Approval Architecture, Governance & Operations

A Salesforce approval process is a control system—not a status change

JSBC Labs5 November 20268 min read

A green status can conceal a weak control

A discount request reaches Approved, so downstream automation creates an order and finance assumes the decision was valid. Later, the team discovers that the approver was covering a queue, never saw the margin calculation and approved after the commercial terms changed. Salesforce recorded an outcome, but the organisation cannot show that the right authority evaluated the right evidence at the right time.

The JSBC Labs position is that an approval process is a control system. Its job is to define decision rights, protect the decision state, preserve evidence, route exceptions and make delay visible. A status field is only one output of that system. Treating approval as a field update produces attractive diagrams while leaving identity, timing, failure and operational ownership undefined.

Define the decision before choosing the automation

Start with the decision: what risk is being accepted, who is accountable, which evidence is mandatory, what threshold changes the authority and how long is the decision valid? Separate approval from acknowledgement, review and execution. A legal reviewer may confirm clause compliance without authorising price; finance may approve exposure without confirming that an order is ready to fulfil. One ambiguous Approved value cannot represent those distinct responsibilities.

Then choose the platform mechanism. Salesforce documents classic approval processes as object-specific chains of steps and actions. Flow Approval Processes add stages, approval and background steps, decisions, record-triggered or invoked starts, fault handling and richer operational records. That does not make every classic process obsolete. Use the simplest mechanism that expresses the control, but do not compress a multi-party, multi-system decision into a simple route merely because it is quicker to configure.

Make submission a contract

Entry criteria should describe a complete, reviewable state. Validate required evidence, ownership, amounts, dates and exception reasons before submission. Capture the values that determined the route, not just the record ID. If a request can be resubmitted, define whether prior decisions remain visible, whether the authority is recalculated and which material changes invalidate an earlier approval. Otherwise users can obtain approval and then change the proposition underneath it.

Classic approval processes lock a submitted record by default, and Salesforce lets administrators decide whether the assigned approver can also edit it. Flow Approval Processes require deliberate record-locking design, especially when steps run concurrently. A lock is useful, but it is not a complete integrity model: it does not automatically freeze every related record, external quotation or calculated input that informed the decision. Identify the full evidence boundary and either snapshot it or detect change before completion.

Route authority, not merely work

Routing rules encode the organisation's authority model. Decide when assignment follows a manager hierarchy, named role, queue, related-record owner or explicit policy table. Salesforce supports assigned approvers, queues and delegated approvers in its approval capabilities, but delegation should not silently bypass separation of duties. A delegate may be operationally available yet still lack the independence, geography or financial mandate required for the decision.

Design for absence and organisational change. Define who maintains authority data, how a departed employee's work is reassigned, when a queue is appropriate and who monitors unclaimed items. Put monetary and risk thresholds in governed configuration where feasible, with effective dates and review ownership. Avoid hard-coded individuals. Every routing branch should answer two questions: why was this person authorised, and who is responsible if nobody acts?

Treat outcomes as business events

Approved, rejected, recalled, canceled and error are different outcomes. Flow Approval Processes expose distinct approval-submission states, while classic processes provide initial submission, step, final approval, final rejection and recall actions. Model each path explicitly. Rejection may require correction and resubmission; recall may invalidate open work; cancellation may be an administrator's intervention; error means the control did not reach a decision at all.

Keep consequential side effects behind a clearly completed outcome. In Flow Approval Processes, Salesforce recommends background steps for related updates and notifications rather than embedding unrelated work in an approver's screen action. For classic processes, final actions can update fields, send alerts, create tasks or send outbound messages. In either model, make external calls idempotent and reconcile ambiguous failures. The approval decision and the successful execution of its consequences are separate facts.

Operate the approval queue as production work

An approval system can be logically correct and operationally useless. Measure time to first action, age by stage, reassignment rate, rejection and recall rate, fault count and the share completed by delegates. Segment by process, risk tier, business unit and approver group. Flow Approval Processes provide approval submissions, work items and associated orchestration runs that can support this operating view; classic processes have process instances and work items that likewise need ownership.

Set service expectations by business impact, not one universal reminder. A high-value deal expiring today and a low-risk policy exception should not compete blindly in the same queue. Define reminders, escalation, reassignment and an emergency path with documented conditions and retrospective review. Do not auto-approve because a timer expired unless the business has explicitly accepted that risk. Silence is not consent, and an overdue control should become visible rather than disappear.

Preserve evidence that explains the decision

A defensible record needs the submitter, approver, timestamps, decision, comments, route and relevant evidence version. Salesforce stores Flow Approval Process submission comments, work-item comments and recall or cancellation comments in different approval records. Classic approvals create process instances and step records. Design reporting and retention around those actual objects instead of assuming one history related list tells the whole story.

Require structured reason codes where they aid review, while retaining free text for context. Link the approval to the policy version, calculation, contract or risk assessment that informed it. Restrict access to sensitive comments and evidence, and define retention and deletion obligations. Approval history can demonstrate who clicked a button; it becomes useful control evidence only when the organisation can also explain what they were authorised to decide and what information they considered.

Test the control, then govern its evolution

Test more than the happy route. Cover boundary amounts, missing authority, delegates, unanimous and first-response rules where used, rejection, recall, cancellation, reassignment, concurrent steps, record changes during review, background-step failure and duplicate submission. Assert both the decision record and downstream effects. For Apex submission or processing, inspect Approval process results and handle per-request failures; Salesforce documents approval processing as DML-governed work, not a cost-free control call.

Version the process, its called flows and its policy configuration together. Before activation, prove what happens to in-flight work and how operators distinguish old and new rules. Review routing and ageing metrics after release, sample decisions against policy and retire obsolete definitions deliberately. The standard is not that records reach Approved. It is that every consequential decision has valid authority, stable evidence, controlled side effects and an accountable path when the process stalls or fails.