What makes Process Builder so bad?

This is probably a good time to discuss why Process Builder is bad, given that Salesforce recently at Dreamforce ’21 announced the retirement of Process Builder(and Workflow rules) by 2023.

The purpose of this article is to share why it is important for Admins, Developers and Architects to move away from Process Builder and encourage them to use Flows.

#1 Record updates to same record

Building on what we discussed in the previous article, Why Before save flows are faster than Process Builder?, we already saw that doing record updates on same the record using Process Builder is bad because you end up making a DML(and a SQOL query).

NOTE: In some use cases, it’s a necessarily evil to do record updates in after save context, for example, automation based on record Id and auto-number fields.

#2 Cross object updates

Cross object updates are the updates to either the related parent record or related child, record(s) of the current record.

For every Action type of ‘Update Records'(same record or cross object update), Process builder consumes a SOQL query and a DML. A DML is necessary for updating related record(s), but a SQOL query?

Let’s further break the cross object update into Parent record update and Child records update.

For parent record update, you can certainly avoid doing a SQOL query in flows.

For Child records update, you do need a SOQL query. However, they’re some bulkification issues around child record updates; generally happens for a fairly large amount of records.

#3 Recursion

Process Builder can be set to be invoked recursively. This is maybe desired for very few use cases, but the overall impact of this can be quite huge, especially, if you have 1 Process per object. This is one of the most prominent reasons why a lot of orgs’ transactions using Process Builder are slow as F🐢CK. NOTE: Flows do not get invoked recursively.

#4 Overall performance

Process Builder, under the hood is nothing but a flow. So eventually, behind the scenes, Process Builder runs as a flow. However, the Process Builder at design time compiles(as a flow, eventually to code) very inefficiently which makes the actual flow run slower.

Conclusion

Based on all this information, it’s quite easy to deduce Process Builder is not generally slower, but also expensive when it comes to Governor limits usage.

Hope you find this one useful! Catch you in the next one! ✌ And thank you for being an awesome reader! Subscribe to this blog for receiving all the latest updates straight to your inbox. 🙂