Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

  • Time-based Workflow

    • The implementation of time based updates in Flows is terrible. If it has less features and is less reliable and is less customisation than existing functionality why would I use it? It is just bad. I need to test the new Scheduled Paths feature in Spring ‘21. Apparently the Flows now show in Time Based Workflows - yet to test.

  • Email Alerts, if there are a lot of emails being automated

    • Who’s stupid idea was it to have seemingly orphaned email alerts because you can’t see that they are used in Process Builders? And it’s not even in the new Where is it Used functionality.

    • Email Alerts can now use Lightning Email Templates in Spring '21 but they are still orphaned in the UI!

  • Where a complex formula is used more than once

    • Nope, Invocable Process Builders are just a waste of time, and see above re formulas in Flows… I sometimes just want to stick with what I know works. (May be less of an issue with the ability to run Apex in Flows, and the release of the Automation Components).

  • Long Text and Rich Text Fields

    • You STILL cannot build record triggered flows that are triggered based on the contents of a long text or rich text field. Eg I have a field named Instructions and another field named InstructionsExcerpt that is used to validate if Instructions is filled in. InstructionsExcerpt is updated every time the Instructions is Edited and IF it is not null. This will stay as a workflow. You need to have an after-save flow that is triggered ALWAYS, then include a decision in that Flow. I’m not sure it’s worth it unless you have another Always After Save Flow.

    • Foiled again! Dammit!

  • Just because

    • Why would I rebuild anything that is already fully functioning in Workflows… (nice to see this reiterated by Jen Lee in the Architect blog post)

...

  • 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.

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.

...