| Table of Contents |
|---|
...
Display Validation Rules correctly. Geezus. Who ever thought the current way Flows fail with a validation rule is acceptable? Still not good in Spring '21.
Be easily able to update data for duplicate management without having to write a trigger. Yep!
More clarification or less confusion over the whole “One Process Builder per Object” rule and “don’t mix Flow, Process Builder, Workflows and Triggers” rule. I don’t necessarily subscribe to these rule, but that needs a whole other post and what I learn here might change my thoughts. (disclaimer: I don’t work in large enterprise orgs, so I’m only talking about small to medium sized orgs with small to medium sized complexities). This is going to be way more valid for After-Save Flows also. There is some documentation on this topic now in the Architect Decision Guides, but and I have more to say on this topic laterstarted writing about this in Flow Triggers Naming and Grouping .
Maybe getting away from DLRS… I love DLRS but as Andy is no longer able to support it to the extent that it needs, I’m worried about it’s longevity. And sometimes it’s flaky and sometimes it causes issues (again this probably needs a whole other post). I’m still going to use DLRS.
The “Always” updates - the fields that are like formulas but the formula is > 5000 character compile size so it needs to be an update. This is the whole basis for my Multiple ways to run Flows for multiple records talk at Japan Dreamin. Now, the caveat to this is building formulas in Flows SUCKS! even worse than building formulas in Process Builder! This is NOT addressed yet as at Spring '21.
Make it easy to do a criteria like “If all of these fields are not entered then don’t allow the stage to be changed”. When you can’t fit all of your criteria into a formula this becomes a pain to manage because you have to manage both setting the validation field AND clearing the validation field when the record is subsequently edited to NOT match the validation. I need to do another post on this.
...
So we have a process that needs to update some values, create some records, notify another user, add a chatter post to the record and send an email. So we are going to have the updates in the Before-Save Flows then have the rest of the bits in a combination of After-Save Flows and Process Builder and possibly older Flows… Isn’t this breaking the rules? Well maybe not, since Before-Save flows have their own place in the Order Of Execution before everything so it’s almost like we are removing the load of those updates from the Process Builders… but is it still going to be slow because of all the other things? The updates would not be a heavy load on the whole transaction in that scenario. (But we can do things in Process Builder to mitigate this now, like using the 0 hours wait time to almost do a “@Future” method but in Process Builder or Flow).
Is having to do the Get Records for ALL the simple Parent values in Before-Save and After-Save Flows going to add additional load where a Process Builder can just simply traverse to get that value?This is fixed now! Yay!When we have really complex business logic that really needs to be encapsulated in one Flow (if you were writing code it would be it’s own separate class) should we create multiple Before-Save and After-Save Flows? (with the proviso that we can’t guarantee the order and are OK with that). I think I’m going to have to say yes, on this… treat it like the One Process Builder “rule”. If I have things that only ever need to be done on Create, it’s going to be in a separate Process than create / update. I need to do another post on this topic.
Think Think of the classic scenario why they told us that Process Builders were sooo much better than Workflow Rules - where you have different field values based on different criteria. So I have exactly this scenario. I have 6 fields that can be different values based on one field that has 7 different options - basically it's a picklist with a list of presets and you choose that and it goes and sets all these other fields with the right values that make an external system function. Am I going to have to do all those combinations in one formula in Flow? No, decisions in Before Save Flow should do the trick now.
Does “Where is this Used” work for Assignment Elements in Flow? (I don’t think so).
Are Flow Triggers bulkified? I don’t see how they are when they run once for every single record. Check the Architect Decision Guides on this…
...
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 See Flow Triggers Naming and Grouping for tips on Naming your Flows
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. See Formulas in Flow Triggers for more details on this…
| Info |
|---|
In my scenario above. I enter the Base Rate - it is never set in my Assignments in my Flow. I always set my Contract Fee based on the Percentage and the Base Rate. But what if I have another formula that I want to calculate Contract Total that is added as the Base Rate plus the Contract Fee. If the formula for fContractFee is $Record.BaseRate__c * $Record.Percentage__c The formula for fContractTotal can not be fContractFee + $Record.BaseRate__c It would have to be ($Record.BaseRate__c * $Record.Percentage__c) + $Record.BaseRate__c (I’ve excluded all the null checks for clarity). Then I have another formula that spells out the Contract Total in words to display on the Contract documents. So I would have to put the full formula calculation for every part of the formula that requires any part of the value. (For example see all these stupid formulas just for adding the dollar signs). Nope. That’s all fine for simple formulas but for complex formulas that is a need to go into After-Save Flows. |
You CAN do a Get Record for This Record or now use Prior Value, which is the Previous Value of this record BEFORE you Edited ituse $Record_Prior to find the prior value of a field.
But you could come into strife - test it really well.
Think of the differences between setting a default and what the user intended to set.
...
Pause or Wait in Flow - yes there is definitely valid reasons to use this in headless flows - eg using the 0 minutes wait trick to do things in another transaction.
Workaround may be to use Invocable Apex
Where I call a Flow - eg assigning a Topic to a record, I have that in a generic Flow - I would have to make that an Invocable Apex instead.
Quip Actions (I haven’t used them but I can’t see them in Flows).
...