5

I've read somewhere about an idea of implementing all Process Builders that are executing on a single object within a single Process Builder, instead of using multiple ones (IMO this is a similar approach to what is generally done with triggers).

Is this approach possible to maintain over a longer period of time? Have you seen it used successfully? Also, is it better from a certain technical perspective, for example, is it faster?

Improve this question
2
  • I would be in the camp of one process builder around a process not the entire business logic. In fact, it cannot be done around differing logic as only one branch of the PB can be entered in a given transaction per se. Really though I am in the camp of not using PB as there are too many issue still present that cannot handle anything but the most basic of processes reliably
    – Eric
    Commented Sep 6, 2016 at 22:04
  • From Summer '16 there is an option to either Stop or Evaluate the next criteria when a PB finishes a specific branch, so it is possible to enter more than one branch in a given transaction. That's the reason I thought that now we could handle more complex logic within a single PB instead of using multiple. And I agree with you, I'm also in a camp of not using PBs at all, but we already have a ton of automation spread out in them, which gets pretty painful when something goes wrong.
    – smukov
    Commented Sep 7, 2016 at 5:35

1 Answer 1

Reset to default
9

If you have a great many processes you want to automate, then consolidating them into one flow via Process Builder can be a great choice from an organization perspective. Doing so will also give you more granular control over order of execution within the flow. I'm not certain of any other benefits. Specifically, I doubt it will improve performance.

A few words of caution:

  • If you have some logic that should be re-evaluated and some that should not, you will at least need to create one flow for each branch.
  • You may also need to bifurcate your flows based on if you want the process to start only when a record is created, or also when it is edited.
  • There may always be a performance gap between Process Builder and a custom built, well optimized Apex Trigger. Because of this performance hit, I think you need to consider the case where your flow logic fails.
    • If you had them split out and one flow starts throwing errors, you can simply disable the specific flow that is causing the problem.
    • If you consolidate them, you may find it difficult to extricate or fix the broken logic. This could lead to a longer downtime as you troubleshoot.
Improve this answer
1
  • 2
    Thank you, Adrian, for your great answer. At this point I believe that leaving them separated could still be a slightly better idea. I'll leave this question open for now to see if somebody else has anything to add. I'll accept an answer in a day or two. Thanks.
    – smukov
    Commented Sep 7, 2016 at 8:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .