Vendor Defaults

Defaults for New Vendors

Every approved vendor starts with a set of defaults. Those defaults are, in practice, your marketplace’s security model.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

Admin Panel → User Administration:

• User Groups — what the defaults grant

Why defaults matter here

Because nobody reviews them per vendor. Approving is a commercial decision made quickly; whatever the defaults grant is what the vendor gets, for as long as they are a vendor.

So the defaults are worth an hour of careful thought once, rather than a per-vendor decision nobody will actually make.

Start from what a vendor must do

List it honestly: list products, see their own orders, update their own stock, manage their store page. Then grant that and nothing else.

The temptation is to start from an existing internal role and remove things. That approach reliably leaves something in.

They must not see each other

The defining requirement of a marketplace. A vendor seeing another vendor’s orders, pricing or customers is a commercial disaster, and it is exactly the kind of thing a permissive default produces.

Test it explicitly: sign in as one vendor and try to reach another’s data.

They are external

Vendors are not staff. They should not see your internal datastores, your customers beyond their own orders, or anything about your business you would not put in a contract.

Products approved, not just listed

The default should be that a vendor can create a product and not publish it. Approval is what stands between your shop and whatever somebody decides to list on it.

Review the defaults, not the vendors

Changing a default changes what new vendors get; existing ones keep what they were given. So a periodic review needs to look at both — what new vendors receive now, and whether anybody is still holding something the default no longer grants.

Removal should be as easy as approval

Know, before you need it, what revoking a vendor does to their access, their products and their pending orders.

Worked example

A marketplace grants new vendors one group allowing product creation without publication, visibility of their own orders only, and their own store page. The commercial team approves vendors; only two administrators can change the defaults. A quarterly test signs in as a test vendor and attempts to reach another’s orders.

Recommendations

• Build defaults from what a vendor must do, not by trimming a staff role.
• Test vendor-to-vendor isolation deliberately.
• Products created, not published, by default.
• Review defaults and existing grants separately.

Default Security Groups

The default groups decide what an approved vendor can do. They are the mechanism behind the defaults, and they deserve to be designed rather than borrowed.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

Admin Panel → User Administration:

• User Groups — the groups themselves and their permissions

Make vendor groups their own

Not shared with staff. A group used by both means every change made for one audience silently changes the other, and it will eventually grant a vendor something intended for an employee.

Name them so the distinction is obvious — a group called "Vendors" is harder to add to an employee by accident than one called "Sellers".

One group, or a small few

Most marketplaces need exactly one vendor group. Some need two — a standard tier and one with additional capability. Beyond that you are usually modelling commercial arrangements as permissions, which becomes unreviewable quickly.

Scope by ownership, not by table

A vendor needs their own orders, not the orders table. That is row-level security, not a table permission, and getting it wrong is the failure mode that exposes one vendor to another.

Check what the group inherits

Groups often carry more than the permission you added — access to views, reports, documents or activity that came along with something else. Look at what the vendor group actually grants, from the vendor’s side.

Sign in as a vendor

The only reliable test. Reading the permission configuration tells you what you intended; signing in tells you what you did. Keep a test vendor account for exactly this.

Removing the group must remove the access

Which it will not if access was also granted individually somewhere, during setup, by somebody solving a problem. Check that revoking a vendor by removing the group actually ends their access.

Review who else is in it

Periodically. Vendor groups accumulate staff accounts added for testing and never removed, and each one is an internal user with a vendor’s view of your shop.

Worked example

A marketplace has a single Vendors group, used by nobody else, scoped to records the vendor owns rather than to whole tables. A test vendor account is used after every permission change to confirm that another vendor’s orders remain unreachable. A review found three staff accounts left in the group after a launch, which were removed.

Recommendations

• Vendor groups used by vendors only.
• Scope by ownership, not by table.
• Keep a test vendor account and use it.
• Confirm removal actually revokes access.