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:
- 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?
- 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.
- 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.
- 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.
- 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:
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?
I’ll give this one a shot.
disclaimer: The only experience I have with process builder was helping my boss out in the Dev Zone at Dreamforce last year.
Process Builder is a tool that sits in between workflow and Apex in terms of what it can accomplish. Process Builder can be the best fit for the task at hand, but like all tools, it can be misused.
The big advantage to Process Builder is that it gives you a sizable portion of the power of Apex code without the need to actually write Apex code. You just need to have a somewhat programmer-ish mindset (knowing how to make use of loops, variables, and conditionals).
Having even a single developer on staff can be a big investment for a company. Process Builder allows some of the benefit of a dev, without the full cost of a dev. It saves money…for a time.
I’d argue that using Process Builder means that you start to accrue considerable Technical Debt. The numerous downsides that you mention are all technical debt.
The scenario you describe sounds like someone has (or several people have) succumbed to the Law of the Instrument, which, restated, is
When you have a golden hammer, every problem starts to look like a nail
Process Builder helped them out on problems x and y, so it should work for problem z too, right?
Well, after some ill-defined point, the processes start getting more complex. They also start to become more tightly coupled, and interact with one another more and more.
In your situation, it sounds like there’s an issue of shared resource planning as well. One business unit may not have/want a dev to take care of this, but it will end up impacting the rest of the business units.
It is at that point where I believe you cross the line in the sand where a developer writing Apex makes more sense. Some of the value of a Good Dev™ is that they are able to manage the interactions required between the business logic in a way that scales well, is easy to maintain, and is easy to extend.
Process Builder can be used to solve a variety of issues, but it isn’t always the right tool and is no substitute for a competent developer.
The situations where I’d consider using Process Builder are:
- When you are only performing work on a single object
- You aren’t trying to work on more than a hundred records or so
- The required logic isn’t terribly complex (a couple of
- You can’t afford to hire a dev right now, but will be able to in the near future (< 1 year)
Used correctly, Process Builder can serve as a replacement for simple triggers until your org needs to start considering code scaling. It even may be faster to develop than a trigger.
Moderately complex logic and interactions with other objects are a good way to quickly get over your head, and would require more up-front cost when a dev is brought in to untangle the unholy mess.