How approval enforcement works

Read time: 5 minutes. Last updated: August 28, 2026 Who it's for: Anyone who needs approvals to be a control rather than a convention - and anyone evaluating whether QuotWay's approvals would satisfy a compliance or governance requirement.

Approval workflows covers how to build a policy. This article covers what actually holds it in place.

The gate sits inside the send action

When a policy matches a proposal, approval isn't a reminder shown to the sales rep - it's a condition on the send itself, evaluated on the server:

The rep selects Send proposal.
The proposal version is created and recorded.
The quote parks at Awaiting merchant approval.
The buyer is not emailed. The notification is never queued while the quote sits in that state.
Only when the chain terminates approved does the proposal go to the buyer.

There is no override on the send action - no "send anyway" for a rep who is in a hurry. Because the check runs server-side inside the send path rather than in the interface, it applies however the send was initiated, including a send triggered by an automation rule. An automated proposal goes through the same policies as a manual one.

Who can decide a step

Each step in a chain names its approvers, either as:

Specific staff members - "Dana approves this step", or
A role - "any Manager approves this step".

Decisions are authorised on the server against that list. A staff member who isn't a named approver, and isn't in the approving role, is rejected - not hidden from the button, rejected on the request.

Making sure a rep can't approve their own quote

This falls out of your role setup, so it's worth being deliberate about it.

The Sales rep role has no approval permission at all. A Sales rep can build proposals, counter, message buyers and convert accepted quotes, but cannot decide an approval step on any quote - including one they wrote. Manager and Admin can decide, and only on steps where they're a listed approver.

So the configuration that gives you separation of duties is:

Who	Role
The people writing quotes	Sales rep
The people signing them off	Manager or Admin

Set up that way, the person who authored a quote is structurally unable to approve it. If you need one person to both write and approve - a small team where the owner does everything - that works too; just be aware you've chosen convenience over separation.

See Staff and roles for what each role can do.

Conditional steps: escalating on depth of discount

A step can carry a condition, so a chain only engages when it needs to. "A rep may discount to 10%, anything deeper escalates to a manager" is one policy with one conditional step: the manager step activates only when the discount exceeds 10%, and is skipped when it doesn't, so ordinary quotes send straight through.

Conditions can key on quote value, blended discount, deepest single-line discount, deposit percentage, products or collection, customer tags, company location and currency. The deepest-line predicate matters here: a blended quote-level discount lets one deep line hide behind a set of full-price ones.

⚠️ Approval policies require the Professional plan. Conditional steps, parallel steps, timeout escalation and delegation require Enterprise. Routing by value alone - "anything over $50,000 needs an Admin" - is a policy scope rather than a conditional step, and works on Professional.

Admin override, and what it records

An Admin can cancel a live approval chain - for a stalled approver, a deal that changed, or a policy that shouldn't have matched. It's deliberately constrained:

Admin only. Managers and Sales reps don't have it.
A written rationale is required. There's no silent cancel.
Every open step records a decision. Each active, waiting or delegated step gets a skip decision written against it, carrying the rationale, the actor, and their IP address and user agent.
It does not send the proposal. Cancelling returns the quote to In review. To send, you send again - which re-evaluates the policy and forms a fresh chain.

The point of the last one is that the override is an escape from a stuck chain, not a route around the gate. The only way a proposal reaches a buyer is an approved chain.

The audit trail

Every decision is written to an append-only record: who decided, which step, when, the outcome, and any rationale. Skips and overrides appear alongside approvals rather than being omitted, so the history reads as what actually happened. That record is what makes approvals evidence rather than intention - it's the thing to point at when someone asks how a particular discount was authorised.

Approval workflows - building policies, steps, and approvers.
Staff and roles - which role can decide what.
Automation rules - automated sends respect the same policies.