1. Before-save update in a flow is 10 times faster than an update in a record-change process that’s built-in Process Builder
  2.  Before-save updates in flow accomplish that same goal, but much more quickly because each record doesn’t get saved to the database again. Avoiding that extra save procedure means skipping another round of assignment rules, auto-response rules, workflow rules, and other customizations that take time to execute.
  3. Before-save updates is similar to a before trigger.
  4. Before-save updates in flows are executed immediately prior to Apex before triggers.
  5. Flow execute first before process builder and trigger in the execution cycle
  6. Flow executed through the process builder gets executed before escalation rule execution
  7. No order of execution defined if there are multiple before-save updates in the flow
  8. In the flow, the $Record global variable contains the record values. Use an Assignment element to update those values,
  9. Get Records element to flow, now Salesforce automatically stores the fields that you need. You no longer have to select each field manually, but you can still opt to do so. 
  10. Now we can deactivate a Flow Without Leaving Flow Builder. Salesforce has added “Activate” button in the flow builder.
  11. developers can create reusable Apex actions that use the generic sObject and List<sObject> data types
  12. The flow still respects org-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories, but it ignores object permissions, field-level access, or other permissions of the running user. but it ignores object permissions, field-level access, or other permissions of the running user.
  13. Select Related Record Values from Record Variables with One Click
  14. Search for resources using API name, label, or description in the manager tab. Previously, the search feature of the manager toolbox only supported API names.
  15. The engine automatically removes duplicate record updates. For example, if an update of Account, an email was performed for 13 contacts, a corresponding 13 updates would be generated, causing the duplicate record limit to be exceeded.
  16. if one record in a batch failed to save from an action, the entire batch rolled back. Now, Salesforce rolls back only the records that fail to save.
  17. Avoid the limit for maximum CPU time on the Salesforce servers by replacing Apex code and record-change processes with before-save updates in flows.