Why you shouldn't use Process Builder

posted Jul 16, 2016, 4:55 PM by Ezra Kenigsberg   [ updated Jul 17, 2016, 3:21 PM ]
Q: "Why should I use Workflow when there's Process Builder?"

A: Two big reasons: Processes give lousy error messages, and Processes can break data loads.

Let's break it down!

1)    Processes give lousy error messages.

Here're the error messages returned by Workflow and a Process. Can you guess which is which?
Error Message A:
Error Message B:

Give yourself a Kewpie Doll if you correctly surmised that a Process returned message A, and Workflow returned message B.

Notice that message A, the Process message, is annoyingly cryptic:
  • It says a Flow failed, which is wrong. A Process failed.*
  • It gives an ID that's almost completely useless.*
  • It doesn't tell you which field caused the problem.
  • It doesn't tell you which value caused the problem.
Compare that to message B, the Workflow Field Update message:
  • It correctly tells you a Workflow or Approval caused the error.
  • It tells you the field that caused a problem.
  • It tells you the bad value in that field.
2)    Process Builder can break data loads.

Processes are subject to many of the same limits as Apex Triggers. Workflow Rules are not subject to those limits.

Salesforce ought to warn users: if you build a Process with Process Builder, you should perform load testing before deploying that Process to Production.

I encourage you, when considering automation, to try mighty hard to do it with clever configuration or Workflow.

Process Builder brings a bunch of risks that, if you can't solve your problem with config or Workflow, are better addressed by Flow or Apex Triggers.


* What's the heck's up with that ID? And why does Salesforce say the Process is a Flow? Great questions! Tune in tomorrow for the answers.
Comments