A new quote arrived. Which salesperson should see it?

The client problem

A supplier serves customers across several regions. One Account Manager handles the western portfolio. Another owns a named group of strategic properties. A third joins next month as territories change.

Then a buyer requests a quote.

Without a shared commercial model, the marketplace can only put the request into one general inbox and ask somebody to triage it. Orders, comments and dashboard numbers drift into separate spreadsheets. Salespeople see accounts they do not own—or miss the ones they do.

On a multi-vendor procurement platform built with Medusa, we made commercial routing follow the supplier's live portfolio. Orders and quotes are connected to customer properties. Account Manager scope resolves to those same properties. The platform derives each manager's work queue and statistics from the intersection.

The capability is not a notification rule. It is a consistent answer to one business question: which customer relationships belong to this salesperson now?

Manual assignment is the symptom, not the model

The obvious solution is an account_manager_id field on every quote and order.

That can work when ownership is decided transaction by transaction. It becomes fragile when the supplier actually thinks in territories or customer portfolios.

If a region changes hands, must every open quote and historical order be rewritten? If a new property joins a strategic group, who finds and assigns its first request? If two systems update the same field differently, which one owns the truth?

The client already had a stronger concept than manual assignment: an Account Manager is responsible for a geographic territory or a named customer group. The commerce platform needed to make that concept operational.

We therefore derive visibility from current scope. The transaction remains attached to the customer property where it happened. The manager remains attached to the portfolio they own. Routing is the relationship between those two facts.

This avoids turning every commerce event into a separate piece of sales administration.

Use the customer property as the commercial anchor

In property procurement, a company account is not precise enough.

One organisation may operate buildings in several regions, with different buyers, delivery destinations and commercial owners. A quote raised for one property should not automatically appear to every salesperson who knows the parent company.

The platform links orders and quotes to the relevant property. Account Manager scope also resolves to a set of properties, either from geographic rules or from a customer group.

That gives routing one common unit:

• the quote belongs to property P;
• the order belongs to property P;
• the manager's current portfolio contains property P;
• therefore the transaction belongs in that manager's commercial view.

This model works even when the supplier changes how it organises sales. Geography and named accounts can produce the same property-set contract for downstream commerce.

The property becomes the bridge between customer organisation, commercial responsibility and transaction history.

Build the order queue from seller ownership and portfolio scope

An Account Manager must never see an order merely because its property matches a territory. The order must also belong to the authenticated supplier.

The order-list path starts with seller-order relationships. Only then does it resolve the manager's in-scope properties and intersect the seller's order IDs with orders linked to those properties.

That two-part test matters in a marketplace. A property can buy from several suppliers. Two suppliers may define similar geographic territories. Neither fact allows one supplier's employee to see the other's commerce.

If the manager has no valid scope, the list is empty. If the territory currently resolves to no properties, the list is empty. Ambiguity does not widen access.

For the salesperson, the result feels simple: opening Orders shows the commercial work relevant to their portfolio. Underneath, the platform has applied both seller ownership and customer-property scope.

Routing and isolation are the same query, not two later filters that can drift apart.

Make quotes follow the same rule

Quotes are where commercial ownership is especially visible.

A buyer may be asking for a negotiated price, a product alternative or help structuring a larger purchase. The responsible Account Manager needs the request and its conversation context. An unrelated salesperson should not see it.

The quote list filters by the authenticated seller and, for Account Managers, by the property IDs in their current portfolio. The returned record is enriched with the related draft order and customer context so the salesperson can understand the request rather than opening a bare ticket.

The same property check appears on quote detail and comment routes. This is essential. Filtering the list but leaving a direct URL open would create a visual preference, not a commercial boundary.

A manager can work the quote because it belongs to an in-scope customer property. They cannot gain access by guessing an identifier or receiving an old link after the portfolio changes.

Route attention without claiming permanent ownership

There is an important distinction between a scoped queue and a permanent assignee.

The implementation we built derives which Account Manager may see and handle an order or quote from current scope. It does not need to stamp one immutable salesperson onto every transaction.

That is useful when commercial territories evolve. A newly assigned manager can see the portfolio they now own without a bulk rewrite of every related commerce record. A removed manager loses the view because the same scope resolver no longer returns those properties.

Some businesses may still need explicit assignment—for commissions, handover history or named opportunity ownership. That can be added as a separate domain with its own lifecycle.

For this client problem, the immediate need was operational routing: make the right portfolio appear to the right role and make the boundary consistent everywhere. Deriving it from scope kept the transaction history stable while commercial responsibility evolved.

Keep list, detail and action paths aligned

Many access bugs begin with a correct list and an incorrect detail route.

The dashboard hides an out-of-scope order, but /orders/123 still returns it. A quote is absent from the inbox, but its comment endpoint accepts a new message. Statistics are filtered, but a reservation action reaches a customer outside the portfolio.

We use a common scope resolver and reusable guards across these paths. A direct resource is resolved back to its effective property, then checked against the manager's property set and seller context. Missing or out-of-scope relationships fail closed.

This gives the product one commercial rule regardless of navigation:

• lists decide which work appears;
• detail routes decide which work can be opened;
• mutation routes decide which work can be acted on;
• all derive the answer from the same portfolio.

The user experience and the security boundary reinforce each other.

Make the dashboard describe the manager's real book of business

Routing orders and quotes is only half the capability.

An Account Manager also needs to understand the portfolio: revenue, active customers, top properties, products and categories. Showing seller-wide totals beside a scoped order queue would be confusing and commercially misleading.

The vendor statistics routes use the same Account Manager property resolver. Revenue and ranking queries are constrained to the current property set instead of reporting the supplier's complete account.

This produces a coherent workspace. The manager sees the transactions they can work and the performance of the customers they are responsible for. A territory change affects both surfaces through the same model.

We do not need a separate analytics permission spreadsheet that somebody must remember to update after every commercial reorganisation.

The reusable lesson is that analytics scope should be derived from operational scope whenever both claim to describe the same portfolio.

Let portfolio changes take effect without rewriting commerce

Sales organisations change.

A territory can be split. A strategic property group can move to another manager. A new salesperson can inherit a portfolio. The commerce history should remain attached to the properties and suppliers where it occurred.

Because visibility is resolved at access time, changing the Account Manager's scope changes the operational view without rewriting orders and quotes. The new manager receives the relevant queue; the previous manager no longer does.

This makes handover faster, but it also creates an important design responsibility: scope changes must be governed. Invitations and role changes validate seller ownership, replace old links rather than accumulating privileges and prevent conflicting live assignments where the business requires exclusivity.

Dynamic routing is powerful because it follows the current model. That model must therefore be explicit, reviewable and consistently enforced.

Design the empty and ambiguous cases deliberately

What should happen when an Account Manager has no scope?

Showing every order as a fallback would be convenient and dangerous. Guessing from an email domain or delivery postcode inside each route would create inconsistent behaviour.

The platform returns an empty commercial view when it cannot establish a valid portfolio. Direct-resource access fails closed. The supplier's administrator can then correct the person's territory or customer-group assignment.

The same principle applies when a resource cannot be mapped reliably to a property. A quote without the required relationship should not become globally visible simply because routing data is incomplete.

These cases matter in real operations: new employees, partially completed invitations, moved properties and legacy records all create moments where context is missing. A predictable empty state is safer than silent scope expansion.

The interface should explain that the portfolio needs configuration rather than suggesting there is no business activity.

A practical commercial-routing checklist

Before routing marketplace work to Account Managers, ask:

1. What is the true unit of customer ownership: company, property, region or named group?
2. Can both transactions and commercial scope resolve to that unit?
3. Is seller ownership checked before portfolio scope?
4. Do orders and quotes use the same scope resolver?
5. Are list, detail and action routes aligned?
6. Does a direct URL repeat the server-side property check?
7. Do comments and other contextual actions enforce the same rule?
8. Are dashboard statistics limited to the same portfolio?
9. Does a missing or empty scope return no work rather than all work?
10. Can territories change without rewriting commerce history?
11. Does the business need derived visibility, explicit assignment or both?
12. Are role changes and conflicting assignments governed?

These questions turn “send this lead to sales” into a durable commerce capability.

Why Medusa was the right foundation

Medusa held the order, draft-order and customer foundations. We extended the platform with properties, supplier-owned commercial scopes and guards that translate those scopes into operational access.

That allowed the client to organise sales around the way it actually serves customers. Orders, quotes, comments and statistics could all follow one portfolio definition instead of relying on an external CRM export or a manual triage inbox.

The architecture stays in the background. The visible outcome is clear: when a buyer asks for a quote or places an order, the appropriate supplier team sees it in the context of the customers they are responsible for.

That is what extensible commerce should enable. The engine provides the transaction; the solution adds the client's commercial operating model around it.