by Aidan Harding 
The choice between writing custom Apex code or using declarative tools in Salesforce has always been a difficult one to make. Process Builder is capable of more than Workflow was, but it came at a big performance cost. In this article, Roger Mitchell measures that performance cost again. And it looks like things have improved considerably since 2016.
From the numbers in the article, the gap between Process Builder and code has come down considerably. Particularly if you are handling many records at once.
It would be interesting to run those experiments with higher numbers of records. 200 is a magic threshold in Salesforce where Apex triggers get run multiple times e.g. if 400 records are updated and a trigger runs on them, Salesforce actually runs the trigger once for the first 200, then again for the next 200.
And it would be interesting to see how the growth in records affects the time cost e.g. Does Process Builder have a one-off cost, but then the time cost increments along the same curve as Apex code?
Certainly it’s food for thought and time to adjust our decision making in Process Builder vs. Apex. But, do not forget the other important factors:
- Properly written Apex code comes with tests, Process Builder has no facility for tests
- Process Builder’s error handling is not ideal
- Incrementally adding a new Process Builder flow every time you think of a new requirement is a bit like eating a cake a week. No individual cake is a terrible idea, but a year down the line you and your Salesforce org could end up getting pretty bloated
Process Builder was much slower than an Apex trigger back in December 2016, but has improved massively as of August 2018.