Should we use process builder at all?

Question

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?

Answer 1

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.

The takeaway

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 ANDs and ORs at most)
• 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.

Answer 2

Perhaps this is a good time for a wiki. Feel free to throw in your two cents.

Cons:

• Process Builder runs very late in the Order of Execution, meaning even if it's optimized, it is more likely to be the straw that breaks the camel's back, and hence get blamed for more errors.
• It doesn't play nice with the Bulk API (causes rollback of entire batch if one record fails in the flow)
• Doesn't require test coverage (see pros)
• Allows development to happen directly in production

Pros:

• great enablement tool for small orgs that are run by a single admin or small team
• More powerful than workflows. Can do more with just clicks
• Doesn't require test coverage (see cons)

Answer 3

1. Not sure how much data is to support this, but yes, if you create a bunch of processes that run every time a record is created or saved it will slow things down, but formulas and other conditions can be used to determine what is run when. This is as much about good administration as it is about good programming in apex - I can write something poorly enough it will run plenty slow.

2. No testing is required, but you can have this as an internal requirement. Use Dev sandbox -> push to partial copy and require approval before pushing from the partial to production. Require a set of manual tests to be passed in the partial sandbox

3. No argument there, but no worse than a validation rule or workflow. Hopefully Salesforce will improve all of these in the future (see The DX Pilot for work they are doing in improving version control)

4. They improved this in winter '17 but it is still not very good. You can deploy https://github.com/mshanemc/processBuilderBlocks to your sandbox and use the apex debug invocable process to manage error handling or use it in production to give you something more useful in your logs.

5. See 3 - could use improvement, but you can always add your comments in the formulas and use smart naming of each step/action.

While there are areas to improve, it lower the barrier to entry for many organizations. You might see delving through versions of processes as hard to maintain, but delving through someone else's spaghetti code in apex is no dream either.

Process builder's strong suits are: a) can replace simple triggers without writing/maintaining apex b) runs in system mode, so allows background updates to fields that you might not want a user manually changing c) arguably a more modern replacement to workflow rules - as it solves many known limitations