1

Even if you follow the guidelines and keep one PB for sObject and so on, you'll be probably sooner or later having to refactor the (probably quite big) PB, to an Apex Trigger. So why the docs encourage people to do this. There are any good reason behind this? What Am I missing?

3
3

Salesforce was founded in 1999, and by 2000 was branded as the "No Software" CRM solution. For the first eight years or so, there was no code-based alternatives, and it worked well enough for many small-to-medium-sized orgs. Apex was largely made as a stopgap for those large orgs with highly specialized processes, which took many years and iterations of newer Apex language features and compilers. Even today, there's a ton of new configuration-based features to minimize the amount of Apex you need to use.

The general philosophy for using Salesforce is to use configuration until it no longer suits your needs, then go with code. For many orgs with rather simple business processes, configuration-only is largely possible, maybe with a bit of custom Apex to handle things like callouts and integrations. By the time you get to the point where Salesforce "needs" Apex code to get every last cycle of performance, you've likely already acquired enough in-house talent to cover that gap.

I see no reason why one wouldn't start with configuration-only, and only migrate the heaviest objects (typically, Accounts, Leads, Cases, and Opportunities) to triggers as necessary. I don't know what percentage of customers use code over configuration or anything like that, but I suspect that most small orgs (say, smaller than a few hundred users) are more likely to be configuration-based deployments, and the larger enterprises moving primarily to code.

I personally prefer Apex to any configuration-based solution, but that comes from a strong background in programming (33+ years) plus my heavy experience with 5,000+ user orgs where performance is absolutely a premium. If I had to set up a brand new mom-and-pop shop CRM system, it'd almost certainly be configuration only. Code would be overkill. Starting with configuration-only solutions tends to lead to faster startup times (weeks instead of months), and is well-suited for many small-to-medium sized customers.

1
  • 2
    To this I would add - the new features of Record-Triggered Flows are coming extremely close to fulfilling all functionalities of Process Builder, especially in the coming Summer '21 release. But also Flows give you a little more control over what's happening. You have much more knowledge about which steps are explicitly triggering SOQL/DML. Plus before-save Flows are super-fast and can be as DML-free as before Triggers. So I think the SF advice will soon be shifting to put Flows first before all other options. – Charles T Apr 19 at 23:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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