🔥
Automation: Flows, Approvals, and Order of Execution
Automation logic, flow triggers, and best practices (the core of the exam).
⏱️ Estimated reading time: 40 minutes
Flow Types: Exam Scenarios
Identifying the right type is the first exam question.
1. Screen Flow: Requires UI. (e.g., Call Script, Survey).
2. Record-Triggered Flow: Automatic on create/edit/delete. (e.g., Update field, Email).
3. Schedule-Triggered Flow: Batch. (e.g., Daily at 8 AM, check overdue tasks).
4. Autolaunched (No Trigger): Background processes invoked by Apex/Buttons.
5. Platform Event-Triggered: External integrations (IoT, ERP).
1. Screen Flow: Requires UI. (e.g., Call Script, Survey).
2. Record-Triggered Flow: Automatic on create/edit/delete. (e.g., Update field, Email).
3. Schedule-Triggered Flow: Batch. (e.g., Daily at 8 AM, check overdue tasks).
4. Autolaunched (No Trigger): Background processes invoked by Apex/Buttons.
5. Platform Event-Triggered: External integrations (IoT, ERP).
🎯 Key Points
- ✓ Screen Flows never trigger alone; they need a human or action
- ✓ Record-Triggered is the direct replacement for Workflow Rules and Process Builder
- ✓ Delete Trigger only works in 'Before Delete'
Critical Optimization: Before-Save vs After-Save
Understanding this is the key to performance.
Fast Field Updates (Before Save):
- Runs BEFORE saving to the database.
- Use: Updating fields on the *same* record that triggered the flow.
- Advantage: 10x faster. Does not cause recursion.
Actions and Related Records (After Save):
- Runs AFTER saving.
- Use: Creating/Updating *other* records (children, parents), sending emails, or complex actions.
- Rule: If you need the record ID (e.g., to create a child), you MUST use After Save.
Fast Field Updates (Before Save):
- Runs BEFORE saving to the database.
- Use: Updating fields on the *same* record that triggered the flow.
- Advantage: 10x faster. Does not cause recursion.
Actions and Related Records (After Save):
- Runs AFTER saving.
- Use: Creating/Updating *other* records (children, parents), sending emails, or complex actions.
- Rule: If you need the record ID (e.g., to create a child), you MUST use After Save.
🎯 Key Points
- ✓ Need to send an email? -> After Save
- ✓ Need to update a field based on another field on the same record? -> Before Save
- ✓ ISCHANGED() and PRIORVALUE() are essential for detecting specific changes
- ✓ Use 'Entry Criteria' so the Flow doesn't run unnecessarily
Flow Anatomy: Variables and Resources
Flows use Resources to handle data.
- Variable: Data container (Text, Number).
- *Available for Input:* Receives external data (e.g.,
- Record Variable: Stores a full record.
- Collection Variable: Stores a LIST of records (vital for Loops).
- Formula: Calculates values dynamically.
Magic Variable: To pass the current record ID to a Screen Flow, the variable MUST be named
- Variable: Data container (Text, Number).
- *Available for Input:* Receives external data (e.g.,
recordId). - Record Variable: Stores a full record.
- Collection Variable: Stores a LIST of records (vital for Loops).
- Formula: Calculates values dynamically.
Magic Variable: To pass the current record ID to a Screen Flow, the variable MUST be named
recordId (exact) and be Input.🎯 Key Points
- ✓ $Record: Global variable with data of the triggering record
- ✓ $Record__Prior: Contains data BEFORE the change
- ✓ $User: Information of the user running the Flow
Loop Logic and 'Bulkification' (The #1 Mistake)
Salesforce has strict limits (Governor Limits).
Cardinal Sin: NEVER put Data elements (Get, Create, Update, Delete) INSIDE a Loop. If you do, the Flow will fail when processing many records.
The Safe Pattern:
1. Loop: Iterate over the list.
2. Assignment: Modify the record in memory and add it to a new collection.
3. Close Loop.
4. Update Records: Run the update ONCE outside the loop using the collection.
Cardinal Sin: NEVER put Data elements (Get, Create, Update, Delete) INSIDE a Loop. If you do, the Flow will fail when processing many records.
The Safe Pattern:
1. Loop: Iterate over the list.
2. Assignment: Modify the record in memory and add it to a new collection.
3. Close Loop.
4. Update Records: Run the update ONCE outside the loop using the collection.
🎯 Key Points
- ✓ DML Limit: Max 150 database calls per transaction
- ✓ Assignment element is the only safe one inside a Loop
- ✓ Bulkification means designing the Flow to handle 1 or 1000 records without breaking limits
Debugging, Errors, and Security Context
Debug on Canvas: Allows testing the Flow simulating another user. Vital to check if permissions affect execution.
Execution Context:
- User Context: Flow respects user permissions. If they can't edit a field, it fails.
- System Context: Flow ignores permissions (God Mode). Record-Triggered Flows always run like this.
Fault Paths: If an element fails (e.g., validation error), you must connect a 'Fault Path' (red line) to an error screen or email to prevent the user from seeing a cryptic technical message.
Execution Context:
- User Context: Flow respects user permissions. If they can't edit a field, it fails.
- System Context: Flow ignores permissions (God Mode). Record-Triggered Flows always run like this.
Fault Paths: If an element fails (e.g., validation error), you must connect a 'Fault Path' (red line) to an error screen or email to prevent the user from seeing a cryptic technical message.
🎯 Key Points
- ✓ Rollback Mode: Runs the test without saving changes to the database
- ✓ Failed Flows send an email to the admin with technical details
- ✓ Screen Flows run by default in User Context (depending on who uses it)
Distribution: How do users see Screen Flows?
Creating a Screen Flow doesn't make it visible automatically.
Distribution Methods:
1. Lightning Pages: 'Flow' component in App Builder.
2. Quick Actions: Custom button (Ideal for Mobile).
3. Utility Bar: Fixed bottom bar.
4. Experience Cloud: External portals.
Note: Users need the 'Run Flows' permission in their profile.
Distribution Methods:
1. Lightning Pages: 'Flow' component in App Builder.
2. Quick Actions: Custom button (Ideal for Mobile).
3. Utility Bar: Fixed bottom bar.
4. Experience Cloud: External portals.
Note: Users need the 'Run Flows' permission in their profile.
🎯 Key Points
- ✓ You can control Flow component visibility on the page with filters (e.g., Hide if Status = Closed)
- ✓ Active Flows cannot be edited, you must save a new version
Approval Processes and Migration
Approval Processes: Unique due to Record Locking.
- Steps: Entry -> Lock -> Approval (Unanimous vs First) -> Actions.
- Delegated Approver: A user can designate a temp substitute.
Migration: 'Migrate to Flow' tool converts Workflow Rules and Process Builder to Flow. Cannot migrate everything (e.g., SOAP outbound messages).
- Steps: Entry -> Lock -> Approval (Unanimous vs First) -> Actions.
- Delegated Approver: A user can designate a temp substitute.
Migration: 'Migrate to Flow' tool converts Workflow Rules and Process Builder to Flow. Cannot migrate everything (e.g., SOAP outbound messages).
🎯 Key Points
- ✓ A Flow can 'submit' a record for approval (Action: Submit for Approval)
- ✓ Approval History is a mandatory related list
- ✓ Initial Submission Actions happen upon clicking 'Submit'
Order of Execution: The Final Hierarchy
Memorize this order for the exam:
1. Validation Rules: The first filter.
2. Before-Save Flows: Fast optimization.
3. Duplicate Rules: Does it exist?
4. Save to DB: Written (no commit).
5. After-Save Flows: Heavy automation.
6. Assignment Rules: Assign owner.
7. Auto-Response Rules.
8. Workflow Rules / Process Builder.
9. Escalation Rules.
10. Roll-up Summary: Parent calculations.
11. Commit: Final save.
1. Validation Rules: The first filter.
2. Before-Save Flows: Fast optimization.
3. Duplicate Rules: Does it exist?
4. Save to DB: Written (no commit).
5. After-Save Flows: Heavy automation.
6. Assignment Rules: Assign owner.
7. Auto-Response Rules.
8. Workflow Rules / Process Builder.
9. Escalation Rules.
10. Roll-up Summary: Parent calculations.
11. Commit: Final save.
🎯 Key Points
- ✓ If a Flow updates a field, Validation Rules run AGAIN
- ✓ Before-Save Flows avoid the re-validation cycle because they happen before save
- ✓ Assignment Rules run AFTER Flows (The Flow sees the original owner)