Best practices on Process Builder

Question

Hi I'm reading a book to learn apex coding and found this paragraph related to PB:

A best practice is to ensure that for a single object that there is a single Process Builder process defined with all control managed through this one process. In practice, this is not always maintainable and may require the process to be migrated to an Apex trigger. If you find yourself in a situation where you require more than one process per object you should consider migrating these processes to Apex.

Battisson, Paul. Learning Salesforce Development with Apex: Write, Run and Deploy Apex Code with Ease (English Edition) (p. 26). BPB Publications. Kindle Edition.

What I understand from this is that all of the updates done to an object in Process builder should be run in just 1 process?!

I'm kind of concerned given that we have like 10+ Processes on each of our objects...

Answer 1

Yes, consolidating flows is considered best practice. Having worked in an org where we were pushed to consolidate our Process Builder flows, I can speak to both the positives and negatives. The reason we were pushed in this direction is because we were hitting governor limits on our save operations for several objects. Consolidation of these flows remediates this problem to the extent your flows contribute to it. If you have a highly complex org and observe governor limit exceptions, you should definitely consider flow consolidation as an early step to address them.

As to the downsides, there are a few. Your version management becomes a bit more of a mess, for one thing. And the already poor error handling of flows is exacerbated because you will basically only know "something went wrong in Process Builder" with no indication whatsoever of what node caused the problem. While live issues do send out an error email providing more detail, any problem in a unit test leaves you high and dry. You will have literally no way to investigate other than running the test and hoping you can track down the right log file and section thereof. That can be quite tricky if you have an error that only happens during deployment validation, especially since orgs where you have to consider this strategy tend to take a long time to validate.

If you do consolidate, I highly recommend adding a field to your object that allows you to bypass your flows for unit testing purposes. Otherwise, your entire system will become too brittle to manage.

Answer 2

Having a single process builder for an object is the right approach but exception to this rule is when you have one process builder for creation events and one for update events.

For the limit of PB for an object Check this question on salesforce.stackexchange.com

For the best practices for process builder go through these links:

10 best practices for PB

Salesforce Process Builder Best Practices

If there is anything other query you meant to ask by this question then please update the question.

Cheers

Answer 3

I have read this recommendation as well, but for me maintainability/readability of the processes is very important. I have exactly 10 processes for Account, some of them for creation events, some of them for update events.

Some processes copy fields, other create objects, several invoke a mail alert. All of these have different conditions of course. Some even spawn actions in the future. To put these in just two processes (one for creation, one for update) would result in very large processes, if it can be done at all.

To say more about the maintainability aspect: suppose you have just one process per object and suppose you are working on new functionality, in a sandbox. Let's say a quick fix must be done on production. This fix has nothing to do with the new functionality, but it applies to the same object. Than you are obliged to apply it to your sandbox as well, because it is all one big process. And it's not an elegant update of the process: a changeset simply adds a new version, it will not merge anything.

Also, if you want to temporarily disable one bit of functionality: when you have separate processes, you just deactivate the appropriate one. If you have one big process, well, you have to edit some condition, somewhere, I guess, and remember where you have done what. Good luck with that.

Putting all functionality for an object in one big process goes against all lessons that we have learned about maintainability.

So for the moment I am keeping them in separate processes. As for the recommendation to migrate to Apex classes: that is just ridiculous. You should only consider Apex programming if you can't fulfill requirements via processes/flows/workflows. Apex code is much more error prone and makes your org much more inflexible.