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.