With all the Salesforce Flows enhancements over the last few releases, I’ve been wondering what the relative performance is among the various record automation options like Flows, Process Builders, Workflows, and Apex Triggers. Same-record field updates was an area of particular interest after reading this from Salesforce:

Of the ~150 billion actions that were executed by Workflow, Process Builder, and Flow in April this year — “actions” being things effected outside the runtime, such as record updates, email alerts, outbound messages, invocable actions — we believe that around 100 billion of those actions were same-record field updates.

Architect’s Guide to Building Record-Triggered Automation on Salesforce Using Clicks and Code

Roughly 2 of every 3 declarative actions are doing same-record field updates!

In this post, same-record field update benchmarking and before delete benchmarking will be covered. The methodology, results, and conclusions from each are covered.

Disclaimer: These results are from a personal developer edition org running on the Winter 21 release. These timings will vary according to your edition, system load at the time, and other factors. Treat these as relative performance timings and not absolute timings.

Want to run the benchmark? See my Salesforce Benchmark Package.

Same-Record Field Update Bechmarking

Since same-record field updates are the most common action, let’s explore the 5 options available today and see what the relative performance is among them.

Solution’s Timing Averages After 10 Runs

Apex Trigger	Before-Save Flow	Workflow	After-Save Flow	Process Builder
52.8 ms	62.7 ms	87.1 ms	354.1 ms	396.2 ms

Methodology

For each solution, a custom object was created with an Auto Number name field and with a custom text field. 200 records are inserted in each solution’s custom object using apex from Execute Anonymous using VS Code and each solution sets the custom text field to the same value. Immediately before and after the insert statement Limits.getCPUTime is invoked. The start time in milliseconds is subtracted from the end time to determine the overall insertion time. These results are then recorded in a Benchmark Result custom object.

System.debug was avoided because turning on system.debug usually causes everything to be slower. Dan Appleman and Robert Watson shared that in their Dark Art of CPU Benchmarking presentation. Parsing each debug log after each benchmark run is also tedious.

The timings shown include the general overhead of inserting 200 records. As a result, the timings shouldn’t be interpreted as each operation takes X time. Each one is X plus Y overhead.

Before-Save Flow

A before save flow was created without any criteria and has one assignment that sets the custom text field to a default value.

10 Run Timings

Run #	Time in Milliseconds
1	55
2	58
3	59
4	71
5	70
6	59
7	70
8	58
9	69
10	58

Average: 62.7 milliseconds

Process Builder

A process builder was created on record insert that has no criteria and updates the custom text field to a default value.

10 Run Timings

Run #	Time in Milliseconds
1	370
2	443
3	374
4	431
5	452
6	413
7	379
8	400
9	361
10	339

Average: 396.2 milliseconds

Apex Trigger

An apex trigger with the Before Insert event is created that sets the custom text field to the default value for each inserted record.

10 Run Timings

Run #	Time in Milliseconds
1	50
2	59
3	46
4	44
5	66
6	55
7	47
8	47
9	54
10	60

Average: 52.8 milliseconds

After-Save Flow

Since after-save flows can also be used, I was curious about those too. This was done by creating an after-save flow on after-insert that has a single update record that updates the custom text field to the default value.

10 Run Timings

Run #	Time in Milliseconds
1	351
2	360
3	365
4	338
5	325
6	453
7	306
8	377
9	306
10	360

Average: 354.1 milliseconds

Workflow

An on insert workflow rule was created that has a field update to set the custom text field to the default value.

10 Run Timings

Run #	Time in Milliseconds
1	86
2	77
3	74
4	92
5	101
6	115
7	77
8	81
9	80
10	88

Average: 87.1 milliseconds

Same-Record Field Update Conclusions

Before-Save Flows and Apex Triggers are the fastest solutions and should be used first. Which one you should use depends on your team makeup and their skill set. If you mostly have declarative expertise, use before-save flows. If mostly Apex expertise, use Apex triggers. If a mixture, go with before-save flows. Of course, if you have case where a declarative solution isn’t available, use an Apex Trigger. For example, custom validation that a validation rule can’t satisfy, an apex trigger is necessary because before-save flows don’t support them currently.

While workflow rules also run almost as fast, they should be avoided because they’re no longer being enhanced and Salesforce recommends using Flows and Apex triggers as the no-code and “pro” code record automation options, which I agree with. Salesforce record automation recommendations.

After-Save Flows and Process Builders require an additional record update to update the same record which causes the order of execution to begin again which is why it’s so slow.

The relative timings performed as I expected with Apex triggers being the fastest followed by before-save flows, workflows, after-save flows, and finally process builders. The declarative relative timings coincide with Dan Appleman’s declarative benchmarking in The Return of The Dark Art of Benchmarking – This Time It’s Declarative! despite the timings not being the same, which is expected.

Before Delete Benchmarking

In Winter 21, one can now use flows to run automation when a record is deleted. This was one of my most desired features for almost 10 years. Common deletion use cases are:

• Continuing the cascade delete for the deleted record’s child records that have a lookup to it.
• Creating a history / audit record for it in another custom object.
• Send a notification to a person or group when certain records are deleted.

Solution’s Timing Averages After 10 Runs

Before Delete Apex Trigger	Before Delete Flow
94.7 milliseconds	152.3 milliseconds

Methodology

The history / audit record use case is simulated. Whenever a record is deleted, an audit record in a separate object is created to record that event.

For each solution, a custom object was created to hold the records. 200 records are inserted in each solution’s custom object using apex from Execute Anonymous using VS Code and then those 200 records are deleted. Each solution creates 200 audit records in the same “Audit” custom object. Immediately before and after the delete statement Limits.getCPUTime is invoked. The start time in milliseconds is subtracted from the end time to determine the overall insertion time. These results are then recorded in a Benchmark Result custom object.

System.debug was avoided because turning on system.debug usually causes everything to be slower. Dan Appleman and Robert Watson shared that in their Dark Art of CPU Benchmarking presentation. Parsing each debug log after each benchmark run is also tedious.

The timings shown include the general overhead of deleting 200 records. As a result, the timings shouldn’t be interpreted as each operation takes X time. Each one is X plus Y overhead.

Before Delete Flow

This before delete flow has a create records element to create the audit record.

10 Run Timings

Run #	Time in Milliseconds
1	138
2	151
3	182
4	137
5	136
6	149
7	157
8	153
9	165
10	155

Average: 152.3 milliseconds

Before Delete Apex Trigger

An Apex trigger with only the Before Delete event was created on the object which creates an audit record for each deleted record and then inserts them all at the end.

10 Run Timings

Run #	Time in Milliseconds
1	113
2	105
3	88
4	81
5	93
6	92
7	101
8	88
9	94
10	92

Average: 94.7 milliseconds

Before Delete Conclusions

Either option runs really fast. 150 ms vs 94 is not that much different in absolute terms. If possible, use the before delete option first and the Apex trigger option second. This certainly depends on you and your team’s skill set as mentioned in the field update conclusions above.

Next Steps & Further Research

• Create another benchmarking blog post comparing one before save flow with a single decision but one assignment for each outcome depending on the criteria met VS having multiple before save flows but each one has one criteria and does one assignment. I’ve actually already done this but didn’t want this post to be too long. What do you think the results were? Let me know in the comments below.
  • Here’s that Benchmark

• Open source the benchmark and code so others can run them and extend it.

• Benchmark solution combinations such as an object with multiple solutions like before-save flows and apex triggers. Keir Bowden aka Bob Buzzard had some interesting results in Spring 20 Before Save Flows and Apex Triggers and Before Save Flows and Apex Triggers Part 2.

Resources

• Architect’s Guide to Building Record-Triggered Automation on Salesforce Using Clicks and Code – Salesforce’s guide and recommendations for record-triggered automation. It’s long but comprehensive!

• Dark Art of CPU Benchmarking – Dan Appleman and Robert Watson presented their methodology, findings, and results in this 2016 presentation. While the timings are obsolete, their guidance and insights remain. I had the pleasure of working with Robert at NimbleUser and he’s a great guy. I attended one of Dan’s Dreamforce 2011 or 2012 sessions and that was also great. I read his original Advanced Apex book but have to read the latest 4th edition where he discusses benchmarking further.

• The Return of The Dark Art of Benchmarking – This Time It’s Declarative! – Dan Appleman did a follow-up presentation at the 2020 Virtual Dreamin conference. His relative declarative performance timings correlate with mine.

• Spring 20 Before Save Flows and Apex Triggers and Before Save Flows and Apex Triggers Part 2 – Keir Bowden had some interesting results about how system.debug with CPU time limits can be skewed.

• Process Builder Optimization: Don’t Evaluate the Next Criteria! – Dan Appleman details why evaluating the next criteria in a process builder should not be done. Hint: evaluating the criteria nodes is very slow!

• Limits Profiler – Adrian Larson’s Github profiling project.

Let me know in the comments below if this was helpful and what you think.