- Purchase control often begins with a false choice.
- Either buyers can place orders freely and finance discovers the exceptions afterwards, or every basket waits for somebody to approve it.
- The first model is fast but weak.
- Our client needed a third option for a property-procurement platform: routine buying should remain routine, while purchases outside a person’s delegated authority should reach the right deci
The client problem
Purchase control often begins with a false choice.
Either buyers can place orders freely and finance discovers the exceptions afterwards, or every basket waits for somebody to approve it.
The first model is fast but weak. The second is controlled but frustrating. A replacement part for an urgent repair can sit in the same queue as a large planned purchase, even when the buyer already has authority to place the smaller order.
Our client needed a third option for a property-procurement platform: routine buying should remain routine, while purchases outside a person’s delegated authority should reach the right decision-maker for the relevant property.
Medusa gave us the cart, customer, order and workflow foundations. It did not automatically know the client’s hierarchy, property responsibilities or approval thresholds. We built that decision layer around the commerce journey.
The result is not “approval on every order.” It is progressive control: the system asks for a decision only when the business rule requires one.
Start with delegation, not a generic approval status
An approval feature can look deceptively small in a backlog:
Add pending, approved and rejected states to checkout.
Those states describe what happened, but they do not answer the difficult questions.
Who is allowed to buy directly? Which amount changes that authority? Who receives the request? Does responsibility follow the organisation or the property? What happens when the usual approver has not been assigned? Can the requester approve their own exception? What information does the decision-maker need?
The real product is a delegation model.
For this client, the purchasing hierarchy included Supervisor, Manager and Master responsibilities. Those names belong to their operating model; another organisation may call them site lead, regional manager and procurement director. The reusable principle is more important than the labels: approval routing should reflect how authority is actually delegated, not force every customer into one hard-coded role pair.
Let ordinary purchases take the direct path
The fastest approval is the one the business does not require.
We introduced configurable amount thresholds for the different levels of responsibility. When a basket remains within the requester’s delegated limit and no other policy signal requires escalation, checkout can continue without creating an approval request.
When the value crosses that boundary, the platform creates a durable request and routes it upward.
This produces a much better experience than a universal queue. The buyer replacing a modest maintenance item can finish the purchase. The buyer assembling a materially larger order receives a clear explanation that a decision is required. The system applies control at the exception, not friction at the entrance.
For the organisation, thresholds are not merely numbers in a settings screen. They express who has authority to commit spend. Making them configurable allows the approval system to follow policy as responsibilities evolve.
Route to responsibility for the property
A property business is not governed by one flat list of employees.
One manager may be responsible for several properties. A supervisor may operate within one site. A senior organisation role may have visibility across the portfolio without handling every routine decision.
The approval request therefore carries property context. Routing uses that context to find the person whose responsibility matches the purchase.
Consider two identical baskets created by buyers in the same organisation. If they belong to different properties, they may need to reach different managers. Routing only by company membership would send one of those requests to the wrong person or require a central team to redistribute it manually.
Property-aware routing turns an abstract hierarchy into an operational one. The request arrives with the location, buyer, basket and amount that explain why this person is being asked to decide.
Design a fallback for missing assignments
Real organisations are incomplete.
A new property may not yet have a manager. Someone may have left. Responsibility may be in transition. The approval system cannot simply create a request with no recipient, nor should it silently convert the exception into an unrestricted purchase.
The implemented hierarchy includes a fallback to an authorised organisation-level Master when no responsible property manager is available.
That fallback keeps the purchase moving while preserving the control decision. It also makes missing organisational data visible through a real workflow rather than allowing requests to disappear into an unowned state.
Every approval design needs an explicit answer to the same question: if the ideal approver cannot be resolved, who is allowed to make the decision? “Nobody” and “any administrator” are both operational failures disguised as defaults.
Keep requester and decision-maker separate
The person who creates an exception should not gain authority simply because the software knows they are associated with the request.
Requesting, approving and rejecting are separate authenticated actions. Access checks determine which supervisors or managers may see and decide a request for a given property.
This separation protects more than the final status. It protects the meaning of the workflow.
The requester is saying, “I need the organisation to authorise this purchase.” The approver is saying, “Within my delegated responsibility, I accept or reject that commitment.” If one browser action can perform both roles without a policy check, the approval screen is theatre.
The same separation makes the interface clearer. Buyers see the state of their request and the next expected action. Approvers see a queue of decisions within their scope rather than every order placed by the organisation.
Preserve the cart while the decision happens
Approval is not a separate document floating beside checkout. It is part of the buying journey.
The cart contains the actual commercial context: sellers, lines, quantities, shipping choices, property and totals. If that context is discarded when an approval request is created, the buyer must rebuild the order after approval. If it remains freely mutable without lifecycle rules, the approver may authorise one basket while checkout completes another.
We persist the checkout context and govern how it can move through submission, revision and decision. The approval request points to the purchase being evaluated, and guards protect the seller and shipping consistency that the decision depends on.
For the buyer, this means approval feels like one stage of checkout rather than a detour into email and spreadsheets. For the approver, it means the request contains the basket they are actually authorising.
Approval can be triggered by more than order value
An amount threshold answers one kind of risk: how large is this purchase?
Procurement policy also asks: what has already been spent?
A relatively small basket can be the purchase that pushes a property or GL account beyond its monthly or year-to-date budget. A larger order can remain within an approved plan. Treating value and budget as the same signal produces the wrong decisions in both directions.
The platform therefore has separate threshold and budget-overage concepts. The detailed budget path evaluates the relevant spending period and current allocation before applying the configured policy. That deserves its own treatment because its business question is different from hierarchical routing.
The important point here is extensibility: the request lifecycle can accept multiple policy signals without converting the routing model into one giant conditional. Amount, budget and other future rules decide whether escalation is needed; property responsibility and hierarchy decide who should receive it.
Give the approver a decision, not a data hunt
An approval queue only saves time if each item explains itself.
The decision-maker needs enough context to answer three questions quickly:
- What is being purchased and for which property?
- Why did this order require my attention?
- What will happen when I approve, reject or request a change?
The request should surface the triggering threshold, requester, property and basket rather than asking the approver to reconstruct them across systems.
This is where a purpose-built commerce workflow improves on approval by email. The decision remains connected to current cart and organisation data. The system can enforce access and lifecycle rules at the moment of action. The buyer receives a durable result instead of an ambiguous reply in a thread.
Revisions are part of the normal path
Approval is rarely a binary judgement on the first submission.
An approver may accept the business need but ask the buyer to reduce a quantity, choose another item or correct the delivery context. Forcing a rejection and a brand-new cart loses the thread between the initial request and the final purchase.
The wider approval capability records revision requests, notes, actors and times, then allows a buyer to resubmit with a description of what changed. Submitted, revision-requested, resubmitted, approved and rejected events create a durable history of the decision journey.
That gives both sides a shared explanation. The buyer knows what to change. The approver can see whether the resubmission addresses the request. The organisation retains the sequence that led to the final decision.
Protect the moment of decision
Two authorised people can open the same request. Without a concurrency rule, one may approve while another rejects a stale screen a fraction of a second later.
The platform serialises competing decision actions around the approval request. The goal is narrow and concrete: one current request cannot accept conflicting decisions at the same time.
This is a small implementation detail with a large product consequence. The UI can report a stable outcome instead of asking users to interpret whichever response arrived last. It also gives downstream checkout workflows one decision to act upon.
Concurrency controls belong wherever a business state can be changed by multiple actors. An approval request is exactly that kind of state.
Why we extended Medusa instead of building a separate approval portal
A standalone procurement portal could collect approval forms, but it would duplicate the hardest context.
It would need customers, roles, property assignments, carts, lines, totals, shipping decisions and order outcomes. Every change in commerce would create another integration contract between the portal and the store.
By extending Medusa, we kept the decision close to the purchase it governs. Medusa remained responsible for commerce. The custom approval module owned requests, routing, thresholds and lifecycle. Workflows connected the decision to checkout without asking either domain to pretend it was the other.
This is why choosing an extensible platform is an architectural decision. The benefit is not freedom to add arbitrary code. It is the ability to add a client-specific business capability while preserving one coherent buying journey.
A practical approval design checklist
Before adding approvals to commerce, define these contracts.
- Direct-buy authority: which conditions let a buyer complete checkout without escalation?
- Trigger signals: amount, budget, category, property or another policy fact?
- Responsibility scope: organisation-wide, regional, property-level or a combination?
- Escalation ladder: which role receives each level of exception?
- Fallback owner: who decides when the preferred assignment is missing?
- Separation of duties: who may request, view and decide?
- Cart stability: which parts of checkout are frozen or governed while approval is open?
- Revision lifecycle: can an approver request changes without destroying the original context?
- Concurrent action: what prevents conflicting decisions?
- Operator explanation: can every participant see why the request exists and what happens next?
If those answers are vague, adding three status values will not create governance. It will create a queue nobody trusts.
The business outcome: precise control
The best approval system is not the one that intercepts the most purchases. It is the one that applies the organisation’s authority model accurately.
Routine orders keep moving. Exceptional commitments reach someone with the right responsibility. Missing assignments have a safe escalation path. Buyers and approvers stay inside one commerce journey, with a durable explanation of the decision.
Medusa supplied the transactional foundation. We added the client’s delegation model: hierarchical thresholds, property-aware routing, authenticated decisions, revision handling and protected checkout state.
That is the kind of commerce capability WeAreSouk builds. We begin with the operational tension—in this case, financial control versus purchasing speed—and extend the platform so the business no longer has to choose between the two.
If your approval process currently lives in inboxes, spreadsheets or a universal checkout queue, we can map the delegation rules and design a Medusa workflow that escalates the exceptions without slowing everything else down.