Salesforce Automation Use Cases: Flows vs. Apex Triggers

Salesforce is continuously enhancing Flow Builder every release, making its capability closer to Apex triggers. While Apex trigger excels at handling very complex logic and bulk operations, Flow Builder empowers admins to create powerful automation using point-and-click interface. However, many developers still prefer Apex over Flow due to its flexibility, precision, and ability to handle advanced use cases that go beyond the capabilities of declarative tools. Personally, I am using Apex for anything complex that I can't do with Flow.

In this article, we'll explore some real-world scenarios, analyzing the best tool for each - whether it's Flow or Apex - based on the complexity and requirements of the use case.

Use Case 1

A company uses Salesforce to manage Opportunities and their related Opportunity Products. When the Quantity or Unit Price of an Opportunity Product is updated, the parent Opportunity’s Total Amount field should reflect the sum of all its related Opportunity Products.

Analysis:

• If you think this can be solved with a Flow, you’re correct! A Record-Triggered Flow is ideal for this scenario when updates to Opportunity Products are straightforward. The Flow can trigger on changes to the Quantity or Unit Price fields, retrieve all related Opportunity Products, calculate the total, and update the parent Opportunity’s Total Amount field. This approach is simple, requires no code, and is well-suited to Salesforce’s declarative automation tools.
• However, if you think Apex might be required, you’re not wrong either. For scenarios with bulk updates or more complex logic, such as excluding certain Opportunity Products or applying conditional calculations, Apex Triggers would be more effective. Apex handles larger datasets and advanced operations more efficiently. While both options work, Flow is typically the better choice for simpler use cases due to its ease of use and maintainability.

Use Case 2

A company wants to streamline follow-up tasks for their sales team. Whenever an Opportunity is marked as “Closed Won,” a follow-up Task should automatically be created for the Opportunity owner, reminding them to send a thank-you email to the customer.

Analysis:

• If you think this can be done using a Flow, you’re right! A Record-Triggered Flow is perfect for this scenario when creating a single Task per Opportunity. The Flow can trigger on the Opportunity’s stage change, populate the Task details (e.g., due date, subject, and assigned owner), and create the Task. This makes it quick and easy to implement without needing custom code.
• Now, if you’re considering Apex, you’re not wrong either—especially if the logic involves creating multiple related records or handling more advanced conditions. For more advanced scenarios, such as creating multiple Tasks for different team members or varying Task content based on Opportunity size, Apex provides greater flexibility. However, for simple use cases like this one, Flow is the better option due to its straightforward setup and maintainability

Use Case 3

A company frequently imports large batches of Contact records into Salesforce from an external system. For every imported Contact, their associated Account’s Total Contacts field needs to be updated to reflect the number of Contacts linked to that Account.

Analysis:

• If you think this scenario could be handled using a Flow, it would be challenging. Flows can struggle with bulk data operations due to Salesforce’s governor limits. A Record-Triggered Flow would execute for each imported record, potentially hitting limits when processing thousands of Contacts. This makes Flow inefficient for bulk processing.
• If you think Apex is the better option, you’re absolutely correct. Apex Triggers excel in handling large-scale operations. Apex processes records in bulk, ensuring that the Total Contacts field on Accounts is updated efficiently without hitting limits. In this scenario, Apex is the superior choice for scalability and performance.

Use Case 4

The company has a policy that restricts discounts on certain product categories to a maximum of 15% for small accounts (annual revenue below $1 million). For larger accounts, discounts up to 25% are allowed. If the discount exceeds these thresholds, the Opportunity cannot be saved, and an error message should notify the user of the violation.

Analysis:

• If you think this can be handled using a Flow, you’re correct! A Record-Triggered Flow can evaluate the discount against the company’s rules in real time. By using the Flow’s built-in validation features, such as the “Add Error” action, users can be alerted immediately when their inputs don’t meet the criteria. This approach ensures that the logic is declarative and easy to update if the rules change in the future.
• While Apex Triggers can handle this validation, they might not be the best choice here. Writing a trigger adds unnecessary complexity for a scenario that can be solved declaratively. Flows allow for flexibility, easier maintenance, and faster updates, making them the ideal tool for medium-complexity validation scenarios like this.

Use Case 5

A retail company wants to integrate Salesforce with their external email marketing platform. Whenever a new Lead is created in Salesforce, the system needs to process complex data transformations before adding the Lead to a subscription list in the email marketing platform. 

The integration requires combining data from multiple objects related to the Lead (e.g., Campaign Memberships, custom Preferences, and associated Account data) and formatting it into a specific JSON structure required by the external system’s API. Additionally, the email marketing platform provides a response that must be parsed to update Salesforce with the subscription status and a unique subscription ID.

Analysis:

• If you think this integration can be handled using a Flow, you’re partially correct. While a Record-Triggered Flow can trigger when a Lead is created and make an HTTP callout, it struggles with handling complex data transformations, such as aggregating data from multiple objects and creating nested JSON structures. Furthermore, parsing the API response to update multiple Salesforce records with details like subscription status and unique subscription ID exceeds Flow’s capabilities. These limitations make Flow impractical for this use case.
• Apex is the better choice here. It can efficiently query and aggregate data from multiple related objects, format it into a complex JSON payload that meets the external API’s requirements, and handle nested or dynamic data structures. Apex can also process the API response, extract key details such as subscription status and ID, and update multiple Salesforce records to ensure synchronization. Additionally, Apex offers robust error handling, allowing retries for failed requests, logging for debugging, and sending notifications for errors. This makes Apex the more reliable and scalable option for such complex integrations.

Conclusion

Flow Builder and Apex Triggers are essential tools for automating processes in Salesforce. Each has its strengths and weaknesses. Choosing the right tool depends on the specific requirements of your use case, but with the right approach, both can help streamline operations and enhance productivity. By understanding the capabilities and limitations of each, you can make informed decisions to build scalable, efficient, and reliable solutions.

The table below summarizes when to use each tool.

Scenario	When to Use Flow	When to User Apex Triggers
Updating Fields on the Same Object	When updating a field on the same object based on straightforward conditions (e.g., field changes)	Flow handles these efficiently without code, except for complex criteria
Updating Parent or Child Records	When updating a related record with straightforward, simple logic	When the update involves multiple objects or complex conditions requiring custom logic
Bulk Data Operations	Not ideal — Flows struggle with governor limits during bulk updates or imports	When handling bulk updates efficiently (e.g., updating child records in response to changes in a parent record
Integrations with External System	Effective for basic API integrations, such as HTTP Callouts or Platform Events with minimal data transformations	Required for advanced integrations involving nested JSON, real-time API calls, or complex response parsing.
Complex Validation Rules	Best for straightforward record validations that rely on a single object	When enforcing intricate validation logic that spans multiple or unrelated records or objects