A coworker had an assignment to rework workflows/process builders to flows. The fast field update flows (before triggered) all have the "Update Triggering Record" for all kind of changes and I'm worried this causes another update (re-running all validations, automations etc) and perform much slower instead of just using the "Assignment" element, that I know just alters the current DML.
So my question is really if there is any difference between the "Update Triggering Record" and "Assignment" element when doing same record updates in flow in terms of resources?
Also, what happens if there are multiple "Update Triggering Record" in one flow instead of multiple assignments? Will there be one update for each "update-element" or are they combined into one/no extra update?
Best Answer
Before Save Flows operate the same as before insert/update Apex triggers. They modify the record after standard validations but before the first save noted in Triggers and Order of Execution. Unlike the After Save triggers, they do not cause another round of validation/flow/trigger execution, and are therefore very efficient at updating the triggering record (very nearly as fast as a before insert/update Apex trigger).
You can, and should, use Before Save Flows whenever possible, as they do not trigger a recursive DML operation. Note that in a After Save flow, an Assignment is not sufficient to update the record. You must also use an Update Record element to actually save any changes, which is also what causes the second round of validations and triggers to execute. Using multiple Update Record elements will result in even further DML operations being executed, so we must take care to combine all such updates into a single Flow and a single Update Records element, if possible.
Note that flows are bulkified, in the sense that multiple records being processed at once will execute the flows essentially "in parallel", but only in the sense that each Update Records element will act as a blocker, and then be bulkified from there. If you have a conditional decision that ends up going to two different Update Records elements, either because another blocking element is on a decision path, or because you used different elements, multiple updates may be triggered. Always try to minimize the number of blocking paths to take full advantage of this feature.