Be the first to like this
People using some combination of Apex and Flow/Process Builder can experience ‘Too many DML statements’ or ‘CPU Time Limit exceeded’ exceptions. Resist the urge to fingerpoint at a specific implementation detail or an AppExchange Package and test your flows during development for specific scenarios including differing batch sizes.
By testing your flows with various batch sizes, you will better understand how Flow and Apex handle bulkification differently. The talk was about getting a grip on what is actually happening between Process Builder and Sub Processes or Process Builder and invocable methods.
We took measurements for all kinds of scenarios and found that, while showing good performance on a per-record bases, performance for any process builder-based solution that invokes Subprocesses or Flows shows a significant increase of CPU time consumption for every new batch of 200 records that are processed in a transaction. This is best consumed in form of our visuals available in the slides and the Github repository. Please also note that Process Builder uses SOQL Queries in order to do its job, even when you’re not explicitly reaching to parent or child object, but only update a field on the record itself.
So how does Process Builder bulkify from Apex? As the documentation states:
“When multiple interviews for the same flow run in one transaction, each interview runs until it reaches a bulkifiable element. Salesforce takes all the interviews that stopped at the same element and intelligently executes those operations together.”
Imagine 2000 records being inserted via Apex and a Process Builder Process is responsible for setting a Boolean on Insert.
For each batch of 200 records
process builder uses a query to get the 200 records
instantiates one flow interview per record
waits for all 200 interviews to reach the same bulkifiable element (record update in our case)
executes the bulkifiable action for all 200 interviews together
It is an important question at design time, if my Process Builder/Flow Implementation will be faced with more than one batch. It is also worth noting that trying to ‘bulkify’ process builder+flow yourself might achieve the opposite: slower running solutions, and higher system limit consumption.
The repo containing sample code for the benchmarks, sample data and a detailed readme, can be found at https://github.com/dstdia/CzechDreamin19
Reach out to @ch_sz_knapp and @stangomat on Twitter