Summer-20 was powerful with including key features which helped to decide and execute flows based on record creation and edits. With Winter-21 Release flows become more powerful and covers all scenarios related to data manipulation (Except Un-Delete). Which means when we Create, Edit (Update) or Delete a record we can invoke a flow. Delete is introduced in Winter-21 which completes the CUD operations under a flow. We were excited to know about the features and did a pilot for a few of our customers to migrate the business logic from Triggers to Flows. The result is too good to be real, but we happened to successfully reduce > 85% of code from the Triggers.
Triggers execute on the Database Layer and execute based on the defined trigger events (e.g. Before Insert, After Update, After Delete). This exact capability is now available in Flows which enables non-coders to define business logic within a flow. These could be complex business processes as well. When doing it for our customers we were able to have a 1-1 map 80% of the scenarios directly into the flows. While there are possibilities to leverage a portion of the remainder, clubbing Process Builders and Flows together.
Triggers often contain the most complex logic. If triggers are not designed and written well, it can have serious repercussions like:
- CPU Timeout
- 101 SOQL Errors
- Trigger Recursion causing unintended results
We can simply start by creating a new Flow and select Record Triggered Flow. This then enables us to select the Object whose manipulation would invoke the Flow Same as we do in a trigger.
Now this is the exact same step we write in Apex Program to when the trigger needs to be involved
Finally, we select the object on which we want the flow to be triggered off.
Once the base is all set, we go ahead and add the required business logic like getting related or even unrelated records and add decisions, assignments or DML statements.
Key Benefits:
- Reduced Lines of Code in the Salesforce Instance
- Reduced Developer Dependencies
- Option to get away with test classes (Recommendation would still be to write test classes for Workflows, Process Builders and Flows)
- Faster processing of Business Automation
- Faster Deployments (in case test classes are not written)
- Save on Governor Limits
Let us consider a few business scenarios that provide some insight:
Scenario 1:
Custom-Look-Up Rollup
A perfect example can be a Custom-Roll up Summary based on Lookup (assuming there is no un-delete scenario). We can leverage flows and remove some packages altogether and remove some unnecessary code which performs a similar implementation.
Scenario 2:
Automate Line Item addition/updation governed from Opportunity
Also, consider a scenario where the business requires to add/update line Items to an Opportunity based on certain checkpoints, which could be – does the Opportunity include an Insurance and what is the Insurance Amount that the customer has opted for. If such holds true, then automatically add an Insurance Line Item to the Opportunity.
Scenario 3:
Get information from an unrelated object
Let us consider a scenario where there is a Master Table of Zip Code to CBSA / County and we want the county / CBSA to be populated on Accounts / Contacts based on the address zip. Leveraging record triggered flows this can be achieved with zero lines of code.
Summary:
Winter-21 release features are incredibly powerful considering the updates to flow. Recommendation would be revisiting your trigger and process builder implementation and there is a very-high chance of moving most of the logic to Flows. A System Architect should be able to help you analyze the implementation and provide you with recommendations post reviewing your implementation.