Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

In Spring ‘21 we finally have Is Changed in Flow Triggers… well sort of… it feels convoluted to set up but let’s compare it with Process Builder

Scenario.

  • Set a text field that the rate was changed.

  • Set a text field that the rate was not changed.

It’s a silly scenario but it’s good to show the setup because it covers both the true and false scenarios.

Process Builder

  • For a start, your Process Builder would NEVER look like this because we were told that the “best practice” is for one Process Builder per object, so these nodes would be one of about 50 in this humungous Process Builder that is so confusing to work out what its doing.

  • It’s easy to just choose Is Changed in the Operator… BUT you also have to check if it is not null.

  • The reverse scenarios are a pain to set up because it feels so repetitive to set up the criteria again. Easy for one field, but when I need to check if one of 20 rate fields have changed, then it’s not so easy.

  • Process Builders are so difficult to see what is happening, having to click into each node.

So overall it seems simple at first glance, but quickly turns into a nightmare. My Process Builders are a nightmare.

Flow

  • This Flow would be in a larger flow of your “Always Flow”. Just about every object is going to have an Always Flow…

  • But if you only want it to run if the record is Active, then we are now released from the stupid shackles of One Process Builder per Object and can now build our Flows in a more granular approach as we would do with Workflows. So I would build flows like this”

    • MyObject-BeforeCreateUpdate-Always

    • MyObject-BeforeCreateUpdate-IsActive

  • See my Formulas in Flow Triggers post for more details.

  • Remember that there is STILL no guarantee of order of flows, so if you need an order it needs to be in the same Flow.

  • At first glance it seems that comparing the {!$Record.MyRate__c} with {!$Record__Prior.MyRate__c} rather than a simple Is Changed is a bit of extra work, but I think the payoff is in the ease of setting up different conditions and opposite conditions if there is only one, like the example.

  • And the Assignments are easy to set up also.

So overall I think the Is Changed in Flows is going to be much easier and nicer to work with.

  • No labels