5.2 Approval Processes & Business Rules

5.2 Approval Processes & Business Rules

Quick Answer: A Salesforce Approval Process is declarative multi-step routing: entry criteria decide whether a record can enter, initial submitters who may start it, steps assign approvers and optional criteria, and actions run on approve, reject, recall, and final outcomes. Prefer approvals when you need locking, history, email-style notifications, and admin-owned routing; use Apex or hybrid patterns when routing rules, dynamic approver graphs, or bulk behaviors exceed what the approval engine expresses cleanly.

Approvals sit beside Flow, validation rules, and Apex in the Process Automation toolkit. Platform Developer I expects you to know the structure of an approval process, what happens on submit/approve/reject/recall, and when the standard engine is the “best” solution versus custom logic.

Anatomy of an Approval Process

Think of an approval process as a configured state machine on one object (for example, Opportunity discount requests, Expense__c, or Quote).

1. Entry criteria

Formula or filter criteria that a record must satisfy to be eligible to enter the process. Entry criteria do not automatically submit the record—they gate whether submission is allowed when someone (or automation) tries to submit.

Examples:

• Opportunity Amount > 50000 and StageName in negotiation stages
• Custom object Status__c = 'Submitted' only after a Screen Flow sets that status
• Record type or region fields that segment which process applies (orgs often use one active process per object carefully, or mutually exclusive entry criteria across processes)

If multiple approval processes exist on an object, Salesforce evaluates them in a defined order and uses the first matching process—design exclusive criteria to avoid surprises.

2. Initial submitters

Who is allowed to submit the record into the process: record owner, creator, members of a public group or role, or other configured users. Submitters are a security and process-control concept: even if a user can edit the record, they may not be allowed to start approval.

Submission can come from:

• The standard Submit for Approval button/UI
• Declarative automation (for example, an after-save Flow action that submits for approval)
• Apex using approval process APIs (Approval.ProcessSubmitRequest and related classes)

3. Approval steps

Each step defines:

• Optional step criteria (which records enter this step versus skip/go elsewhere, depending on configuration)
• Assigned approvers (user, manager hierarchy, related user field, queue, or manually chosen in some designs)
• Whether unanimous or first response patterns apply when multiple approvers are involved (per product options)
• Step-level approval and rejection actions (field updates, email alerts, tasks, outbound messages, and related action types available to approvals)

Steps chain: step 1 manager → step 2 finance → step 3 VP, for example. Skipping logic and criteria-based routing keep simple branches declarative without writing a custom router.

4. Final approval and final rejection actions

When the process completes successfully or fails overall:

Final actions are where business systems often stamp terminal statuses that other automation (Flow, validation, reporting) depends on—coordinate those statuses carefully.

5. Record locking

While a record is in an approval process, Salesforce locks it so most users cannot edit fields and bypass the path. Administrators and users with appropriate permissions may still act; understand that locking is a core reason approvals beat “please don’t edit” social rules. Designers choose unlock behavior on final approval/rejection as part of process configuration.

6. Approval history

The platform tracks who submitted, who approved or rejected, comments, and timestamps. That history is valuable for audit and compliance scenarios—another reason to prefer standard approvals over opaque custom status fields alone when auditability is required.

Business Rules That Interact with Approvals

Approvals do not live in isolation. Platform Developer scenarios often combine them with other declarative rules.

Validation rules

Validation rules still enforce data quality when approval actions or users attempt field updates. If a final approval action sets a field to a value that violates a validation rule, the update fails and the process can error. When designing approval field updates:

• Ensure action values are valid for all entry paths
• Avoid validation rules that block legitimate approval stamps (or include exceptions for status transitions)
• Remember that before-save Flows and triggers on related updates may also fire depending on what the action changes

Formula fields, roll-ups, and path/UI

Approvals often key off formula-driven thresholds (discount percent, risk score). Roll-up summaries on parents can drive entry criteria on parent records. Lightning Path and page layouts should surface status and approval-related fields so users understand why Submit is available or blocked.

Workflow-style actions inside approvals

Approval actions historically resemble workflow actions (field update, email alert, task, outbound message). On the exam, treat them as configured outcomes of approve/reject/recall/final, not as a reason to build a parallel Workflow Rule that duplicates the same field update.

Flow alongside approvals

Common hybrid:

1. Screen Flow gathers justification and sets Ready_for_Approval__c
2. Validation rules ensure required attachments/fields
3. User or Flow submits for approval
4. Final approval actions set Approved__c and unlock
5. After-save Flow on the approved status creates provisioning records

Keep a single source of truth for “who approves” (the approval process) and let Flow handle rich pre/post work.

Interplay with Apex

Developers still touch approvals when:

• Programmatic submit is required after complex Apex calculations
• ProcessSubmitRequest / ProcessWorkitemRequest patterns approve or reject in bulk or from integration users
• Dynamic approver determination is too complex for static steps (though many “dynamic” needs are still met with user hierarchy or related user fields)
• Packageable products must automate approval without relying on a specific admin-clicked button

Apex does not replace the approval engine lightly: re-implementing multi-step email, locking, and history is expensive and error-prone. Prefer submit into a declarative approval process from Apex when the routing itself is standard.

Also remember governors and bulkification: submitting hundreds of records in a loop without bulk-friendly patterns can hit limits—same discipline as other DML-adjacent platform features.

When Approval Processes Beat Custom Coded Routing

Choose standard Approval Processes when most of these are true:

• Multi-step human approval with clear assignees (manager, queue, named roles)
• Need for record lock during review
• Need for approval history and comments
• Email notifications and simple field updates on approve/reject are enough
• Admins must adjust steps, email templates, or entry criteria without deployments every time
• Compliance stakeholders expect a recognizable Salesforce approval trail

Choose custom routing (status fields + Flow/Apex, custom LWC consoles, or external BPM) when:

• Approver graphs are highly dynamic, graph-shaped, or data-driven beyond step criteria
• You need parallel complex branches, SLA engines, or external system human tasks as the system of record
• Bulk automated “approvals” without humans make the approval engine the wrong metaphor
• UI must be a fully custom worklist outside standard approval interfaces

Exam “best solution” framing

If the stem says managers must approve discounts over 20%, the record should not be editable mid-process, and email goes to the approver—Approval Process is the answer, not a before trigger that sets a checkbox. If the stem requires evaluating a recursive product configuration and then calling an external credit API before choosing one of twenty regional approvers from custom metadata with complex tie-breakers, lean Apex (possibly still submitting to an approval step once the assignee is known).

Design Pitfalls

• Overlapping entry criteria across multiple processes on one object
• Final approval field updates that fight validation rules or after-save Flows (infinite bounce of status values)
• Forgetting initial submitters—users cannot submit and blame “broken” automation
• Using approvals only to send email when a simple Flow email alert would suffice (overkill)
• Coding a custom lock flag instead of using real approval locking

Summary Map for Study

Master this structure, the validation/Apex interactions, and the “when not to reinvent routing” judgment call, and approval questions become pattern recognition rather than Setup menu memorization.