| Tweet |
Introduction
As is true of most releases over the last few years, Spring 22 has a bunch of flow enhancements in it, and two particularly caught my eye. I'm pretty sure that Apex developers will be casting a longing look in their direction and wondering why the same thing isn't available for pro code, although I have some opinions about that which I'll also share!
Flow Ordering
While best practice around no, low and pro code is one <insert automation tool here> per object and action, this isn't always achievable. Even if you've been able to achieve it with your own org metadata, as soon as you install a managed package from the app exchange you'll probably get some overlap. And if you've embraced the unmanaged package development approach, you stand a good chance of undoing your own good work.
Spring 22 introduces the concept of ordering for record triggered flows, allowing an administrator to control the order they are executed in, and an evil co-worker to cause all sorts of havoc. There might have been havoc without ordering, but this allows the evil co-worker to guarantee things run in the wrong order!
A flow trigger order value can be specified between 1 and 2000 (so much for one flow per object and action!), but it things are a little more nuanced than they might first appear.
Order values 1 - 1000 execute first, and if multiple flows have the same order value, the API name is used as a tiebreaker.
Then flows with no order value execute, in order of their Created Date. Note that you can't change the Created Date, so if you want to influence the order of flows in this section you'll have to supply an order value and take them out of this section. I see what you did there Salesforce!
Then flows with order values 1001-2000 execute, again with the order of any collisions being decided based on the API name.
I'm not sure why those without a value run in the middle section, but obviously if you keep all your order values below 1001, then those without a value run at the end, and if you have them all above 1000 then those without a value run at the start, so you really are in full control.
Note that each of before and after save flows have their own 1-2000 set of values that are independent. You can't specify an order value that would cause an after save flow earlier than a before save flow - what a merry time of misrule that would be!
Flow Trigger Explorer
When I originally saw this I was really impressed, as I thought it was working in tandem with the new ordering functionality and showing me the exact automation in the order that it runs in. However, throwing a few examples in to show this at the January 2022 meeting of the London Salesforce Developers made me realise it's not quite as cool as that. If you look closely at the screenshot below you'll see a couple of issues if you are hoping this will show you what happens when:
First, the items in each section are sorted by flow label, not the order value, API name or Created Date. Second, inactive flows are mixed in with active ones, so you need to dig a little deeper. It does let you see at a glance the items that might impact an action on an object though, so I think it's a worthwhile start, and I'm sure that this will get more functionality as time goes on.
Why Doesn't Apex Have These?
Controlling the order that triggers run in is something that Apex developers have been looking for since forever. And finding. There are trigger handlers galore that solve this in a variety of ways, with different levels of configuration and complexity. Managed packages sometimes present a bit more of a challenge, but a well architected package will give you a way to merge their automation with yours if you need to. While I'm sure Salesforce could provide something like the order value for triggers, or indeed their own baked-in trigger handler, I'm willing to bet this would be a case of no good deed goes unpunished and those that care deeply about these things would all be upset about different aspects of the solution being forced on them.
An Apex trigger explorer that listed the triggers involved in a single action and object would, in my view, be a solution looking for a problem. The setup pages show the triggers associated with an object, and a decent naming convention will make it clear which ones run under specific circumstances. A trigger handler framework would likely show the same trigger to rule them all for all actions for an object, or at most a dedicated trigger per action and object.
So I don't think these are particularly needed for Apex, at least for Apex developers. Admins configuring Apex might find them useful, but with the ascent of low code tools there will probably be less of that in the future anyway. I'd still like to see some kind of unit test framework for low code though, so hopefully there's a team somewhere in Salesforce at least thinking about that.
Related
- Record Triggered Flow Ordering release notes
- Flow Trigger Explorer release notes
- ApexTypeImplementor in Spring 22
No comments:
Post a Comment