Salesforce Flow allows you to build complex business automation using clicks instead of code. It is the most powerful tool that Salesforce admins have. When you create a new Flow, you’re prompted to select the type of flow you wish to create. Depending on your needs, you have to select the right one from the five main flow types. These available flow types are screen flow, autolaunched flow, record-triggered flow, schedule-triggered flow, and platform event-triggered flow.
Read this post to learn more about the flow types.
Record Triggered Flow
Record-triggered flow can be considered as the main flow type. It is the only flow type that contains the triggering event (create, update, or delete). It means that it runs automatically when a record is created, updated, or deleted. Record-triggered flow does not need to be called from anything. The $Record global variable contains the values from the record that triggers the flow to run. Therefore, there is no need to add a Get Records element to bring the record data.
As you know, Workflow Rules and Process Builder will be deprecated soon and Flow will be the one and only automation tool. Salesforce recommends you to convert your existing Workflow Rules and Process Builder into Flows. Record-triggered flow is the flow type that you will need to choose to accomplish this. That is why it can be considered as the main flow type. Unlike Process Builder and Triggers, there is no recommendation to have only one record-triggered flow per object. You can create many flows with right entry criteria.
Depending on what you want to perform, you can choose the flow to run before or after the record is saved. They have big differences but before that, it is important to know how to select before or after save. Where are these options?
Before the Winter '22 Release, the configuration of the start element used to look like this. As you can see, there were "before the record is saved" and "after the record is saved" options.
However, in the Winter '22 Release, Salesforce changed the UI of this configuration. They don't call them before or after anymore. To make it more clear for people that aren't familiar with terms before and save, they changed the labels. "Fast Field Updates" option means before save and "Actions and Related Records" means after save.
Before Save (Fast Field Updates)
If you just need to update fields on the record that triggers the flow, this is the right option. It can be triggered when the record is created, created or updated, updated, or deleted. Before save flow runs much faster (10 times) than the after save flow. However, it is important to understand what you can do with this type of flow.
First of all, the only thing that you can perform is to update the record that triggers the flow. As you can see, there are no options to create or delete records, or any interaction elements like calling a subflow, or performing an action (for example, sending an email). However, you can still get any record from the system and perform any logic that you want.
As it was mentioned before, there is no option to update any other record.
If you are familiar with Apex triggers, then you probably know that you don't need to call update to modify the record. Since you are working on the record before it even goes into the database, you just need to set the field values you want and that's it. The logic is the same in before save flow as well. In order to update the record, you can use the assignment element even without the Update Records. However, to make it more clear, Salesforce added another option to update the record: Update Records element.
Both of these elements will update Blocked_For_Service__c checkbox to true. You can use either Assignment or Update Records.
Another important point is that before save flows run immediately. It is not possible to add a scheduled path to take time-based actions. Since before save record-triggered flow runs even before the record is saved to the database, it is not possible to access field values that are set only after the record is saved. For example, you cannot reach the last modified date or a formula field value. On the other hand, you cannot access the record Id when you run the flow on create.
Even though you can just update some fields of the record (and yes this is really the only option), you can perform cool workarounds as well. For example, you can build complex validation rules. It is also important to mention that although you are updating fields, it doesn't consume from the DML limits. As you can see from the debug log below, number of DML statements and DML rows are 0.
Read this article to learn more about before save record-triggered flow.
There is one exception that if the flow is working before delete, then all the data elements like create, update, delete are available. Just like the after save flows.
After Save (Actions and Related Records)
If you need to update any other record or perform actions like sending emails or calling subflows, this is the right option. It can be triggered when the record is created, created or updated, or updated. Unlike before save flows, it cannot be triggered on the delete event. However, there are many more things that you can accomplish using after save record-triggered flows.
As you can see, there are many elements that are available in the toolbox. You can create, update, or delete any record, call a subflow, or perform any action like sending custom notifications. At the end, after save record-triggered flows have the capability to replace all of your Process Builder. Actually, Process Builder is also an after save record-triggered flow, but it has a different UI.
There is one important thing to mention about the subflow action. Unlike Process Builder, you cannot call a flow (using subflow) that has pause element. Just because of this, you may not be able to convert some of your Process Builders to Flow.
Unlike before save flow, in order to update a record, you must use the Update Records element. Assignment element will not update the record. All the DML operations (create, update, delete) consume from the DML limits.
After save record-triggered flow supports three path types. Use immediate path to perform actions immediately (this is the most used path type). Use a scheduled path if you want the flow to run some time after the update of the triggering record. You can base the scheduled time on the update date/time or on a field value in the record. A separate flow interview runs for each scheduled path. Use an asynchronous path to access an external system after the original transaction for the triggering record is successfully committed.
According the order of execution, before save record triggered flows are executed, then before save triggers, then after save triggers, and then after save record triggered flows.
Conclusion
To sum up, record-triggered flows will replace your Workflow Rules and Process Builder. If you just need to update fields on the triggering record, you should use a before save flow since it is 10 times faster. However, in order to update other records or perform many other actions, you have to use an after save flow. If you use the new Migrate to Flow tool to convert your existing Workflow Rules to Flows, you will see that it creates a new flow for each Workflow Rule. Try to merge them, so that you will have less flows and better understanding of the steps and actions.
Here is a comparison chart of before save and after save record-triggered flows.
Leave a Reply