A strong multi-step example is a Capex Purchase Request flow where the approval chain expands based on the dollar amount, conditionally skips steps, and routes to different finance owners depending on the cost center.
The scenario
A Purchase_Request__c custom object holds:
Amount__c(currency)Cost_Center__c(lookup to a Cost Center)Submitter__c(the requesting user)
Business rules:
| Amount range | Approval chain |
|---|---|
| ≤ $5,000 | Department head only |
| $5,001 – $25,000 | Department head → Finance Manager |
| $25,001 – $100,000 | Department head → Finance Manager → CFO |
| > $100,000 | Department head → Finance Manager → CFO → CEO |
Additional rules:
- Marketing department requests skip the Finance Manager step (they have their own approval flow)
- Capital projects (
Cost_Center__c.Type__c = "Capital") always go to CFO regardless of amount - The submitter cannot be the approver at any step (cycle prevention)
How it maps to Approval Process configuration
| Step | Approver | Entry/Skip criteria |
|---|---|---|
| Initial submission | Submit by Owner | Lock record |
| Step 1: Department head | Manager of submitter | Always |
| Step 2: Finance Manager | Specific user (or queue) | Skip when Amount <= 5000 OR Department = "Marketing" |
| Step 3: CFO | Specific user | Skip when Amount <= 25000 AND Cost_Center__r.Type__c != "Capital" |
| Step 4: CEO | Specific user | Skip when Amount <= 100000 |
The “skip” expression on each step is what makes this declarative.
Actions on each outcome
| When | Actions |
|---|---|
| Initial submit | Lock record; email submitter; email Step 1 approver |
| Final approval | Field update Status = "Approved"; email submitter; create related Purchase_Order__c via Flow |
| Any rejection | Unlock record; email submitter with rejection reason; field update Status = "Rejected" |
| Recall | Unlock; clear pending step; field update Status = "Recalled" |
Why this is a good interview answer
- It shows you understand step entry/skip criteria (the “if this step’s criteria are not met, skip it” mechanism)
- It demonstrates dynamic approver assignment —
Manager, named users, queues - It shows conditional routing based on multiple fields, not just amount
- It mentions Flow integration for post-approval side-effects (PO creation)
Modern variant: Flow Orchestrator
For really complex multi-team approvals — where each step might be a multi-day collaborative process, not just a click — Salesforce 2026 recommends Flow Orchestrator. It lets you build stages, with steps inside each stage, where each step can be a Screen Flow assigned to a user or group.
What interviewers want
- A scenario with at least 3 levels of approval
- Conditional skips based on entry criteria
- Different approver patterns (manager-based, named user, queue)
- Bonus: mention Flow Orchestrator as the modern alternative for the most complex cases
Verified against: Salesforce Help — Approval Process Considerations. Last reviewed 2026-05-17 for Spring ‘26 release.