Developer Dilemma... Flow vs Apex : Set collection

The ongoing struggle between Flow and Apex for automating tasks in Salesforce is a constant challenge for developers and architects, with no clear-cut answer. It all depends on various factors, and the decision we make today may not be relevant or correct in the future as clients extend their solutions to new business units or geographical regions, so its important to look at future scalability and design accordingly.

As developers, we typically lean towards configuration-based solutions for simpler tasks, following Salesforce best practices. But every now and then, we stumble upon a requirement that seems straightforward. That's what happened to me recently when I encountered a task that seemed perfect for record-triggered automation with flows.

For a recent use case, I planned to leverage platform events for near-real-time calculations and avoid synchronous processes that could bog down transactions, particularly on high-traffic objects like order lines.

This design is essentially split into two execution contexts. The first part is straightforward: order line updates need to trigger rollup calculations at the order level. To achieve this, we can use a simple record-triggered flow to collect unique order Ids and fire a platform event at the end. But to my surprise, Lightning flows currently lack native support for Set<Id>. 

Set<Id> plays a significant role in optimizing Salesforce processing, especially in scenarios involving hundreds or thousands of order line items. When order lines are updated in bulk, it makes sense to perform calculations at the order level only once, rather than for every instance of an order line update. This is easily accomplished with Apex triggers, as we can collect Order Ids in a Set and internally handle calculations on unique sets of Ids.

Now, let's dive into the debate of Flow vs Apex Code. Currently, Flow lacks native support for Set<Id>. Let's explore how poorly Flow performs when we have to implement a workaround to ensure record id uniqueness.

Flow - workaround for Set: 

You can ensure the uniqueness of Ids in a collection variable within flows by utilizing the "Remove All" and "Add" operators in Flow Assignment. However, it's important to note that this approach introduces additional performance overhead as a tradeoff. 

    

Time to test the performance: 

To calculate how bad the performance of this flow when compared with Apex. I performed a dummy update using an example order with 1000 order lines.

Now, let's deactivate the flow and try the Apex Trigger. 

When the CPU time is compared, Apex trigger is a clear winner with a native support for Set. 

Trying to implement another workaround by using an Apex-defined variable within Lightning Flow proved unsuccessful. Salesforce doesn't seem to like it.

Idea Link : https://ideas.salesforce.com/s/idea/a0B8W00000QcWNzUAN/support-for-set-collection-in-invocable-variable

Record Triggered Automation Design guide : https://architect.salesforce.com/decision-guides/trigger-automation

In conclusion, after several attempts to implement Set<Id> in Flow and careful consideration of the architecture decision matrix and guidelines from architect.salesforce.com, I've made the decision to proceed with an Apex trigger. Given the anticipated high volume of data in my scenario and the absence of indications from Salesforce regarding support for complex data type processing in flows in the near future, this choice aligns with practicality and long-term efficiency.