function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Sebastian KalotaSebastian Kalota 

Apex Triggers vs Record Triggered Flows - Considerations & Best Practice

Hello all,

Since I am aware of the general best practice to make sure that out-of-box automation tools are being utilized properly I am wondering what are the cons and pros of two approaches I have in mind:
1. Have all automations STARTING with Flows, being extended by Apex Code only as and when it's needed. 
2. Writing Apex Triggers to handle automations. 

How does that translate to efficiency? 

I think that the approach with Flows being defined for all objects as initiators of automations can help easily visualize the automation path. Say I would like to write a custom Apex Class that sends the data to another system via HTTP to push the same data to the other platform whenever a record is created. 

Do you think that defining a Flow Trigger that then calls an Apex Class is a good practice? 

Also, perhaps there are considerations about whether we need to re-process some data in SF when we receive a response, then perhaps Before-Save operation would be more efficient and for that reason alone we might want to go with Apex Trigger (since you can call Apex only in After-Save flow?) - so that's perhaps another consideration.

Let me know your thoughts folks - I think more or less I am right about the above, but I want to make sure that I am not missing any additional factors to ponder upon. 

Bryan Leaman 6Bryan Leaman 6
I like the idea conceptually of launching all triggered actions with flows, but in practice, I think you might encounter scalability issues.

We have one particular managed package that was initially extended with triggers and later extended even further with flows. Now, if there was just one flow for each object and it simply performed the updates it was well suited to and then passed all the selected records to a single invokable class that performed all the apex-related trigger-style updates, it might work fine.

But what we found was that in our case, the flows were inefficient and with the latest package upgrade, the packages processes changed enough that we started seeing CPU timeout errors frequently.

The solution that appears to be working for us was to eliminate as many flows as was feasible and pull that code into existing triggers.  I came to that solution using FinancialForce's wonderful "Apex Log Analyzer" for VS Code and seeing how many CPU seconds were consumed running flows vs trigger/apex code.

When it comes to scaling for large transaction volume and loads of triggers firing due to co-dependent record updates I believe triggers are far more efficient. Another consideration is that within a single request cycle, APEX code can use static methods & properties to cache data that should be static during a single request cycle rather than retrieving the same support data ever y time the trigger is fired. This technique has saved us hundreds of SOQL queries & CPU time. I don't believe flows have that kind of capability at present.