Page Comparison

...

• You can now set defaults for record Owners and Currency ISO Codes??? Maybe? (I need to check this). You can’t set these in Quick Actions (But you may be able to set these through the new URL Hacks also).

• You can use Before-Save Flows to set values for Duplicate Rules - such a good use of these Before-Save Flows!

• You CAN use Formulas in record triggered flows, just be aware of the Gotchas! See Formulas in Flow Triggers

• The new thing of being able to see Flows (and Process Builder) in Time-Based Workflow is a complete game-changer. No need to use Workflow for Time dependant actions anymore. Though why it took this long for Process Builder to be in there, I will never understand.

  • HOWEVER, you can NOT search on Object. So ensure the Name of the Flow has the Object in it. See Flow Triggers Naming and Grouping for naming suggestions.

Tips

• Naming Convention: I would suggest ObjectName-BeforeCreate and ObjectName-BeforeUpdate or ObjectName-AfterUpdate or ObjectName-BeforeCreateUpdate and then extend it if there is a condition eg ObjectName-BeforeCreateUpdate-IsActive

• Ensure you don’t accidentally assign a value that will ALWAYS set the value to that and will never allow the value to be set to anything else. Eg as shown in the Release Demo Video for Before-Save Flows!

• Create a Checkbox on your record (eg Disable Auto Update for Before-Save Flows), default False… Set this as the first Condition in your Flow… just in case you need a way to opt out.

• Are there fields that always should be entered? If so, put these into a Before-Save Flow for Create only, rather than running this each time it’s updated (except if it changes of course - this is more for default values).

• You can maybe turn off field required-ness on create for some fields that you can now set through these flows. (or event better, requiredness may be able to be set through Dynamic Forms and Dynamic Actions)

• If you are doing a Before Create and Before Update in the same Flow then ensure you use a Decision Element before you do a Get Records on a related Object, so your flow does not fail when that lookup field is not filled in (or when the value is cleared in an Update).

• Decide what happens after the record gets to a certain status - eg Closed Won Opp, or Closed Case. Do these flows run then?

  • Duplicate the Final Assignment Element, stick a Decision before it for the Status / Stage and only set those values that MUST be changed after that Status / Stage.

  • Or use a Lock Record Flow Action on a regular Flow to lock the record (hmm, if Before-Save runs before even Before triggers, does the regular record lock feature even prevent Before-Save updates from happening? And how does Lock Record work if Flows are run in System Context - all this needs to be tested, do not take my word for it).

• Turn a Before-Save Flow conditionally into a Before Update or Before Create by checking for the existence of the $Record.Id. Rather than maintaining two flows… maybe… check if it slows things down.

• Check your formulas for what happens when there is a null value. The resulting field will be Null. Do you want it to be null or 0.

...

• You CAN NOT use formulas that include values from any other field set by the Before-Save record. Think of the field as being null always and every time you edit the record this field value is going to be set again. Note, I need to check this now that I’ve worked out you CAN use formulas in Before-Save flows. Oh wow, it looks like it works!!! I will report back when I delve into it further.

...