A while ago, I asked about this:

Performance gains of moving automation into a trigger?

And I got some great feedback from everyone.

I'm working in a real world scenario now and proposing an org move their 78 wf rules and 28 process builders - on one object - into Apex for the most part, leaving some in for things like scheduled actions and outbound messages.

I have worked out some patterns for encapsulating logic into common interfaces and have been doing some basic testing in a dev org to make sure it's not adding a ton of overhead. The plan is to put some controls in CMDT to manage disabling automation.

What I'm seeing, though, is that with the overhead of loading the trigger, querying for related objects, dynamic assembly of the field changes, the relative performance between workflow rules and triggers is not quite as far apart as reporting might suggest. I want to make sure as I'm explaining my recommendations to the client, I'm not promising something that can't be delivered.

I know that my testing may be a bit oversimplified, but does this make sense? If I'm developing an apex framework or needing to reference related parent records (thus using SOQL), it seems logical that it adds overhead in execution time and possibly heap size. So, won't I be losing a fair amount of the performance gains that many have identified in various blogs?

I realize fully there are other excellent reasons to make a choice to move this to apex (order of execution, salesforce limits, recursion, consolidation of technologies, testing). I just want to make sure that if we proceed on this, I've set expectations appropriately.

For those who have done similar work - did you actually realize a meaningful gain in performance? Or was the gain more in terms of other benefits?

  • 2
    The key for immediate and obvious performance gain is moving same record updates from workflow or process builder into a "before" context (apex or now before-save flow). If you're just updating related records based an the initial record - then, the gain won't quite be as described in your original question. Are all those 78 WF rules and 28 process builders updating the same record (the one that triggered it)? Only moving those that do to a before-context would get you the big gain while minimizing how much work you actually have to do. Mar 10 at 16:10
  • 1
    some other useful info on optimizing PBs
    – cropredy
    Mar 10 at 17:08
  • @KrisGoncalves these are being moved into before save triggers. Not updating the related records, but referencing them as part of the logic for what to do w/ the record in the Trigger.New context. Not all rules apply in all scenarios, but 7 process builders and 56 WF rules are doing immediate field updates on the same record. Mar 10 at 17:11

Your Answer

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

Browse other questions tagged or ask your own question.