- A shared supplier login is convenient right up until the supplier grows beyond one person.
- The warehouse manager needs to update stock.
- Offboarding becomes a password change.
- That was the client problem we solved for a multi-vendor marketplace built on Medusa.
The client problem
A shared supplier login is convenient right up until the supplier grows beyond one person.
The warehouse manager needs to update stock. A commercial manager needs to handle quotes and customer relationships. An administrator needs to configure pricing, shipping and the team itself. If everyone signs in with the same account, everyone receives the broadest authority—and nobody can tell who changed what.
Offboarding becomes a password change. Delegation becomes a message containing credentials. A person responsible for one store can operate inventory across every site. A commercial employee may gain access to configuration they should never touch.
That was the client problem we solved for a multi-vendor marketplace built on Medusa.
We turned each seller into an organisation of named members with three distinct journeys: Admin, Store Manager and Account Manager. Invitations carry their future responsibility. Locations and commercial scopes are assigned explicitly. The backend enforces what each person can see and change.
The seller account stopped being a credential. It became an operating model.
Begin with the jobs people actually perform
Role systems often begin with pages.
“Can this person open Products?”
“Should this menu item be hidden?”
Those questions are useful for interface design, but they are a weak foundation for authority. A person can perform the same business action through several screens or an API. Hiding a page does not explain why the action is allowed.
We began with responsibilities.
- The Admin runs the supplier organisation and can manage its full commercial and operational configuration.
- The Store Manager operates one or more assigned stock locations: products, inventory, shipping and orders associated with that responsibility.
- The Account Manager follows customers, quotes and orders inside an assigned commercial scope, with read-oriented access to the catalogue and inventory context they need.
The labels belong to this client’s model. Another supplier may use Operations Manager or Territory Representative. The reusable principle is to model authority around work, not around navigation.
Give every person an individual identity
The first improvement over a shared login is deceptively simple: each team member has their own account.
That makes invitation, activation and removal individual events. A supplier can revoke one employee without disrupting everyone else. Notifications reach the person expected to act. Support can distinguish the organisation from the human using it.
But individual accounts without scoped authority merely reproduce the shared-login risk many times. Each invitation must therefore describe the role the person will hold and the business scope attached to it.
The role-aware invitation endpoint creates the member invitation, then pre-assigns the location or commercial scope required by the chosen role. When the recipient accepts, the platform can materialise a complete responsibility rather than a member who exists but cannot safely do their job.
An invitation is not just an email. It is the beginning of an authorisation transition.
Admin: responsibility for the supplier organisation
The Admin has broad access because their job is broad.
They manage orders, catalogue, inventory, customers, team, settings, shipping, analytics, pricing and quotes. They can invite the people who will operate the organisation and assign the context those roles require.
The important distinction is that Admin authority belongs to a named person inside one seller organisation. It is not a marketplace-wide backdoor and not a credential shared among the supplier’s staff.
This gives the supplier a clear owner for configuration decisions. It also gives the marketplace a stable boundary: the Admin may operate the seller they belong to, not another seller’s data.
Broad authority is sometimes necessary. The architecture makes its owner and tenant explicit.
Store Manager: operate the sites you are responsible for
A supplier with several stores or warehouses rarely wants every operator to manage every location.
The Store Manager role is linked to one or more stock locations. The assignment describes the physical sites the person operates.
Within that responsibility, Store Managers can work with products, inventory, shipping and orders. They can read the customer and analytics context required for operations. They do not inherit organisation settings or pricing administration simply because they need to receive an order.
This turns a vague “warehouse user” into a useful commerce role. The member is not merely allowed to open an inventory screen; their responsibility is connected to actual stock-owning sites.
The same location identity can then support order assignment, pickup, fulfilment and operational reporting. Team structure and logistics refer to the same business object.
Account Manager: commercial access follows a portfolio
An Account Manager’s responsibility is neither organisation-wide administration nor warehouse operation.
They need to follow customers, quotes and orders inside a commercial portfolio. That portfolio may be geographic—a territory built from service areas—or based on a property/customer group.
The invitation and member model therefore attach an Account Manager scope. Resource guards resolve the property behind an order, quote, return, reservation or customer relationship and compare it with that scope.
Inside the portfolio, the Account Manager can see the commerce context and handle quotes. Outside it, guarded resource paths return not found.
That last behaviour is valuable in a marketplace. It does not merely deny mutation; it avoids disclosing that an out-of-scope resource exists. Commercial delegation remains contained inside the seller and the assigned portfolio.
Delegation itself needs permission
Who may invite whom is part of the authority model.
An Admin can construct the team and assign the three supplier roles. A Store Manager can invite Account Managers when building the commercial support around their operation, but cannot create another Admin or another Store Manager.
The backend checks that rule even if a caller bypasses the dashboard.
This provides useful delegation without allowing authority to expand recursively. The location operator can add the commercial role they are expected to coordinate with, but cannot create a peer with broader operational sites or an organisation owner.
Every organisation system should define this second-order permission. It is not enough to ask what a role may do. Ask which roles it may create and which scopes it may assign.
Validate the scope before creating the responsibility
A role name alone is incomplete.
A Store Manager invitation requires stock locations. An Account Manager invitation requires a geographic territory or property group. The referenced scope must belong to the same seller.
Those rules are enforced before the platform treats the invitation as valid. If assignment creation fails, the workflow cleans up the new invitation and any resources created for that request.
This avoids a common operational trap: the user receives an invitation, accepts it and discovers an account with a role label but no usable responsibility. It also avoids leaving orphaned territories or scope records after a failed setup.
The useful unit of success is not “invite row created.” It is “a person can accept a complete, valid role inside the right supplier.”
Change roles as one governed transition
People change jobs.
A Store Manager may become an Admin. An Account Manager may move to another territory. A person may switch from site operations to commercial responsibility.
Changing one role string is not enough. Old stock-location assignments or commercial scope links must be removed, and the new responsibility must be created. If the transition fails halfway through, the member should not be left with a mixture of old and new authority.
The role-change workflow first validates everything the target role requires. It snapshots existing Store Manager assignments and Account Manager scope links, then replaces them. Compensation logic can restore the prior assignment state when a later step fails.
This makes a role change a business transition rather than a sequence of unrelated form updates.
For the operator, the outcome is clear: the member has the old responsibility or the new one, not an accidental combination produced by a partial update.
Prevent two people from silently owning one exclusive scope
Some assignments are intentionally exclusive.
A particular territory or property group may have one active Account Manager scope in this operating model. If the UI creates a second assignment without checking the first, both people can believe they own the portfolio and customers can receive conflicting follow-up.
The platform checks active links and uses database constraints as a safety net. Existing orphan scope records can be reused when appropriate, while a scope already attached to another member or pending invitation produces a conflict.
The business rule is therefore visible at both application and data levels.
Not every organisation needs one-to-one commercial portfolios. Where it does, exclusivity should be a model invariant, not a convention written in onboarding documentation.
The backend is the security boundary
A polished role-aware dashboard is valuable. It gives each member a focused interface and avoids presenting actions they cannot perform.
It is not enough.
Requests can be crafted directly. Old browser tabs can retain routes. A frontend bug can reveal a button. Security must be enforced where data is read or changed.
Vendor middleware and resource guards check capabilities and scope on the server. Member listings are filtered by seller. Store Manager assignments constrain operational responsibility. Account Manager paths resolve the resource’s property before allowing access. Focused isolation tests cover cross-seller and out-of-scope behaviour.
The frontend expresses the role. The backend authorises the action.
That separation lets the interface evolve without turning every UI change into a security change.
Permission matrices should describe capabilities
The implemented role matrix covers business capabilities such as orders, products, inventory, customers, team, settings, shipping, analytics, pricing and quotes.
Each role can have full, read, specialised or no access depending on the capability.
This is stronger than maintaining a list of allowed URLs. The same capability can appear in a table, a detail page, a bulk action or a background operation. Capability-based rules keep the decision attached to business meaning.
They also make stakeholder conversations easier.
“Should an Account Manager handle quotes in their territory?” is a question the supplier can answer. “Should role X access route Y?” is implementation language that hides the policy decision.
Once the business answer is clear, routes and UI components can consistently consume it.
Why we extended Medusa and the marketplace model
Medusa and the marketplace foundation already provided seller membership, authentication and commerce resources. The client needed a deeper supplier organisation: multiple sites, operational delegation and scoped commercial portfolios.
We extended those foundations instead of building a separate identity portal.
The custom roles stay close to the resources they govern. Store Manager assignments point to Medusa stock locations. Account Manager scopes resolve properties used by orders and quotes. Invitations flow into seller membership. Server guards protect the same APIs the operational dashboards use.
Choosing Medusa made sense because we could preserve one commerce identity model while adding the client’s organisational reality on top.
The result is not generic role-based access control for its own sake. It is a supplier operating model embedded in commerce.
A practical supplier-organisation checklist
Before replacing a shared vendor account, define these contracts.
- Individual identity: can every employee be invited, removed and audited separately?
- Business roles: which jobs exist inside the supplier organisation?
- Capabilities: what may each role read, operate, configure or delegate?
- Operational scope: which stock locations belong to each site manager?
- Commercial scope: which territories or property groups belong to each account manager?
- Invitation completeness: is role context validated before the recipient joins?
- Delegation authority: which roles may invite which other roles?
- Role transitions: how are old assignments removed and prior state restored on failure?
- Exclusive ownership: which scopes may have only one active assignee?
- Server enforcement: do APIs independently verify tenant, capability and resource scope?
Answering those questions turns “add users” into an organisation design.
The outcome: suppliers can grow without sharing authority
The supplier no longer has to choose between one unsafe shared credential and a collection of equally powerful accounts.
Admins can run the organisation. Store Managers can operate assigned physical sites. Account Managers can handle commercial work inside a defined portfolio. Invitations and role changes create complete responsibilities, while backend guards enforce the same boundaries even outside the dashboard.
Medusa supplied seller membership and the commerce resources. We added the organisational contracts the client’s multi-site marketplace needed.
That is how WeAreSouk approaches enterprise marketplace architecture: begin with how people actually share work, then make identity, scope and delegation part of the commerce model.
If a supplier portal still assumes one login—or gives every employee the same global permission—we can map the team’s responsibilities and build a Medusa organisation that remains useful as the seller grows.