You can trigger flows in the following ways:
- When a record is created or saved.
- On a schedule
- In response to a received platform event.
Official documentation for triggers includes the following:
- This start node
- This page on Before-Save Triggers
- This page of considerations focuses on Before-Save Updates
These features are not yet covered in the reference documentation but are discussed in release notes:
Considerations when using Before-Save Triggers
Normally, if you want to update a record, you use the Update Records element. But with a Flow that’s triggered by a Before-Save Trigger, the update will happen automatically and you should not try to add an Update Record element to it.
A before-save flow also runs up to 10 times faster than other record update measures (See the Salesforce documentation here.
The “Run Asynchronously” Option
This checkbox shows up in trigger criteria for Record Change triggers:
There are two key reasons to use this option, and both of them involve addressing long-time idiosyncracies of the Salesforce platform:
- If you want to trigger a flow from a record change and then make a callout to another web service (Slack, Jira, AWS, for example…)
- If you want to trigger on one record (say, an Opportunity), and modify another record (say, a User) from a special set of Setup records that are related to permissions.
Both of these are straightforward to do in a flow that doesn’t trigger on a record change or schedule, so why do they require special action here?
The answer is that Salesforce won’t let you create a new transaction while you have an old transaction open, and triggers can be thought of as an open transaction.
Putting these activities on the Run Asynchronously path causes Salesforce to put them in a lower priority queue that gets handled separately from the open trigger transaction. This queue generally gets handled so quickly that you won’t even notice it, but the covenant about all asynchronous operations is that there’s no guarantee and in certain load conditions, the path’s execution may be delayed. Note that you can monitor the progress of any asynchronous work in the Time-Based Workflows page:
When checking Run Asynchronously, keep in mind this guidance:
Configure the flow to “run only when a record is updated to meet the condition requirements”, or select the Is Changed operator in a condition.
This constraint prevents the trigger from firing too frequently.
Comparing “Run Asynchronous” Path with Scheduled Paths
You can create a Scheduled Path that behaves similarly to the new Run Asynchronous path by setting the scheduled path to execute “0” time units aver the triggering update. So what are the differences?
Run Asynchronous is generally faster, because it usually executes within a second, while the scheduled paths usually execute roughly a minute later. These subtle differences also manifest in batching: Run Asynchronously runs with the same ‘cohort’ as the save, while ‘0 Minute Scheduled Paths’ runs with everything compatible that comes due at that 1 minute boundary (up to maximum batch size, default is 200).
Order of Execution
Before Save Considerations
Before Save triggers will fire before Process Builder triggers (since PB is always “After Save”), so customers should generally avoid editing the same fields in both before-save and after-save triggers, as they might get weird results. Before-save will obviously always get applied first, but if a process fires off another save the before-save trigger could get executed again (and the process will again), so if they’re not careful they could cause nondeterministic loops (up until the PB recursion limit).
“Run Asynchronous” Path Considerations
The work on the Run Asynchronously path does not begin until all work on the Run Immediate paths gets completed and those transactions are committed. Any values or queries carried out in the Run Asychronous path will reflect any changes made on the synchronous path. Run Asynchronous work happens at this step of the Order of Execution (currently step 20):
After the changes are committed to the database, executes post-commit logic such as sending email and executing enqueued asynchronous Apex jobs, including queueable jobs and future methods.
- Salesforce Flowsome on Before-Save Flows
- Before-Save Flows and Accidental Recursion
- Jen Lee on Before Delete Flows
- Jodie Miners on Before-Save Flows
- Spring 20 Before-Save Flows and Apex Triggers (Bob Buzzard)
- Using Before-Save Flow and Custom Metadata Type to Update a Region Field (Gidi Abramovich)
- Using Before-Save Flow to Prevent a Record Creation/Update based on its Sibling Records’ data (Gidi Abramovich)