Stop Mixing Salesforce Technology

Have you ever received a CPU time limit exceeded error in Salesforce? You are not alone! The first time I saw that error I wondered, ‘What does that mean and how do I fix it?’ After googling for a little bit, I found out that it means a process is taking too long and is unable to be completed. Salesforce’s CPU time limit for synchronous transactions is 10 seconds and 60 seconds for asynchronous transactions. CPU time varies per automation process and per execution of that process, which is why it is important to stay well within the CPU time limit. Understanding how the different automation technologies work together in Salesforce can help developers and admins better understand how to create the most optimized and efficient organization. I conducted an analysis to determine the average CPU time for each Salesforce automation technology, both individually and in combination with other automation technologies so that you can avoid ever seeing this error.

Setting Up the Testing Environment

To test the average CPU time, I created an empty Salesforce Developer Org to run my tests in. To ensure the data collected is as accurate as possible, I ran some initial tests in the org to determine if there would be any CPU time to begin with. I then ran a script in the developer console that inserted 100 records into the org. I recorded the CPU time taken to insert the records, and then ran another script that deleted the records inserted. This process was repeated 20 times, which is shown in the chart below. The average CPU time for the empty org was 0.

Next, I needed to determine whether a deactivated automation process affects CPU time. If it does not affect CPU time, it would allow me to test technologies on the same object while leaving the technologies not currently being tested deactivated. For example, if I had previously been testing a process builder, deactivated it and wanted to test a workflow next, would it affect the workflow's CPU time? I created a custom object called Efficiency Test and added a trigger on it that contained commented out code to discover if it affects CPU time. I followed the same testing process as before, running a script in the developer console to insert 100 records, recording the CPU time, running another script to delete the inserted records. I repeated this process 20 more times. This test resulted in an average CPU time of 0. I followed the same testing process previously mentioned for a deactivated before flow, process builder, and workflow. I received an average CPU time of 0 for those as well. I determined that deactivated automation processes do not affect CPU time in an organization. This data is shown in the chart below.

Testing Process and Results

I decided to split the testing into two categories: simple and complex tests. A simple test involved updating a field value, while a complex test involved querying a record from a parent object and setting the value of a field on that parent record. A before insert trigger, workflow, process builder, and before flow were tested during the simple test. They were tested individually and in combination with each other. Every test took place on the custom Efficiency Test object. I also created four different custom fields to be updated by each automation. For the simple test, I followed the same process as above with a few modifications. I inserted 1000 records using a script in the developer console, recorded the CPU time, and ran another script to delete the previously created records. I followed this process 20 times for each type of the automation technologies and their combinations.

For example, the simple trigger test below updated a custom field called Type on Efficiency Test with a test value on insert of an Efficiency Test record.

 if (Trigger.isbefore){
 
    for (Efficiency_Test__c testTrigger:Trigger.new ) {
        testTrigger.Type__c = 'Test';
    }
   
 }

For the complex test, I followed the same testing process as before, with some slight modifications. All complex tests occured on the Efficiency Test object. I also create four custom fields on Account to be updated during the complex test. I ran a script to insert 500 records in the developer console, recorded the CPU time, and ran another script to immediately delete those records. I was only able to insert 500 records instead of 1000 due to hitting the CPU time limit. I followed this process 20 times per automation category.  I followed this process for an after flow, process builder, workflow, and after insert trigger both individually and the different combinations of technologies

For example, the complex trigger test below queried for related parent accounts and updated a custom field on Account with a test value.

 if (Trigger.isAfter){
    Set accID = new Set();

    for (Efficiency_Test__c test:Trigger.new) {
        if(test.Account_Master__c != null) {
            accID.add(test.Account_Master__c);
        }
    }
    if (accID.size ()>0) {
        List accountList = new List();
        for (Account ac: [select id, Trigger_Test__c from Account where id in: accID]) {
            ac.Trigger_Test__c = 'Test Trigger';
            accountList.add(ac);
        }

        if (accountList.size() > 0)
        update accountList;
    }
 }

Analysis

The results, shown by the chart below, indicated that a before flow, process builder, and workflow combined have the highest average CPU time of a little over 5 seconds for the simple test. Workflow resulted in an average of 0 CPU time, although they are not the best to use in terms of multiple commits. A process builder has the highest average CPU time of a salesforce automation process running alone, with an average of almost 4 seconds.

Like the simple test, workflow resulted in an average of 0 CPU time in the complex test. After insert trigger, after flow, and process builder required the most CPU time with an average of around 9 seconds. Individually, an after flow required the most time with an average of close to 4 seconds. The average CPU time for the complex test of the other technologies and combinations of technologies can be found in the chart below.

You may be wondering 'What automation processes should I be using then?'

We recommend:

• Triggers for complex long-term logic on an object.
• Before flows for field updates and simple logic if there isn't going to be much more logic added to the object later on.
• After flows for sending emails.

We don't recommend mixing technologies.

The last thing anyone wants is a slow salesforce instance, so keep these charts in mind when choosing what salesforce automation process to work with. Although workflow rules and process builders will be retiring in the future, it is still important to understand how the automation technologies interact with each other and know how to best migrate your processes when those technologies retire. If your salesforce instance is too slow, you’re hitting CPU limits, or you just want a more efficient system, contact us for a free consultation and we can help you get back on track. And leave a comment below with a salesforce data analysis you would like to see in the future.