When a record needs a person's sign-off before it proceeds — a high-value order, a credit release, a price override — model it as an approval process. The process resolves a real approver for each step, notifies them, locks the record while the decision is pending, stamps the outcome onto the record, and leaves an audit trail of who decided what and when — everything an "override checkbox" cannot give you. This page builds a two-step approval end-to-end, shows every way a record enters it and every way approvers act on it (including on mobile), and explains how approval state gates what happens to the document next.
Prerequisites
- The approval-model capability (
setup.metadata.approval.manage). Holders of this capability are also approval administrators at run time — they may act on any pending step, which matters for unblocking stuck requests. - The stored values of the entity's status field — outcome stamps are written as stored values, not display labels.
- Whatever the steps will resolve approvers from: a record field holding a user (a manager or owner field), or the team or role that owns the decision.
Procedure
- 1
Label is what approvers and submitters see; Name is the stable internal identifier.
- 2
Entity decides which records can enter this process — one process serves one entity.
- 3
Active is off by default: an inactive process is never selected, so build and review before switching it on.
- 4
Process Order breaks ties when several active processes on the entity match the same record — the lowest matching order wins.
- 5
Allowed Submitters: Anyone with access, the record owner only, a security role or a team — independent of who approves.
Step 1 — Create the process
Go to Setup → Process Studio → Approvals and choose New (the same list is reachable per entity under Design Studio → Entities → the entity → Logic → Approval Processes). Enter a reader-facing Label and stable internal Name, select the Entity, leave Active off, and set Process Order and Allowed Submitters — anyone with access to the record, the record owner only, members of a security role, or members of a team. After creating the shell, add the entry condition that decides which records qualify—for example, total amount above fifty thousand—and configure maker-checker (require a separate approver, which stops the submitter approving their own request), lock record on submission, whether the current approver may edit while the request is pending, and whether the submitter may recall. When several active processes exist for one entity, the first matching process by order claims the record, so compare neighboring orders and verify this process cannot shadow or be shadowed accidentally.
Step 2 — Define the steps
Add the steps in order. Each step names its approver: a specific user, a user from a record field (the classic "the requester's manager" — the field must hold a user), any member of a role, a team, or an approver the submitter chooses at submission. Per step you also decide whether one response completes it or every member must agree (unanimous), what a rejection does — end the request, or send it back to the previous step — and an optional step entry condition with a skip behavior, so a step like "finance review" engages only above a second threshold and is skipped cleanly below it. Steps can carry timeouts: after a set number of hours, auto-approve, auto-reject or escalate past the silent approver.
Step 3 — Wire the outcomes to the record
This is where approval state gates the document. On the process and its steps, configure field updates — partial updates applied on submission (status becomes pending approval), on a step's decision, and on the final approval, rejection, recall or revert (approved orders stamp approved; rejected ones return to draft). Add tasks where a decision should create follow-up work, notifications (with templates per event) so approvers and submitters hear about submissions and decisions, and follow-up business rules where a decision should run richer logic. With the lock while pending, the stamps close the loop: downstream steps — releasing, invoicing, a status transition guarded by a business rule that requires the approved stamp — simply cannot happen until the sign-off exists.
Step 4 — Activate
Switch the process to active. There is no draft-version lifecycle here: active means live immediately, and edits to an active process are live immediately too — so build, review, then activate, and prefer editing during quiet hours on busy entities.
Step 5 — Submit records into the process
A record enters approval one of four ways. Interactively: the Approval Panel on the record form shows a submit button when the record is eligible — if the panel is missing, add the widget to the entity's layout. Automatically by the process itself: enable auto-submit on create or update, optionally with a condition, and matching saves submit with no further configuration. Declaratively: a business rule's request-approval action submits after a qualifying save. Or from a workflow, whose submit step also waits for the decision so the flow can branch on the outcome. One rule spans all four: a record can have only one pending request at a time.
Step 6 — Work the pending approvals
Approvers act from two surfaces. The Approvals inbox page lists everything pending for the signed-in user — entity, record, step and age — with bulk approve and reject for high-volume queues. The record's Approval Panel shows the same request in context, with the full history timeline. The actions: approve and reject (with comments) for the current step's approver, their nominated delegate, a reassignee or an approval administrator; reassign to redirect the current step to another user; recall for the original submitter to withdraw a pending request; revert to roll back an already-approved request; and comment for remarks that change nothing but land in the trail. On mobile, the Approval Panel on the record form carries the same set — submit, approve or reject with remarks, recall, reassign, and the history — so a manager can clear approvals from the field.
Step 7 — Verify the chain end-to-end
Prove the entire chain with a disposable record over the threshold: submit as an allowed user, confirm one pending request, the expected lock and pending stamp, then act as each resolved approver and verify the timeline before advancing. Confirm final approval stamps and unlock behavior. Run negative probes as well: an under-threshold record is not eligible, an unauthorized submitter is refused, maker-checker blocks self-approval, and rejection or recall applies its configured effects. Capture the request identifiers and outcomes so support can distinguish configuration from user error later.
Expected result
Exactly one active process claims an eligible record, each step resolves to the intended approver population, and the record's lock, status stamps, notifications and history change at the configured moments. Ineligible, unauthorized and maker-checker cases fail safely, while final approval, rejection, recall and timeout paths leave an auditable terminal state.
Common problems
Submission fails or the record is not eligible. In order: a pending request already exists (one per record); no active process's entry condition matches — and a broken entry-condition expression fails closed, reporting not eligible rather than erroring; or the submitter violates the process's submitter restriction. Test the entry condition the way you test a rule condition.
The process is never selected. A process with zero steps is never chosen, however good its entry condition. Also check process order — an earlier active process whose condition also passes claims the record first.
A step's approver cannot act or resolves to no one. For field-based approvers, the record field must actually hold a user (an empty manager field resolves nobody); for team and role steps the actor must be an active member; maker-checker blocks the submitter even when they are a legitimate approver; and a rejection configured to "go back a step" on step one has nowhere to go — it degrades to a final rejection.
The decision succeeded but the stamp is missing. Outcome effects are post-decision and best-effort: the field update goes through the normal save pipeline, and an active business rule can reject the stamp itself. Check the audit trail for the stamping save and the entity's rule set — the approval is intact; the follow-up write was blocked.
Common questions
Why not just add an "approved" checkbox instead?
Because a checkbox records nothing: no resolved approver, no notification, no lock while pending, no timestamp, no reason — and anyone with edit rights can tick it. The approval process provides all of those for roughly the same setup effort. If you deliberately choose a checkbox as a lightweight exception, lock it down with field-level security and treat it as the exception, not the pattern; the reasoning is laid out in the customization ladder.
Can anyone edit the record while it is pending?
Not when lock-on-submission is enabled — that is its purpose. Two exemptions exist by design: approval administrators can always edit, and the current approver can when the process explicitly allows approver edits during approval. Everyone else waits for the decision, which is what makes the eventual stamp trustworthy: the record the approver saw is the record that was approved.
What if two approval processes both match a record?
The first active process by process order whose entry condition passes wins, and only it — a record never runs two processes at once, and a record with a pending request cannot be submitted again anywhere. Design overlapping processes so their entry conditions partition the records (by amount band, by record type), and use process order as the tiebreaker for the overlap you cannot eliminate.