Record-Triggered Flows

Record-Triggered Flows – Salesforce Platform Developer 1 Exam Guide

Record-Triggered Flows are one of the most important automation tools on the Salesforce Platform. For the Platform Developer 1 exam, understanding how they work, when they execute, and how they interact with the order of execution is essential. This guide covers everything you need to know.

Why Are Record-Triggered Flows Important?
Record-Triggered Flows are Salesforce's recommended declarative automation tool, effectively replacing Workflow Rules and Process Builder. Salesforce has invested heavily in Flow as the future of automation, which means:
- They are a core topic on the Platform Developer 1 exam.
- As a developer, you must understand how they interact with Apex triggers and the broader order of execution.
- Knowing when to use a Record-Triggered Flow versus Apex is a key competency tested on the exam.
- They allow admins and developers to automate complex business logic without writing code, following Salesforce's "clicks not code" philosophy.

What Are Record-Triggered Flows?
A Record-Triggered Flow is a type of flow that automatically fires when a record is created, updated, or deleted. Think of them as the declarative equivalent of an Apex trigger. They allow you to:
- Evaluate criteria on the triggering record.
- Execute logic such as creating, updating, or deleting related records.
- Perform actions before or after the record is saved to the database.
- Call Apex actions, send emails, post to Chatter, and more.

Record-Triggered Flows can be configured to run in three different optimization modes:

1. Fast Field Updates (Before Save)
- Runs before the record is saved to the database.
- Can only update fields on the triggering record (the record that caused the flow to run).
- Does NOT allow you to create, update, or delete other records.
- Does NOT allow you to perform actions like sending emails or calling Apex.
- This is the fastest and most efficient option because it does not require additional DML operations — the changes are saved as part of the same transaction that saves the triggering record.
- Analogous to a before trigger in Apex.

2. Actions and Related Records (After Save)
- Runs after the record is saved to the database.
- Can update the triggering record as well as create, update, or delete other records.
- Can execute actions like sending emails, calling Apex invocable methods, posting to Chatter, etc.
- Analogous to an after trigger in Apex.
- Because the record has already been committed, updating the triggering record here results in an additional DML operation.

3. Run Asynchronously (After Save — Async Path)
- Available as a scheduled or asynchronous path within a Record-Triggered Flow.
- Runs outside the original transaction in a separate context.
- Useful for non-time-critical operations or operations that might hit governor limits if run synchronously.
- Includes Scheduled Paths, which allow you to run flow logic at a specific time relative to the triggering record (e.g., 3 days after the record's CreatedDate).

How Record-Triggered Flows Work in the Order of Execution
Understanding where Record-Triggered Flows fit in Salesforce's order of execution is critical for the exam:

1. System validation rules run.
2. Before-save Apex triggers execute.
3. System validation and custom validation rules run.
4. Duplicate rules execute.
5. Record-Triggered Flows (Before Save / Fast Field Updates) execute.
6. The record is saved to the database (but not yet committed).
7. After-save Apex triggers execute.
8. Assignment rules, auto-response rules, and workflow rules execute.
9. Record-Triggered Flows (After Save) execute.
10. Entitlement rules execute.
11. Roll-up summary fields are calculated.
12. Cross-object workflow rules execute.
13. The transaction is committed to the database.
14. Post-commit logic runs (e.g., sending emails, async paths/scheduled paths).

Key Takeaway: Before-save flows run after before-save Apex triggers and after validation rules. After-save flows run after after-save Apex triggers.

Entry Criteria and Conditions
When configuring a Record-Triggered Flow, you define:
- Object: The sObject the flow triggers on (e.g., Account, Opportunity).
- Trigger Event: When the flow fires — A record is created, A record is updated, A record is created or updated, or A record is deleted.
- Entry Conditions: Optional conditions that must be true for the flow to run (similar to trigger criteria).
- When to Run: You can choose to run the flow only when a record is created or updated to meet the condition requirements, or every time a record is updated and meets the conditions. This is important for preventing the flow from re-executing unnecessarily.

Key Flow Elements You Should Know
- Decision Element: Evaluates conditions and branches logic (like an if/else statement).
- Assignment Element: Sets or modifies variable values.
- Get Records: Queries records from the database (like a SOQL query).
- Create Records: Inserts new records.
- Update Records: Updates existing records.
- Delete Records: Deletes records.
- Loop Element: Iterates over a collection of records.
- Invocable Apex: Calls an Apex method annotated with @InvocableMethod.

$Record and $Record__Prior
Record-Triggered Flows provide two important global variables:
- $Record: Represents the current state of the triggering record (new values).
- $Record__Prior: Represents the state of the record before the update (old values). This is only available when the trigger event includes updates. It is analogous to Trigger.oldMap in Apex.

These are extremely useful for checking whether a specific field value has changed, which is a common exam scenario.

Governor Limits and Bulkification
Record-Triggered Flows operate within the same governor limits as the overall transaction. Key points:
- Flows are bulkified automatically. When multiple records trigger the flow (e.g., from a Data Loader import), the flow interviews are batched and the DML and SOQL operations are bulkified to minimize governor limit consumption.
- However, poorly designed flows can still hit limits. For example, placing a Get Records element inside a Loop element is an anti-pattern that can cause SOQL query limit exceptions — just like a SOQL query inside a for loop in Apex.
- Each flow interview in a before-save context does NOT count as a separate DML operation because the update is bundled with the triggering save.

Record-Triggered Flows vs. Apex Triggers
The exam may test your ability to decide when to use one over the other:

Use Record-Triggered Flows when:
- The logic is straightforward (field updates, creating related records, sending notifications).
- You want maintainability by admins.
- The requirements can be met declaratively.

Use Apex Triggers when:
- Complex business logic is required that cannot be easily expressed in a flow.
- You need fine-grained control over error handling, custom exceptions, or complex data structures.
- Performance is critical and you need to optimize SOQL/DML manually.
- You need to interact with external systems synchronously during the save transaction.

Common Exam Scenarios
1. Scenario: A field on the triggering record needs to be updated before it is saved. Answer: Use a Before-Save Record-Triggered Flow (Fast Field Updates).
2. Scenario: A child record needs to be created when a parent record is inserted. Answer: Use an After-Save Record-Triggered Flow.
3. Scenario: A notification needs to be sent 7 days after a Case is created if it is still open. Answer: Use an After-Save Record-Triggered Flow with a Scheduled Path.
4. Scenario: You need to check if a field value changed from one specific value to another. Answer: Use $Record and $Record__Prior in the entry conditions or a Decision element.
5. Scenario: You need to prevent a record from being saved based on a condition. Answer: While you can use a fault path or a custom error in Apex, in a before-save flow you can add a custom error message using the Add a custom error message feature to block the save declaratively.

Exam Tips: Answering Questions on Record-Triggered Flows

1. Know the order of execution cold. Many questions test whether you understand when before-save flows run relative to validation rules, before triggers, and after triggers. Remember: before-save flows run AFTER validation rules and AFTER before-save Apex triggers.

2. Before Save = Fast Field Updates on the triggering record ONLY. If a question mentions updating a related record or creating a new record, the answer is NOT a before-save flow. It must be an after-save flow.

3. $Record__Prior is only available on update triggers. If a question asks about detecting field changes, look for answers that reference $Record__Prior. It is not available for record creation because there is no prior state.

4. Watch out for governor limit traps. If a question describes a flow with a Get Records inside a Loop, recognize that as an anti-pattern. The correct answer will typically involve moving the query outside the loop or using a collection variable.

5. Understand the difference between "Only when a record is updated to meet the condition" and "Every time a record is updated and meets the condition." The first option means the flow runs only when the record transitions into meeting the criteria (like a trigger that checks old vs. new values). The second means it runs every time the record is saved and the criteria are met, regardless of whether the values changed.

6. Scheduled Paths run asynchronously. They do NOT run in the same transaction. If a question asks about immediate real-time updates, scheduled paths are not the answer.

7. Flows respect sharing rules when run in User context, but can be set to run in System context. Be aware of the "Run flow as" setting. By default, Record-Triggered Flows run in System context without sharing, meaning they can access all records regardless of the running user's permissions. However, Salesforce provides the option to run in System context with sharing or User context.

8. Declarative-first principle. Salesforce exam questions tend to favor declarative solutions. If a scenario can be solved with a Record-Triggered Flow, that is usually the preferred answer over writing Apex — unless the question specifies complexity that requires code.

9. Pay attention to the trigger event. Questions may describe a scenario where a flow should only fire on record creation, not on updates. Make sure the trigger event matches the scenario described.

10. Recursion awareness. If a Record-Triggered Flow updates its own triggering record in an after-save context, it can potentially re-trigger itself. Salesforce has built-in recursion prevention (a flow won't re-trigger itself in the same transaction for the same record by default), but the exam may test your awareness of this behavior.

11. Read the question carefully for keywords. Words like "immediately," "before the record is committed," "after the record is saved," "without code," and "declaratively" are strong hints pointing toward specific flow configurations.

12. Remember that Record-Triggered Flows have replaced Process Builder and Workflow Rules. If a question asks about the recommended automation tool, the answer is almost always Flow — not Process Builder or Workflow Rules, which are no longer recommended for new automation.

By mastering these concepts and tips, you will be well-prepared to tackle any Record-Triggered Flow question on the Salesforce Platform Developer 1 exam.