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.