You are here:
Record-Triggered Flow Considerations
A record-triggered autolaunched flow makes additional updates to the triggering record before or after it’s saved to the database. Understand the considerations and special behaviors of flows that make before- and after-save updates.
Required Editions
| View supported editions. |
General Considerations
These considerations apply to any record-triggered flows.
- Record-triggered flows run custom validation rules.
- You can’t reference a screen flow from an autolaunched flow.
- Due to their position in the order of execution, record-triggered flows can behave differently from similar workflow rules.
- A flow can't look up an account when a user creates a case from that account if the Case.AccountId field is read only for the running user. For example, when a user creates a case from an account detail page, the Case.AccountId field remains null. The case doesn’t automatically link to the account, so the flow can't use the unpopulated Case.AccountId field to look up the Account record.
- A record-triggered flow fails if it attempts to access external data, such as Data Cloud objects, during its synchronous execution path. It fails because Salesforce prevents callouts to external services from running while a record is saving. To execute flow logic that queries an external data source, use an asynchronous path. On the Start element of your flow, turn on the Add Asynchronous Path toggle under Actions and Related Records to create this path. The asynchronous path runs in the background after the original record save is successfully committed, enabling the external callout.
- Asynchronous paths don’t support the
ISCHANGEDoperator, for example in decision elements. -
Flows that are configured to run on a given object don’t run if that object has a formula field referencing another object and that field is updated on the other object.
For example, consider a record-triggered flow that runs for updated accounts. The Account object contains two custom formula fields:
- Partner Address: A formula field that references the Address field on another account record.
- Contact Phone: A formula field that references the Phone field on a contact record.
Scenario Result The Address field on the second account record is updated. The flow is triggered for both the second account record and the account record that references the Address field. The Phone field on the contact record is updated. The flow isn't triggered, even though the account record that references the Phone field now shows the updated data.
Considerations for Fast Field Updates
These considerations apply to record-triggered flows that are optimized for fast field updates (before-save).
- The flow can’t perform actions other than updating the triggering record’s field values.
- The flow can’t update values in records that are related to the triggering record.
- Only these elements are supported: Assignment, Decision, Get Records, and Loop.
- The View All Data permission is required to activate an autolaunched flow that has a trigger.
This video explains when to use fast field (before-save) updates and when to update actions and related records.
View this video in a separate tab.
Considerations for Debug Mode
- The
ISCLONE()formula function always evaluates toFALSEwhen you’re in debug mode. For example, if a record-triggered flow contains anISCLONE()formula function in the entry criteria or in the Decision element,ISCLONE()evaluates toFALSEeven when you’re debugging with a cloned record.
