2

I went through a lot of different articles about Process Builder vs Triggers. Yet I can't say I clearly see the benefit of using Process Builder if you know how to write an apex trigger.

What would be a reason to go with Process Builder instead of a trigger? I understand that one doesn't need code coverage for process builder but I don't consider that a benefit.

I am also wondering if a lot of Process Builders add up over time if there's some sort of conflicts that they might impose on each other that becomes harder to debug?

Adrian Larson
  • 149,971
  • 38
  • 239
  • 420
Arthlete
  • 4,917
  • 9
  • 59
  • 103
  • 1
    This is similar to https://salesforce.stackexchange.com/questions/139983/should-we-use-process-builder-at-all (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time) – Derek F Jan 15 '19 at 19:04
  • @DerekF Thanks for linking to your answer! That was a good addition to what the others said. – Arthlete Jan 15 '19 at 20:34

3 Answers3

8

From my perspective, the benefit is primarily for those who do not have the knowledge or resources to build Apex. If you have the knowledge and resources, I would stick with Apex.

The main drawbacks are the poor error handling, and the fact that this feature makes it so easy to introduce errors through lack of knowledge. For example, checking that a parent record exists before checking if a field on it has a specific value. Using Apex does not fix these errors in and of itself, but the development cycle should force you to include null checks, etc.

Again, I would personally recommend you put the logic in Apex if choosing between these two and you have the skill to implement either/or. However, I would note that Workflow Rule is still a good fit for many simple field updates.

The one exception to the above would be if you want to post to chatter and include at-mentions. Using the ConnectAPI is not bulk safe, and so in this corner case Process Builder is radically more efficient than Apex.

Adrian Larson
  • 149,971
  • 38
  • 239
  • 420
  • Thank you, this is the kind of answer I was looking for! – Arthlete Jan 15 '19 at 17:57
  • 1
    If you have more process builder on specific object then there will be chances to get CPU limit exceeded error – Santanu Boral Jan 15 '19 at 18:29
  • 1
    Like having one trigger per object one should also stick to one process per object – Pranay Jaiswal Jan 15 '19 at 19:07
  • This article https://www.slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB. – RedDevil Jan 16 '19 at 04:12
  • 1
    Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress – Eric Jan 16 '19 at 05:16
6

For orgs that have business logic that can be purely described in Process Builder and Validation Rules, the benefit is that you get faster deployment times, no need for unit tests, and can implement business logic faster (generally speaking). However, for many typical cases, mixing Process Builder and Triggers can cause excessive governor limit usage, and so mixing the two are generally not recommended by those with enough experience to have tales to tell.

sfdcfox
  • 489,769
  • 21
  • 458
  • 806
  • Hi @sfdcfox, I work for an org who gets CPU time exceeded errors all day. I moved workflow logic to Process Builder (they don't have skills for flows or code) but I think Apex would be much more efficient, first because I'd have more control on what's executed and in which order, 2nd because I think code might be faster. Is that a good advice for them ? – Emmanuel BRUNO Sep 07 '21 at 07:54
1

There's an interesting discussion I found on reddit: https://www.reddit.com/r/salesforce/comments/8uupjs/am_i_wrong_to_hate_processbuilder/

I find the below pretty interesting from the stand point that one can turn off the process builder without touching any code(or being a developer). Where I work we have a very heavy deployment process that requires multiple Pull Requests even for the smallest code change. That is pretty slow and sometimes there might not be any devs available to approve a PR immediately.

Classified triggers are much more maintainable if you have a regular dev on staff. I work on really technical enterprise orgs and from my perspective avoiding PB just because it's PB is a huge mistake. There are things you can do in PB much faster (posting to chatter, for one) and making quick apex invocables that are launched for a specific process node (that you MAY want to disable as part of operations, so admin can go and turn that node off). They're easier to iterate (by design) than triggers - so not being able to refactor them is crippling the tool.

For mission critical objects, triggers only. For less mission critical mixture is fine. PB handles easy stuff (write values from parent to child, post to chatter, quick create simple records, easily assess record state and assign values from formula fields etc). For anything that needs reference data like Maps, uniqueness like Sets - those go in the trigger.

Community
  • 1
Arthlete
  • 4,917
  • 9
  • 59
  • 103