5

I'm working w/ a client who is running up against some limits for declarative automation. They are making robust use of workflow rules (above the limit), process builder (> 15), and a trigger.

I am familiar with some arguments for picking one tool per object from the Salesforce best practice documentation.

My sense is that this client might benefit from moving much of their record-modifying automation into a trigger-only approach. Perhaps also by moving some of their triggers and other automations into a platform event based trigger or async methods. Much of the behavior doesn't seem to have a strong need for timeliness. However, I don't have any performance based statistics to back this up.

Is anyone familiar with any kind of metrics around the processing time for using a trigger as opposed to process builder or workflow rule?

5
  • 2
    Moving any available workflow field updates and process builder updates to Before Save Flows will still result in upwards of 100x speed gains without code. Apex is only very slightly faster than BSF and requires more work (unit tests, etc).
    – sfdcfox
    Jan 1 at 15:27
  • What is the current experience of deploying flows like? I'm hoping to get the client to shift their deployment model over time and from what I recall flows could get problematic in terms deploys. Jan 7 at 13:25
  • 2
    Aside from the various difficulties maintaining multiple versions of the flow in a repo, the actual deployment process is fairly painless. I'd recommend BSF as much as possible, but they're limited in capabilities (e.g. can't do DML), so some combination of both BSF and Triggers are usually necessary anyways, which means that triggers are still advisable beyond a certain complexity.
    – sfdcfox
    Jan 7 at 13:31
  • Thanks, that makes sense. In an object with both workflow rules and a trigger, moving the record change workflow logic into a BSF would see some performance benefits by moving to a more efficient technology which is more declarative. If still using trigger for other work, I do wonder about whether this article: help.salesforce.com/… is still applicable. Jan 8 at 2:41
  • 1
    Yes, the guidelines are still applicable. Notably, you should prefer to use one automation tool per object. This really makes it easier to maintain. I still prefer code for heavy objects, and flows for light objects. However, that's still just my opinion. The best option is the one that balances maintenance and performance decently. As soon as a flow gets too complicated, it's probably time to port to code.
    – sfdcfox
    Jan 8 at 4:28
10

There are some metrics published officially by the Architect relations team and you can read them on the new architect website.

Clearly from the analysis Triggers are efficient when it comes to performance.

There is also a nice blogpost from a community member about how to capture the metrics. So this technique can be adopted to see current performance metrics.

There is also an open-source VSCode extension plugin that makes analysis easier.

1
  • 1
    Great links - thanks Mohith.
    – Keith C
    Jan 1 at 10:03

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.