Jtdcftul

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?

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.

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.

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.