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
  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?

  • 5
    +1 for a very well asked question. I have a feeling this one gets closed as Primarily Opinion Based, though. – Adrian Larson Sep 8 '16 at 17:46
  • 2
    Thank you @AdrianLarson and Sebastian , if this isn't an appropriate space what would be? I believe there are some empirical points to be discussed outside of opinions - most of which I've tried to mention while avoiding the more opinion based problems (UI for example). The conversation is one that should be had with skilled, experienced professionals and I feel stackexchange is the best place for that. I considered the SF forums or idea exchange but they seemed less of a fit. – Stephen Sep 8 '16 at 17:51
  • 11
    I would like to see this question stay. How does it get made into a Wiki? – Eric Sep 8 '16 at 18:03
  • 2
    Additional comment, PB errors completely break sensitive integrations by blocking DML. At least WFR's gracefully exit. If records being inserted trigger a PB and the record insert cannot fail, PB needs to be removed from the equation. Something as simple as a null value not being checked in a PB will break PB. – Eric Sep 8 '16 at 18:07
  • 1
    @SebastianKessel advanced search – Adrian Larson Sep 8 '16 at 18:14

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.

  • Have you read Tipping Point by Malcolm Gladwell? I feel like that phenomenon is relevant to the blurry line between correct tool and overused hammer. – Adrian Larson Sep 8 '16 at 18:54
  • 1
    @AdrianLarson I have not, though after a cursory googling I think I have heard of that phenomenon before. At any rate, I think being able to see the blurry line here comes down to a combination of experience (to identify a potentially ill-fitting solution) and knowledge (to simply know about the existence of alternatives). – Derek F Sep 8 '16 at 19:35
  • the key point of your answer is in the disclaimer. Because if you had used it somewhere, and PB was causing issues with some of the existing functionality, you'd regret you ever looked at this free "dev substitution". – o-lexi Sep 8 '16 at 19:50
  • 1
    @Oleksiy I never said it was free, nor did I say that it is a substitute for a competent dev. It simply costs less (in a monetary sense) in the short term, and may realistically be the best tool available if hiring a dev (even a contractor) just simply isn't an option. I tried to tailor my guidelines for using Process Builder specifically to situations where doing so is unlikely to cause issues, and easy to convert to Apex when that time comes. – Derek F Sep 8 '16 at 20:04
  • 1
    As a company we develop managed packages that control triggers in managed code. We have built an extensive tool that controls the trigger execution order on specific objects. We use triggers for the bulk of actions we need to do; however where Process Builder works well is when a non-developer administrator at our of our customers sites wants to be able to add an additional email alert of field update, but has no development experience, Process builder allows this change to be made declaratively. – developer__c Sep 20 '16 at 13:19

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)
  • I was working out my own answer, but I think I'll hop on board the wiki train here. – Derek F Sep 8 '16 at 18:04
  • Feel free to post your own as well! I think either way works. – Adrian Larson Sep 8 '16 at 18:04
  • 1
    @DerekF Please post your own answer and thoughts. I'd love to read as much honest as possible. If we could get a wiki that could be great and we can incorporate all the answers into it. – Stephen Sep 8 '16 at 18:13
  • 1
    Continuing on with my own answer. – Derek F Sep 8 '16 at 18:14
  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

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.