Why approval processes matter
"A rep discounted a deal by 30% without checking with anyone. It closed before anyone even noticed. We need a hard stop before that happens again — not a policy document nobody reads."
A written policy only works if someone actually follows it in the moment. Workflow Automation (a tool that reacts to a change after it happens) can tell people what happened. But it can't stop something before it happens.
That's the job of Approval Processes: pausing a record until the right person says yes.
Anatomy of an approval process
An Approval Process is a rule you set up in advance. It has two parts: an entry condition (what triggers it) and an ordered list of approval steps (who has to say yes, and in what order).
When a record meets that condition and someone submits it, it follows one strict path:
| Rule | Detail |
|---|---|
| Step ordering | Steps happen one at a time, in order. A request only moves to the next approver once the current one says yes |
| Any rejection | Any single "no" immediately ends the request as REJECTED — any steps still left are skipped |
| One active approval at a time | A record can only be waiting on one approval process per object at a time |
| Permanent history | Every approval or rejection is saved forever, once it happens — it can't be edited or removed later |
1 Require sign-off on big discounts
discount_percent__c > 15, meaning "trigger this when the discount is over 15%."