First there were workflow rules, where each rule accomplished exactly one goal.
Then there were process builders, wherein each Process aimed to create a complete picture of everything happening to that object. (“Where best possible, of course”).
Then came Flows, and soon exited (pushed out?) WF Rules and Process Builder, and the SF Admin world was both wonderful and chaotic ever after.
First came official guidance to create one flow per object, then one type of flow per object. Then came Flow Trigger Explorer, so actually, one per object wasn’t so necessary anymore.
What about performance?
How do we manage technical debt?
(How) should we distribute logic between record-triggered flows or invocable sub-flows or platform event flows?
I know I should do “what’s right for my organization”, but what is right for my organization which, by the way, is a [10,000 user MNC]/[mid-sized enterprise, whatever that means]/[5-person nonprofit with a solo admin].
Join this session as we explore different paradigms for architecting your flows, share best practices for different use cases, and discuss tools & strategies for managing change while lowering technical debt.
Leave a Reply