A company-store approval queue should release an order only when the required decision-makers have approved its current version and a final check confirms that it is still orderable. An approval email is not a production instruction. Define who can decide, what they are deciding, how long the decision remains valid and what happens when the request changes.
This guide is for teams configuring a held-order workflow with a store provider or internal automation team. It answers a narrower question than how much each department can spend: how does a request move safely from “waiting for review” to “released,” without disappearing, duplicating or using an outdated approval?
Brand Sauce publishes this guide as a company-store provider. The workflow below is our recommended design, not a claim that every Brand Sauce store includes these controls or integrates with the example platforms. Official documentation was checked October 14, 2026. Confirm functionality, implementation responsibility and quote-needed work for your proposed setup.
Decide which orders actually need a queue
Do not send every employee selection to a manager merely because an approval feature exists. If eligibility, assortment, destination and funding have already been authorized, another approval may add waiting without resolving a new question. A queue is useful when a person must decide something the established rules cannot settle.
| Order situation | Recommended route | Decision still needed |
|---|---|---|
| Eligible employee, funded gift, approved product and destination | Standing authorization with final automated or operator checks | Whether the request still meets the authorized rules |
| Unapproved artwork or special decoration | Brand review before release | Whether this exact artwork version is acceptable |
| Request beyond the authorized allowance | Budget-owner exception review | Whether the additional commitment is authorized |
| Large event order with a fixed deadline | Quantity, funding and supplier feasibility review | Whether this quoted batch can proceed as specified |
| Unsupported destination or uncertain product availability | Operational hold | Whether the order can be fulfilled, not whether a manager likes it |
Label operational holds separately from approval holds. A manager cannot make an unavailable garment available by clicking approve. The employee should know whether the request needs a decision, a correction or a supplier answer. Use the department-budget guide to establish spending authority before designing this queue.
Use states that describe what can happen next
A single “pending” label conceals too much. Define a small set of states, then assign a responsible person and permitted next action to each. The names can differ between systems; their meanings should not.
| State | Meaning | Permitted next step |
|---|---|---|
| Submitted | A request exists; routing is not yet complete | Validate required fields and assign reviewers |
| Awaiting decision | The current version has outstanding approvals | Approve, reject, return for correction or escalate |
| Approved, not released | Required decisions are complete | Recheck the order and request supplier release |
| Release unresolved | A release was attempted but the outcome is unknown | Investigate the existing attempt before retrying |
| Released | The receiving order system has confirmed acceptance | Track production and fulfillment separately |
| Rejected, withdrawn or expired | This request version cannot proceed | Close it or create a traceable revised request |
“Approved” and “released” should not be synonyms. For example, Shopify’s B2B checkout documentation describes submitting orders as drafts for merchant review rather than processing them automatically. In that setting, initial checkout does not collect payment. This illustrates why a submitted request, confirmation and payment can be different events; it does not establish an employee-manager approval chain or a Brand Sauce integration.
Document the actual boundary in your workflow: does release create a supplier order, authorize payment, start decoration or merely place work in another queue? The supplier’s acknowledgement should identify the accepted order and version. Keep payment status and production status visible without pretending that one proves the other.
Choose “either approver” or “both approvers” deliberately
Putting two names on an approval request does not explain the rule. Sometimes either person has the same authority and the first valid decision is sufficient. Sometimes two distinct authorities must agree. Sometimes one decision should happen before the next reviewer spends time on the request.
Microsoft’s approval documentation distinguishes a first-response mode from an everyone-must-approve mode. In the latter, all assigned approvers must approve, while a rejection can end the request. These are different behaviors, not interchangeable ways to notify more people.
For a merchandise workflow, use either/or for equivalent delegated authority: a budget owner or their authorized backup. Use both when the decisions are independent: marketing approves new artwork and finance approves an additional commitment. Use sequential review when a later decision depends on an earlier one, such as confirming a revised quote after the specification is settled.
Do not add a backup to an “everyone must approve” group if the intention is to avoid waiting for the primary approver. That design adds another required response. Record delegation scope, start and end dates, and the person who actually decided. If the requester is also a reviewer, apply the organization’s self-approval policy explicitly instead of letting routing defaults decide.
Bind approval to an exact request version
The most important approval record is not a green checkmark. It is the link between a decision and what was approved. Store a stable request ID plus a revision number, then retain the product variants, quantities, artwork reference, destination scope, quoted cost components and funding reference associated with that revision.
Use a field-change policy. Changing a comment may not affect authorization. Changing the logo file, quantity, delivery country or committed amount often does. Decide in advance which changes invalidate which approvals. Do not carry an old decision forward merely because the total stayed the same: a different product or artwork can change the substance of the request.
Illustrative scenario: marketing approves revision 3 of a 24-shirt event order with a one-color logo. The requester then replaces the logo file while keeping quantity and price unchanged. Revision 4 needs a new artwork decision, even if the funding decision remains valid under the documented policy. An old email approving revision 3 must not release revision 4.
When a revision is created, close obsolete decision links or reject their responses as stale. Tell the approver that the request changed and provide the current version. Preserve the earlier decision in the history; deleting it makes later investigation harder. The aim is traceability, not accumulating approvals that no longer apply.
Treat reminders, escalation and expiry as different actions
A reminder asks the same authorized person to act. Escalation changes who is responsible or alerts an owner to intervene. Expiry ends the validity of the current request or approval. Write a separate rule for each rather than relying on a generic overdue email.
Set the decision deadline from the order’s real constraints: quote validity, event date, inventory reservation or production cutoff. A software timer is not a service commitment. Microsoft documents a 30-day cloud-flow run-duration limit, including pending approval steps. That is a technical limit in that platform, not a sensible default waiting period for employee merchandise.
For a pilot, you might propose a reminder after one business day and reassignment after two, with local business calendars and time zones stated. Those are illustrative policy choices, not service benchmarks. Confirm that the backup can make the required decision and that reassignment invalidates the previous action path where appropriate.
On expiry, hold or close the request; do not silently interpret nonresponse as consent. Inform the employee whether they need to resubmit, choose again or simply wait for support. An expired approval should not erase the underlying gift entitlement unless the separately communicated program rules say so.
Make release a controlled action, not an email side effect
Immediately before release, check that the current revision matches the approved revision, all required decisions remain valid, the funding authorization is usable and the supplier can accept the specified product and destination. Verify any promised stock reservation and delivery assumptions. A held request should not be described as reserved stock unless a real reservation exists.
Ensure only one release action can succeed for a given request version. Two approvers responding together, a retried automation or an operator double-clicking should not produce two supplier orders. Ask the implementation team to demonstrate this with a stable release reference and duplicate detection at the receiving boundary where supported.
If the supplier call times out, the outcome may be unknown rather than failed. Look up the existing release reference before sending another order. Keep the request in an unresolved state until an operator or system establishes what happened. Our order-sync recovery guide covers this handoff problem in more depth.
After release, changes belong in the supplier’s change or cancellation process. Reopening an approval does not undo production. See the order-change and cancellation guide for setting that boundary with recipients.
Require a demonstration of the difficult cases
Use the following acceptance card before launch. A small manual queue can satisfy it with a controlled register and named operator; a high-volume automated queue needs equivalent controls demonstrated in the connected systems. Record each result as supported, manual or unresolved.
- Routine request: an authorized gift follows the intended route without an unnecessary manager task.
- Two required decisions: one approval does not release an order requiring both artwork and funding approval.
- Backup authority: the backup can act without also requiring the absent primary reviewer.
- Changed request: a response to an obsolete revision cannot release the current revision.
- Expired request: a late approval does not revive it silently.
- Concurrent responses: simultaneous actions produce one release, not two.
- Uncertain handoff: a simulated timeout leads to investigation rather than a blind duplicate order.
- Employee withdrawal: withdrawing before release prevents a later response from releasing the request.
Retain the request IDs and observed outcomes. Measure age of open requests by hold reason, time to a valid decision and time from approval to confirmed release separately. Combining them into one average hides whether the bottleneck is an approver, the product or the connection to the supplier.
Keep bulk and hybrid orders in the same control model
On-demand ordering can suit recurring individual selections, while a known event quantity may justify a bulk purchase. Neither model removes the approval boundary. Bulk decisions often need a batch-level specification and quote; individual gift decisions may already fit standing authorization.
In a hybrid program, approve the bulk replenishment commitment separately from the allocation of already-owned stock. Do not ask employees to approve procurement they do not control, and do not treat distributing an existing shirt as a second purchase. The queue should identify the commitment being authorized, not simply the number of merchandise requests arriving.
Frequently asked questions
Should every employee gift require manager approval?
No. Use standing authorization when the defined eligibility, assortment and funding rules are sufficient. Add review for a real unresolved decision, and test that the routine route cannot bypass those boundaries.
Can an email reply be the approval record?
It can be supporting evidence in a controlled manual workflow if the authorized responder, exact revision and decision are retained. An unstructured reply alone does not establish that the order was released, paid or accepted by the supplier.
What should a provider demonstrate before we buy?
Ask for the eight pilot cases above using your actual authority rules. Require a clear distinction between native functions, external automation and operator work, with implementation and service costs quoted where unknown. The deliverable is a reliable release process—not merely an approval button.
