What’s new with Record-Triggered Automation in Salesforce?
Systems demonstrate automated behavior by enabling business processes to scale and meet key goals and objectives quickly. When automation is implemented correctly, it eliminates manual and repetitive tasks allowing users to focus more on high value tasks. Most often automation means translating business processes from one form to another, for example paper based form to digital forms and with every change comes an opportunity for transformation.
Record-Triggered automation is part of Flow Architecture where this automation focuses on trigger order of execution for Salesforce Records. Salesforce has introduced a new concept of low-code automation with the Flow to allow for significantly better performance when it comes to same-record field updates. However, additional complexity will be encountered by users who are unfamiliar with triggers and find this terminology confusing. So throughout this article, I will continue to refer to two options for triggers as “before save” and “after save”. In Flow Builder, these terms have been renamed as “fast field update” and “actions & related records”.
Let’s first understand the most common triggers in Salesforce, uses cases and the tools which are well-suited for each use as shown below:
Yes = with basic considerations, this is available and should work fine.
Not Ideal = this is possible, but with important and potentially limiting considerations.
No = Not available and no plans to support in any capacity in the next twelve months.
As shown above, for use cases which have multiple tools available and it is recommended that you implement and maintain the tool which incurs the lowest cost. This consideration would also highly depend on the team and expertise available in your team.
For example, if your team consists of Apex developers and already use a well-established CI/CD pipeline along with a well-managed framework for handling Apex triggers, it is probably cheaper to continue on this route to use Apex triggers. In this scenario, the cost of changing your organization’s operations to adapt to Flow development would increase costs significantly. On the other hand, if your team does not have consistent access to developers or you’d likely be better served by low-code solutions that more people can maintain rather than dedicated developers required to maintain several lines of code, then adapting to Flow would probably be better suited.
For a team with mixed skill sets or with admin-heavy skills, Flow triggers provide a compelling option that is more easier to debug, has low maintenance and provides better performance than any other no-code options available in the past. Flow triggers do not require heavy coding skills and allows the delivery of business process implementation to low-code developers enabling you to focus developer resources on high value projects and tasks that will utilize their skills efficiently to bring business to the organization.
Why do we need to use Flow for automation?
Back in Dreamforce 21’, Salesforce announced retirement for Process Builder and Workflow Rules. Since then many organizations have started switching to low-code and no-code solutions in order to improve efficiency and increase extensibility of Salesforce.
Flow is well architected to meet this demand of increased functionality, efficiency and extensibility required by Salesforce customers today. Below are some of the issues encountered with Workflow Rules and Process Builder:
Workflow Rules are used to perform same-record field updates and while they are believed to be fast, they cause a recursive save and will always be slower and more resource hungry than a single, functionally equivalent before-save flow trigger. Before-save updates in Flows are quicker because each record doesn't get saved to the database again. Avoiding this extra save procedure reduces the execution time increasing efficiency.
Workflow Rules have a completely different metadata and runtimes when compared to Flow. Flow not only offers better performance but better debugging, manageability and CI/CD improvements which can never be experienced using Workflows or Process Builder tools.
Although you may be familiar with Apex triggers, a flow that makes before-save updates is similar to ‘before’ Apex triggers. In a ‘Save’ procedure, before-save updates in flows are executed immediately prior to Apex before triggers.
Process Builder is always a harder to debug and less performant alternative to Flow.It has a difficult-to-read list view which combined with underlying metadata for a process resolves it to a mangled, less performant and often incomprehensible.In addition to shortcomings already cited, both Process Builder and Workflow Rules have an inefficient initialization phase that drives processing time across every save-order execution as it includes assignment rules, auto-response rules, workflow rules, and other customizations that take time to execute.
In practice, mostly before-save updates using Process Builder and Workflow Rules resolve to a no-op at runtime, which means that no operations are performed since criteria is not met and the long initialisation phase yields no benefit. This costly initialization phase has been eliminated in the new Flow architecture.
Salesforce is focusing investments on Flow and has closed all major functional gaps identified between Workflow Rules and Process Builder. However, there is still work required to close remaining gaps including enhanced formulas, entry conditions as well as usability improvements to streamline areas where Flow is more complex.
Same-Record Field Updates:
As discussed above, Workflow Rules or Process Builder processes are inefficient to implement same-record field update actions. In the same manner, same-record field updates are not recommended to be updated in after-save flow triggers either! Before-save trigger is recommended for the speed for update same-record field updates due to the following reasons:
The record’s field values are already loaded into memory and hence not required to be loaded again.
The update is performed by changing the values of the record in memory, and relying on the original underlying DML operation to save the changes to the database. In a save procedure, before-save updates in flows are executed immediately prior to Apex before triggers.
The main limitation of before-save flow triggers is that they are functionally sparse: you cannot extend a before-save flow trigger with Apex invocable actions or subflows. However, you can add anything to a before-save Apex trigger (except explicit DML on the underlying record). This is by design in order to support only those operations that will ensure performance gains.
High-Performance Batch Processing:
For “complex logic” in batch scenarios which include complex formulas, complex list processing, loading and transforming data from large numbers of records, looping over loops of loops, Apex triggers are the best option. Apex with its rich debugging and tooling capabilities contain a Map data type which will be retained during runtime and can be accessed in the recipient Apex invocable action.
While before-save flow triggers are not quite as performing as before-save Apex triggers, the impact of the overhead is somewhat reduced when the scope is within a broader transaction. Before-save flow triggers should still be fast enough for the vast majority of non-complex, same-record field update batch processes.
For batch processing which does not need to be triggered immediately during the initial phase of transaction, Flow has some capabilities to perform better although constrained with respect to Apex. Scheduled flows can currently do a batch operation up to 250,000 records per day and can be used for data sets that are unlikely to reach near that limit.
Scheduled paths in record-triggered flows also now support configurable batch-sizes, so admins are allowed to update batch sizes from default (200) to a higher number if required. This is useful for scenarios like external callouts that cannot support the default batch size.
Cross-Object CRUD Processing:
Creating, Updating and Deleting a record other than the record that triggered the transaction requires a database operation with any tool in Salesforce. The only tool which does not support cross-object CRUD processing for fast field updates is the before-save flow trigger.
Apex outperforms Flow in raw database operations in speed. It takes far less time for Apex runtime to prepare, perform and process the result for any specific database call (for example, a call to create a contact) than it takes Flow runtime to do the same. The flow can’t update values in records that are related to the triggering record. In practice, it makes more sense to identify inefficiencies in user implementations and fix them before looking into optimization of low level operations which will likely give greater benefits to the overall business process.
One of the most inefficient user implementations we come across regularly is the issue with multiple DML statements. Here is an example of an implementation of a flow trigger that updates two fields on a case's parent record with two Update Records elements.
In the above example, the flow has two DML operations (two save orders) to be executed at runtime. Combining the two field updates into a single ‘Update Record’ element will result in only one DML operation being executed at runtime. This would increase the inefficiency in executing this Flow.
Workflow Rules is reputed for performing better for save operations as they constrain the amount of DML operations as shown below:
Same-record field update actions are automatically consolidated into a single DML statement at runtime (as long as their criteria is met).
A similar runtime consolidation occurs for the immediate, detail-to-master cross-object field update actions across all Workflow rules for an object.
Cross-Object DML support is constrained in Workflow rules
Hence, for cross-object DML scenarios, it is recommended to minimize the unnecessary DML statement for faster execution either using Flow or Workflow Rules.
As a rule of thumb, for using flow for cross-object CRUD processing, the following best practices are recommended:
It’s crucial to know where all the DML statements are coming from, the logic may be spread across a few triggers and subflows. It is important to institutionalize strong documentation practices and design standards that enable efficient discovery of DML statements at design time.
Consolidating any DML statements that target the same record would result in fewer number of ‘Update Record’ elements which increases efficiency.
For complex use cases that require conditionally and/or sequential editing of multiple fields on related records, creating a temporary record variable or in-memory container for storing data while executing this use case is highly recommended. Update Record operations require temporary data in that variable during the flow’s logic sequence using the Assignment element to perform a single, explicit operation.
However, if you are not experiencing any performance issues, then you may just find this optimisation effort cumbersome.
Asynchronous Processing:
Asynchronous processing in one of the most commonly used processes in the world of programming. However, for record-change triggers, there are two ways to process them: synchronous processing and asynchronous processing. Often the request is to make changes synchronously during the trigger order of execution. However, synchronous processing is not always the right choice for processing record-change triggers especially with complex logic.
Let’s explore advantages and disadvantages of synchronous processing vs asynchronous processing:
Advantages of Synchronous Processing:
Database Transactions: Record-change triggers are used for fast-field updates and are configured to run during the initialisation phase of a transaction to optimize data operations. As seen in same-record field updates, in synchronous processing you can optimize these transactions because you already know that the record triggering this transaction will be updated. You can combine any additional DML into a single database transaction using a before-save trigger.
Rollbacks are consistent - Synchronous processing allows you to compile changes during initialisation of transaction which means that the overall changes to the database will be atomic from a data integrity perspective and rollbacks are easier to handle. So if a record-triggered flow updates all related contacts on an account, if another automation later in the transaction throws an error, the whole update will become void and no contacts will be updated.
However, synchronous processing is not always the right solution and do have some disadvantages as shown below:
Limited Time Window : The record-change trigger starts an open transaction to the database that cannot be committed until all logical steps have been executed as per trigger order of execution. However, this means that there is a limited time window in which all the logic needs to be executed because the database cannot be open for indefinite time. In the case of user-triggered record change, we don’t want the user to have a long delay in saving any updates made.Hence, asynchronous processing allows the user to carry on editing data while data is saved into the database using multiple threads.
Governor Limits: Governor limits are applicable to both Flow and Apex triggers and both have more permissive governor limits for asynchronous processing when compared to synchronous processing to ensure consistency.
External objects and callouts: In general, any request to access an external system would require a waiting period. Sometimes this waiting period may be too long to keep the transaction open. However, invocable actions get around this limitation by implementing custom logic for queueing their own execution after the original transaction has been completed. For example, email notifications and outbound messages have their own custom logic to overcome this limitation. However, this is not the same for other external actions and callouts and we recommend separating them into their own asynchronous processes wherever possible.
DML challenges: Occasionally, you may need to do cross-object CRUD during the initialization stage in a transaction like updating a contact and associated user after a particular change. As discussed above, these CRUD operations cannot be done in a single transaction and hence some use cases may require multiple transactions to be triggered via asynchronous processes.
Both Flow and Apex can offer asynchronous processing for use cases that require separate transactions for external callouts, complex logic or just simply take too long. Salesforce recommends that Apex triggers which implement asynchronous processing inside a Queueable Apex class. For Flow, salesforce recommend using them in after-save flow to achieve a similar result in a low-code manner.
Custom Validation Errors:
When it comes to asynchronous processing, additional care is required to design record-triggered automation particularly if the transaction requires callouts to external systems. The Run Asynchronously path in Flow usually meets many low-code requirements,but some complex ones around custom errors or configurable retries may work better with Apex instead.
As Flow provides no way to prevent DML operations from committing or to throw custom errors, the addError() Apex method is not supported when executed from Flow via Apex invocable method. However, Apex triggers provide this support to custom validation errors.
What’s new with Record-Triggered Automation?
There are countless articles around best practices for fast field updates and how to design record-triggered automation. For example, some have recommended using only one tool or framework per object, use one single flow with sub-flows for automation or split automation into smaller flows, etc.There is no one recommended way to design record-triggered automation and there will always be exceptions and rules that apply to certain use cases but not to all.
Both Flow and Apex offer automation for record-triggers. Flow’s low-code hides the underlying implementation or complexity adding at least one layer of abstraction. However, in terms of performance there is not much difference between Flow and Apex and in some instances Apex are more performant for complex processing.
The majority of changes required to a record don’t require automation that adds additional changes. However, you can configure entry conditions provided by Flows to dramatically increase the performance and run these automations only when a certain conditional state is achieved. Edits made on a record can be tracked and automation executes only when a defined criteria is met. So you can trigger a record-change automation when an opportunity is either closed or an opportunity status changed from open to closed. Both of these options can run automation efficiently to update opportunities.
Conclusion:
With Flow triggers, there is no need for automation to be compiled into a single flow. Neither single flow nor multiple flows have any major performance difference and both give better performance when compared to Workflow Rules and Process Builder. Ultimately, the best approach usually depends on what works well with your business and organization. The team setup and expertise will determine the best tools and methods for automation of your business processes.
Comments
Post a Comment