Record-Triggered Flow Design Patterns | Automate This

[@magpie2728]

This episode is gold 😍 Could you do episode about how to document Flows? Thank you

[@siridevasingh7496]

My opinion: I started out as "One Per" a year or two ago, but after the release of flow trigger explorer we are re-designing to go "multiple". Once the automation logic in your org becomes significantly complex, the maintenance challenges associated with the "One Per" design can greatly slow down feature releases and bug fixes.

[@csoutsource]

I agree with this!

[@confusedguyl100]

Did I miss it or the concept of Transaction wasn't mentioned in the considerations for flow design patterns? The one-flow-per-object pattern may cause all automations under that flow to fail because everything is run in ONE transaction. I don't know if any admin would want that to happen. In my org, we have many automations on Opportunity object doing very different things. We certainly don't want all of them to fail just because an automation fails due to a validation rule, for example.

[@ramachandra9931]

Q

[@NarenderSingh-tq1wq]

Hey, That's a nice point and I do see your point. However, it's not a major differentiator. Every transaction is atomic in nature. So if anything fails at any point, the transaction will rollback. It doesn't really matter even if you've one flow because the decision elements in the Master flow control if the subflow should be executed or not. So, ideally, you would only expect a certain flow(s) to run for a specific update(or create). Makes sense?

[@nagalingeswarareddyvempall2147]

Can anyone help me to understand, how we can create one flow per an object to cover before, after (insert, update and delete) as we don't have options to choose?

[@RVAraghav]

Ok it’s a great topic, great speakers but spoiled by poor video quality and voice sync.

[@ianroque3308]

What is the name of vscode extension mentioned by narender to examine flow metadata inside vscode?

[@dharmeshrana7548]

He said Ruban or Ruben not sure though

[@gunavathibuwari6644]

Good

[@csoutsource]

I disagree with one flow per object model. As Nikhil Kapoor noted, ​the whole point of having the order in Flow Explorer is so that you can create multiple flows per object.

[@PULKITMISHRA-xj1ec]

ಚ

[@KepmukNesshart]

I love how in denial the one flow per object dude is. He is like “I use this flow as a trigger and then it calls all these subflows. I also have separate async and scheduled flows.” If he had one before save, one after save, and one delete, I would let that slide. But instead he has a ton of flows per object and just can’t admit he isn’t one per object anymore.

[@tomhoffman1390]

@kepmuk - its one flow trigger per object per event - its tough to capture the whole approach in this q&a format, the accompanying blog post might help understand the rationale better, its meant to mirror the trigger-handler-action pattern from apex design. Along those lines, in this pattern, a scheduled flow is no different than scheduling an apex class, those actions are always separate and not tied to the trigger on the object. Happy to chat on it sometime - I know there is no approach that is 100% for all scenarios - for me, its easiest to start here and let your requirements drive you elsewhere.

[@alanbirchenough]

It was disappointing to hear such dogmatic opinions being expressed in this session. Not a laughing matter at all in my opinion. The discussion of pros and cons was very good and full of useful information, but the "I'll never change my mind" vibe was discouraging to say the least.