Approval Processes: Steps, Approvers and Actions

Why This Topic Matters

Approval Processes are one of the most heavily tested areas within the Advanced Process Automation section of the Salesforce Advanced Administrator exam. Organizations rely on approval processes to enforce governance over discounts, expense claims, time-off requests, contract terms, and many other business decisions. As an Advanced Administrator you are expected to go beyond simply creating an approval process: you must understand how entry criteria, approval steps, approver selection, and the four categories of actions interact so you can design, troubleshoot, and optimize them. Exam questions frequently present a business scenario and ask you to identify the correct configuration, predict the outcome of a given setup, or diagnose why a record did or did not reach a particular approver.

What Is an Approval Process?

An approval process is an automated workflow that defines how a record is submitted for approval, who must approve it at each stage, and what happens to the record at every point in its lifecycle. It consists of:

• Entry criteria – the conditions a record must meet to enter the process (formula or criteria-based).
• Process properties – record editability during approval, initial submitter settings, email templates, and the approval page layout.
• Approval steps – ordered stages, each with its own step criteria, assigned approver(s), and rejection behavior.
• Actions – automated tasks that execute on initial submission, approval, rejection, and recall.

Only one approval process per object evaluates a record at a time. When a record is submitted, Salesforce evaluates active approval processes in the order they are listed and uses the first one whose entry criteria the record meets.

How It Works: Approval Steps

Each approval process contains one or more steps. For each step you define:

1. Step criteria – Determines whether the record enters that step. Options are: all records enter this step; records meeting criteria enter this step; or a formula evaluates to true. If a record does not meet the criteria for a step, you can choose to approve it automatically, reject it, or skip to the next step (the skip option is available only on steps after the first).

2. Assigned approver – Who receives the approval request. Options include:
• Let the submitter choose the approver manually
• Automatically assign using the user field selected earlier (e.g., Manager field on the User record, or a custom hierarchical relationship field) – the Next Automated Approver Determined By setting on the process itself
• Automatically assign to approver(s) – specific users, a queue (queues are supported only for objects that support queues), or related users such as record owner or creator. When multiple approvers are listed, you choose Unanimous (all must approve) or First Response (the first approver's decision wins). You can list up to 25 approvers per step.

3. Delegated approver – Each step can optionally allow the approver's delegate (set on the user's Delegated Approver field) to approve. Delegates cannot reassign requests and cannot approve requests for processes where the step does not allow delegate approval.

4. Rejection behavior – For steps after the first, you can choose Perform all rejection actions for this step AND all final rejection actions (final rejection) or Perform ONLY the rejection actions for this step and send the approval request back to the most recent approver (go back one step). The first step always performs final rejection.

How It Works: Actions

There are four categories of actions, each able to use Email Alerts, Field Updates, Tasks, and Outbound Messages (up to 40 actions total per action list, 10 of each type):

• Initial Submission Actions – Run when a record is first submitted. The default is a record lock. Commonly used to set a Status field to Pending Approval.
• Approval Actions (per step) – Run when a step is approved. Useful for notifying stakeholders or updating interim status fields.
• Rejection Actions (per step) – Run when a step is rejected.
• Final Approval Actions – Run when the record is approved at the last step. Default is a record lock; you can choose to lock or unlock the record. Often used to set Status to Approved.
• Final Rejection Actions – Run when the record is finally rejected. Default unlocks the record. Often used to set Status to Rejected.
• Recall Actions – Run when the submitter (or an administrator) recalls the record from the approval process. Default unlocks the record. Recall must be enabled in the process properties (Allow submitters to recall approval requests).

Key Process Properties to Remember

• Record Editability – Administrators ONLY can edit records during the approval process or Administrators OR the currently assigned approver can edit records.
• Initial Submitters – Who may submit the record: record owner, record creator, specific users, roles, public groups, etc. Only these users see the Submit for Approval button.
• Approval Assignment Email Template – Sent to approvers when a request is assigned.
• Approval Page Layout – Fields the approver sees when reviewing, plus whether approval history is displayed.
• Email Approval Response – When enabled org-wide, approvers can reply with APPROVE/APPROVED/YES or REJECT/REJECTED/NO.
• Approvals in Chatter – Allows approvers to act directly from a Chatter feed post.
• Activation – A process must have at least one step before it can be activated. Once activated, you cannot add, delete, or reorder steps; you must clone the process to make structural changes. You can still edit actions and some step details.

Important Behaviors and Limitations

• A record locked by an approval process can only be edited by administrators (users with Modify All Data or the object's Modify All permission) or the current approver, depending on the editability setting.
• Field updates in approval processes can trigger workflow rules if Re-evaluate Workflow Rules after Field Change is enabled; they also fire triggers and flows.
• You cannot have more than 30 steps per process and the overall limit of active approval processes per object is governed by edition (typically 300 active across the org, 30 active per object).
• Approval history is stored in the ProcessInstance, ProcessInstanceStep, and ProcessInstanceWorkitem objects and is reportable via the Approval History report type.
• If the Manager field is used for approver routing and a user's Manager is blank, the submission fails unless a different approver is defined or the step uses a different routing method.
• Users can be configured as Delegated Approvers but a delegate inherits only approval ability, not reassignment rights.
• Mass approval is possible from the Items to Approve home page component or list views.

Approval Processes vs. Flow Approvals

The exam may reference the newer Flow Orchestration and approval capabilities, but the classic Approval Process remains the primary feature tested. Know that approval processes are declarative, object-specific, and limited to the four action types, whereas Flow can call an approval process via the Submit for Approval core action and perform more complex branching logic. If a question needs multi-object logic or dynamic conditions beyond step criteria, Flow or Flow Orchestration is likely the intended answer; if it asks about enforcing a review chain with locking and approval history, the classic approval process is correct.

Exam Tips: Answering Questions on Approval Processes: Steps, Approvers and Actions

1. Read for the four action categories. When a scenario says "when the record is submitted," think Initial Submission Actions. "When the final approver approves" means Final Approval Actions. "If any approver rejects and it should be sent back" points to step-level rejection behavior with go back one step.

2. Distinguish Unanimous from First Response. If the requirement says "all three managers must agree," choose Unanimous. If "any one of the regional directors can approve," choose First Response. Queues are a common distractor; remember queues are only available for objects that support them (Leads, Cases, custom objects, etc.).

3. Know what cannot change after activation. Questions that ask how to add a new step to an active process expect you to answer: clone the process (or deactivate, but you still cannot add steps to a previously activated process). This is a frequent trick question.

4. Record locking is the default. If a question asks why users cannot edit a record in approval, the answer is the record lock from Initial Submission. If sales reps need to edit while pending, the fix is the Administrators OR the currently assigned approver editability setting or an unlock field update – not a permission change.

5. Manager field routing requires populated data. If submissions fail for some users, check whether the Manager field (or custom hierarchy field) is blank on their User record.

6. Delegated approvers have limited power. They can approve or reject only if the step allows delegate approval, and they cannot reassign.

7. Entry criteria order matters. When multiple active approval processes exist on one object, only the first matching process (by order) is used. Questions about the "wrong process firing" are solved by reordering or tightening entry criteria.

8. Recall must be explicitly enabled. If a scenario mentions submitters needing to withdraw a request, verify Allow submitters to recall approval requests is checked; otherwise only administrators can recall.

9. Skip step is only available after step one. If a question involves conditionally bypassing the first step, the only options are approve or reject the record – you cannot skip it.

10. Reporting on approvals uses the Approval History report type or the Process Instance objects. Standard object reports will not show approver names and comments.

11. Eliminate answers that overbuild. If a requirement can be met with a single field update in a Final Approval Action, an answer involving Apex or a complex flow is a distractor.

12. Watch for "after approval" automation chains. A field update in Final Approval Actions can trigger a record-triggered flow or workflow rule, which can be the intended mechanism for downstream automation.

Summary

Mastering approval processes means understanding the lifecycle: entry criteria admit the record, initial submission actions lock and tag it, steps route it to approvers based on criteria and routing methods, step-level actions fire on each decision, and final approval, final rejection, or recall actions close the loop. Pay careful attention to approver assignment options, rejection behavior, record editability, and the post-activation restrictions. When answering exam questions, map each phrase in the scenario to the specific configuration element it describes, eliminate distractors that require code or unnecessary complexity, and remember the limitations that commonly appear as trick questions.