One order changed. The whole organisation did not need an email.

The client problem

A buyer places an order for one property.

The requester needs confirmation. The supervisor responsible for that property needs visibility. An organisation administrator may need oversight. On the seller side, the location fulfilling the order and the account manager responsible for that customer need to act.

The other buyers, supervisors, store owners and account managers do not.

A simple commerce notification often starts with one email address: the customer who checked out or the seller's general inbox. That stops working when a Medusa platform represents real organisations, properties, locations, territories and delegated roles.

For a B2B marketplace, we built recipient resolution as a business capability. An order event is translated into the people whose role and scope make it relevant. Only then do notification preferences decide whether each enabled channel should be used.

The result is not “more notifications”. It is information with an operational destination.

The client problem: membership does not imply relevance

An organisation may contain masters, managers, supervisors and buyers. A seller may contain platform admins, store owners and account managers. The same person can be linked to a property, stock location, territory or customer group.

Sending every order event to every member creates two problems.

First, it exposes commercial activity more widely than necessary. A supervisor responsible for one property should not automatically receive another property's order updates. A store owner should not see fulfilment work assigned to a different location.

Second, it destroys attention. When most notifications are irrelevant, people learn to ignore the channel. The urgent return, shipment or approval becomes indistinguishable from background noise.

Role alone is not enough. “Supervisor” tells us what somebody can do. It does not tell us whether this particular order belongs inside their operational scope.

The recipient question must combine the event, the organisation graph and the order context.

Start with the order, not the mailing list

The resolver begins with a concrete business object: the order.

On the buyer side, it identifies the requester, the organisation linked to the order and the property or properties concerned. On the seller side, it identifies the seller, the property and the fulfilment location attached to the order.

Those relationships are more durable than an ad hoc list stored inside an email template. They let the same business rule support a feed notification today and another delivery channel later.

The order-property relationship is read from its explicit link. Where an event can arrive before that link is available, the resolver can use the property captured in order metadata as a bounded fallback. Fulfilment locations come from the order's fulfilments.

The system therefore routes from commerce state. It does not ask each subscriber to rediscover organisational context in a different way.

On the buyer side, notify the requester and real approvers

The requester is the first recipient. They initiated the purchase and need its lifecycle.

Organisation masters are included because their role provides organisation-wide oversight. Supervisors and managers require a second condition: they must have management access to one of the properties linked to the order.

An ordinary buyer elsewhere in the organisation is not included merely because they share the employer. A supervisor attached to another property is excluded. A person with buy-only access is not treated as an approver.

The resolver intersects organisation membership, normalised role and property access. It then loads the actual customer records needed for names and email addresses.

This turns a broad hierarchy into a precise answer:

• the person who placed the order;
• the people with organisation-wide oversight;
• the managers responsible for the affected property.

That is a much better business rule than “send to everyone marked manager”.

On the seller side, route work to where it can be acted upon

Seller teams need a different scope model.

General admins remain recipients for broad operational oversight. Store owners are included only when their assigned stock location matches a fulfilment location on the order. Account managers are included only when the order property belongs to one of their configured scopes.

An account-manager scope can represent a geographic territory or a customer/property group. The resolver expands that scope into the properties it covers, then checks for an intersection with the order.

This lets one seller organisation support several teams without turning the notification feed into a shared global inbox. A shipment event goes to the location that fulfils it. A customer issue reaches the account manager who owns that relationship. Unrelated members stay outside the recipient set.

The platform is translating commercial responsibility into routing logic.

Use explicit links, with narrow transition fallbacks

Distributed workflows do not always write every relationship at the same instant.

An order event may be emitted while the property is already present in metadata but before the dedicated property-order link can be read. If recipient resolution required only the final link, a relevant account manager or supervisor could be missed during that transition.

The implementation first queries the canonical link and uses the metadata property only when no link is available. That fallback is narrow: it resolves one piece of order context. It does not replace the organisation and access model with arbitrary metadata.

The same principle applies to the requester. When the customer graph is not available but the order contains the requester's email, the resolver can still preserve the direct recipient.

Good event routing recognises lifecycle timing without turning every field into an unbounded source of truth.

Deduplicate people, not just email strings

The requester may also be an organisation master. An account manager may appear through more than one matching scope. A member can have an ID and an email address used by different notification records.

The buyer resolver deduplicates by customer identity and gives the requester scope priority when the same person qualifies twice. The seller resolver deduplicates by member identity, with email available for recipients that do not have a member record.

This matters for both experience and auditability. A person should not receive the same event twice because two correct rules happened to select them.

It also keeps the recorded role meaningful. The notification can say whether somebody received it as requester, master, property manager, seller admin, store owner or account manager.

Recipient resolution should produce a stable set of people, not a bag of addresses assembled by templates.

Separate “who should know” from “which channel is enabled”

Scope and preference answer different questions.

Recipient resolution asks who is relevant to the event. Notification preferences ask whether an enabled email or in-app feed message should be created for a particular notification type.

Both buyer and seller preference services support a master switch for email and feed, plus per-type settings that can enable or disable each channel. Current delivery is normalised to instant notifications; this implementation does not promise a digest schedule.

Subscribers can therefore follow a consistent sequence:

1. resolve the business recipients;
2. identify the notification type;
3. check whether the relevant channel is enabled;
4. create the feed or email notification for the selected recipients.

If preferences were applied before scope, the system would still need to inspect every member in the organisation. If scope and preferences were mixed into every subscriber, the rules would drift between order confirmation, cancellation, shipment and return events.

The two-stage contract makes the behaviour explainable.

The in-app feed must enforce the same boundary

Targeted creation is not enough if every seller member can later query every notification.

The vendor notification API resolves which recipient identities the current member is allowed to read. A scoped member receives notifications addressed to their member ID or email. An admin can additionally see notifications addressed to the seller-level identity.

List, detail, read and deletion operations use that recipient boundary. Attempting to access a notification outside the resolved set is rejected.

This closes an important gap. Email naturally goes to one inbox, but a shared in-app feed can accidentally re-broaden information if its query only filters by seller.

The same concept used for delivery must therefore survive into retrieval: relevance is attached to the recipient, not merely the organisation that owns the interface.

Keep a safe fallback without making it the normal route

Organisational data is not always complete.

A seller may have no member who resolves for an event, yet still have a general operational email. In that case, the seller resolver can fall back to the seller address.

The fallback prevents a valid event from disappearing because team configuration is temporarily incomplete. But it is used only when the scoped recipient set is empty.

This is different from always copying the shared mailbox. The normal behaviour remains role- and scope-aware. The fallback is an operational safety net, not an excuse to avoid modelling responsibility.

Its use can also become a useful signal: if important events repeatedly fall back to a general address, the seller's member assignments or scopes may need attention.

Apply the resolver across order-related events

The same recipient contract supports several order lifecycle subscribers.

New orders, payments, cancellations, fulfilments, shipments, returns, delivery claims and invoice-replacement flows can ask for the appropriate buyer or seller recipients instead of embedding their own organisation query.

The content and preference key still vary by event. A shipment is not a return, and a buyer confirmation is not a seller action request. The reusable part is the relationship between the order and the relevant people.

This keeps a future change local. If account managers acquire a new scope type, recipient resolution evolves in one place rather than in every email subscriber.

It also makes tests more valuable. The recipient resolver can be checked against in-scope and out-of-scope examples independently from templates and email providers.

Test exclusion as seriously as inclusion

Notification tests often prove that somebody received a message. For scoped commerce, they must also prove who did not.

The buyer tests include an unrelated buyer, a supervisor managing another property and a buy-only member on the correct property. None belongs in the resolved set. The expected recipients are the requester, organisation master and matching property supervisors or managers.

The seller tests include store owners for different locations and account managers for different customer groups. Only the admin, matching store owner and matching account manager resolve for the order.

Feed-access tests also verify that a scoped account manager cannot see seller-wide notifications, while an admin retains that broader visibility.

These negative assertions protect the actual promise. “The right person received it” is incomplete unless “the wrong person did not” is also true.

A practical notification-routing checklist

Before adding another order email, ask:

1. What business event occurred?
2. Which order, property and organisation does it concern?
3. Who requested the action?
4. Which roles have organisation-wide oversight?
5. Which roles require a matching property scope?
6. Which seller location is fulfilling the order?
7. Which account-manager territory or group contains the property?
8. Are explicit links available at this point in the workflow?
9. Is any metadata fallback narrow and temporary?
10. Are recipients deduplicated by stable identity?
11. Does the event have separate email and feed preferences?
12. Are scope resolution and channel preferences evaluated separately?
13. Can scoped members read only notifications addressed to them?
14. Is there a safe fallback when no team member resolves?
15. Do tests prove exclusion as well as inclusion?

If the answer to recipient selection is “all organisation members”, the event probably has not been modelled deeply enough.

The broader lesson

Medusa gives commerce events and notification infrastructure. The client's B2B operating model determined who should care about each event.

We encoded that model as recipient resolution: buyer requesters and relevant approvers on one side; seller admins, matching store owners and matching account managers on the other. Preferences then govern email and feed channels, while the notification API preserves recipient scope when messages are read.

This is what turns a notification from a broadcast into an operational capability.

The best commerce notification is not the one sent to the largest audience. It is the one that reaches every person who can understand or act on the event—and nobody who cannot.