Wednesday, July 16, 2014

Using Flow Rather than Apex: Performance Tests

Some of the newest Flow features allow for working with collections of records and using a single operation for adding those records to or retrieving them from the Salesforce datatbase.  In the past, Flow could only create or retrieve a single record at a time, but recent features give administrators a visual interface for creating powerful and automated solutions to their business problems using clicks-not-code.

Checking time required and limits for Flow.
As the capabilities of Flow converge with those of Apex programming, administrators will no doubt start handling some of the same tasks with Flow that previously required Apex.  Creating and updating records automatically is a great example of a task that administrators with no programming experience can now manage themselves, for multiple records at a time, with Flow and no Apex code.

But if you have a choice between two tools, it is interesting to see how they compare.  Flow is obviously easier than Apex for anyone not trained to code, while Apex is more flexible.

Benchmarking performance differences reveals the impact of using Flow to replace Apex.  I tested this by coming up with both a Flow and a bit of Apex code to create new records for a custom object and comparing their performance according to feedback from the developer console. 

Performance Comparison

To start, I created a simple bit of Apex code to add 1,000 records to a custom object.  The developer console tracked CPU usage as well as the number of database manipulation language (DML) statements, both of which are performance concerns for anyone watching their governor limits.

I then replicated the code using Flow to add a large number of records to my custom object so that I could compare the performance relative to those same governor limits.  Thanks to the collection variable available with Summer '14, I was able to create a Flow that managed a single DML statement for multiple record insert operations using a Fast Create element.  Previously, this would require a single Record Create element for each new record and so the number of DML statements could become excessive and slow without these new features.

Unfortunately, Flow was more restrictive on the number of records I could manipulate with both the collection variable and the Fast Create element.

For the collection variable, I found that I was only able to hold 499 records with a single variable.  Apex is not so limited with lists and arrays.  This limit meant that I could not create as many records with Flow as I could with Apex.

For the Fast Create element, I was even further limted by Flow.  With Apex, up to 200 records can be insterted with a single DML statement and more records can be submitted with insert operation.  Salesforce automatically divides the operation into multiple statements for blocks of up to 200 records.  For example, 201 records result in 2 DML statements according to the debug console.  My Flow got stuck at 200 records, I could not use the Fast Create when my collection contained more.  Even with 200 records, the debug console reported 2 DML statements being executed for the Flow.

Having to reduce my test size meant that neither the Apex nor the Flow had any measurable use of CPU time.  I look forward to being able to insert more records to better compare performance.

One of the Salesforce critical update messages suggests that enabling governor limits for Flows will have an impact on performance.  You should test your Flows with this update enabled before it goes into effect by default in 2015.


  1. @Bonny, is there a check box for "Enabling Governor Limits" somewhere? I just created a flow with a loop in my Sandbox that ran great and it will not run in my Prod Org as I'm receiving the error "The user is attempting to modify a number of records larger than the Governor Limit for records updated."

  2. I think you will find that in your scheduled updates list. If you are a system admin, you probably get popups every now and then about system updates that you may want to test before they become active on your org. Enabling Governor Limits was one of those system updates on my org.