Forgive me if this isn’t an appropriate topic for this board but I would like to have an open and honest discussion about Process Builder.

We have a multi-tenant org (different business units using the same objects with different logic) that contains dozens of Process Builder processes. Many of the objects have multiple processes. I have many concerns about using process builder at all:

1. Governing Limits and Bulkification Concerns

• Process run much slower than equivalent apex
• Still not fully bulkified
• Are Process Builder workflow rules more likely to violate CPU Time limts than a standard/old workflow rules?

2. Complex Logic and no Testing Required

• Allows user to create complex logic with no testing at all – how are we supposed to maintain and extend systems when there are no regression tests?
• Complex logic built by people who are not developers or architects, little to no concern about implications to other parts of the system and since there are no tests there is no way to catch it.
• No control over order of execution – requires us to run all of our logic multiple times.

3. Source Control Nightmare

• Flow Definitions are saved as versions, thus each version is a new piece of metadata, and this makes it very difficult to track in source control even if you manually remove the version number.
• Almost impossible to simultaneously work on same process in multiple orgs and merge them at the end of the day.

4. Error Handling and Debugging

• Is honestly a complete joke. It seems to only send an email to the original creator of the process, the on screen errors are completely meaningless (‘Error in flow with Id: blahblah’ , and the Id isn’t even presented in the SF interface – you have to query to find out the actual failing process). I hear they are working on this.
• Apex is already light years behind other software stacks when it comes to debugging – Process Builder is even worst.

5. Documentation

• No internal comments to self-document. A single description field simply isn’t enough.
• Hard to maintain in the long run.

Because of all of this it is my opinion that Process Builder should simply never be used at all. Maybe in very small single use orgs that will not grow in terms of functionality – but in that case you are crippling a lot of what makes SFDC an amazing platform.

If you look at this salesforce article: https://developer.salesforce.com/blogs/engineering/2014/12/forcedotcom-declarative-development.html

I would argue that the 3 points they make are far worst using process builder than Apex (this article is a bit dated for Process Builder but it is now GA and is being pushed hard as a click not code option).

• Cost and time – Not much faster to implement then Apex with an appropriate trigger framework – still need a skilled resource either way.
• Maintenance – who’s going to maintain the process after the initial development is done? Very difficult to hand off maintenance due to lack of documentation features.
• Complexity and Scalability – All governing limits still apply and in fact are exacerbated when using Process Builder as opposed to apex.

I know this is very broad and in general we want concise problems with concise answers. So, given the problems listed above, should anyone every seriously consider using Process Builder?

Forgive me if this isn’t an appropriate topic for this board but I would like to have an open and honest discussion about Process Builder.

We have a multi-tenant org (different business units using the same objects with different logic) that contains dozens of Process Builder processes. Many of the objects have multiple processes. I have many concerns about using process builder at all:

1. Governing Limits and Bulkification Concerns

• Process run much slower than equivalent apex
• Still not fully bulkified
• Are Process Builder workflow rules more likely to violate CPU Time limts than a standard/old workflow rules?

2. Complex Logic and no Testing Required

• Allows user to create complex logic with no testing at all – how are we supposed to maintain and extend systems when there are no regression tests?
• Complex logic built by people who are not developers or architects, little to no concern about implications to other parts of the system and since there are no tests there is no way to catch it.
• No control over order of execution – requires us to run all of our logic multiple times.

3. Source Control Nightmare

• Flow Definitions are saved as versions, thus each version is a new piece of metadata, and this makes it very difficult to track in source control even if you manually remove the version number.
• Almost impossible to simultaneously work on same process in multiple orgs and merge them at the end of the day.

4. Error Handling and Debugging

• Is honestly a complete joke. It seems to only send an email to the original creator of the process, the on screen errors are completely meaningless (‘Error in flow with Id: blahblah’ , and the Id isn’t even presented in the SF interface – you have to query to find out the actual failing process). I hear they are working on this.
• Apex is already light years behind other software stacks when it comes to debugging – Process Builder is even worst.

5. Documentation

• No internal comments to self-document. A single description field simply isn’t enough.
• Hard to maintain in the long run.

Because of all of this it is my opinion that Process Builder should simply never be used at all. Maybe in very small single use orgs that will not grow in terms of functionality – but in that case you are crippling a lot of what makes SFDC an amazing platform.

If you look at this salesforce article: https://developer.salesforce.com/blogs/engineering/2014/12/forcedotcom-declarative-development.html

I would argue that the 3 points they make are far worst using process builder than Apex (this article is a bit dated for Process Builder but it is now GA and is being pushed hard as a click not code option).

• Cost and time – Not much faster to implement then Apex with an appropriate trigger framework – still need a skilled resource either way.
• Maintenance – who’s going to maintain the process after the initial development is done? Very difficult to hand off maintenance due to lack of documentation features.
• Complexity and Scalability – All governing limits still apply and in fact are exacerbated when using Process Builder as opposed to apex.

I know this is very broad and in general we want concise problems with concise answers. So, given the problems listed above, should anyone every seriously consider using Process Builder?