This article reviews recursion in Salesforce flows and how to prevent it. It is intended for Fullcast and Salesforce administrators and focuses on strategies for updating account owners and managing account team members when setting up automation to manage data from Fullcast.
What is Recursion?
In Salesforce, recursion or recursive behavior occurs when an automation, most commonly a flow, inadvertently triggers itself or other flows repeatedly in a cyclical manner. This can quickly lead to exceeding Salesforce governor limits, such as data modification (DML) limits or transaction limits within a short period.
A common scenario where recursion arises is with record-triggered flows. For example, a flow that triggers every time an opportunity record is updated and then includes an action to update the same opportunity record risks triggering itself again immediately after the first update completes.
Another potential source of recursion is within loop functions in flows. If an update to a record is placed inside a loop, it can cause that same record to be processed repeatedly within the same flow execution, potentially leading to errors.
Salesforce best practices, such as implementing tight entry criteria on record-triggered flows (e.g., only run when specific fields change) and avoiding updates within loops, are designed to prevent these common recursion scenarios.
Recursion and Fullcast
When Fullcast updates go-to-market information, such as which roles and people have coverage over a specific territory, it writes this data to the account team member object. This standard export configuration exists specifically because the account record tends to be very crowded already. Nonetheless, a common requirement is to reflect some of this information directly on the account record itself, for example, by populating fields like CSM or BDR, or by updating the account owner based on a specific role on the account team. If you
The potential for recursion arises because Salesforce standard functionality wipes out account team members whenever the account owner field is updated. Consequently, automation is often implemented to re-add the necessary account team members for the new owner. This re-creation of account team members is where a recursive loop can occur, especially with flows that trigger on the creation of account team member records and then update the related account. The very act of re-adding the team can trigger the flow again, leading to a cycle of updates and potential governor limit issues. This is a direct consequence of standard Salesforce behavior regarding account owner changes and account teams.
Strategies to avoid recursion
Here are several strategies to avoid recursive behavior when building automation related to Fullcast data:
1. Let account team members be wiped (with caution)
If you are newly implementing account team members specifically for Fullcast and the account executive is the only team member initially created, you might consider allowing the standard Salesforce behavior of wiping the team upon owner change.
However, carefully evaluate if other team members might be added manually or through other processes, as they would also be removed.
Note that Fullcast's nightly sync primarily looks for discrepancies and might re-add the account executive to the team if your Fullcast configuration dictates it. Additionally, the nightly sync only processes accounts with committed changes, so the impact might be limited.
2. Implement recursion prevention strategies in your flows
Depending on whether you are facing single-transaction or multi-transaction recursion, different approaches are needed:
Single-transaction recursion: This type of recursion occurs within a single execution of a flow, often seen with loops. If you encounter a “Too many DML statements” error, this type of recursion is probably the culprit.
Boolean variable (limited scope): use a boolean variable within the flow to track if a specific action has already been performed. At the beginning of the flow or within a loop, check the value of this variable. If it's true, skip the action. Set the variable to true after the action is performed. However, this method only works within the same flow execution and will not prevent recursion across multiple flow triggers.
Multi-transaction recursion: this occurs when a flow completes and its actions trigger another execution of the same or a different flow. Asynchronous flows inherently operate in separate transactions, making this the more likely scenario for Fullcast-related automation.
Custom field on account team member: A robust solution for multi-transaction recursion involves using a custom field on the account team member object.
Date/time field: Create a date/time field (e.g., "last owner update flow run"). When your flow runs and processes an account team member (e.g., to update the account owner), stamp this field with the current date and time.
Entry criteria: Modify your flow's trigger criteria to only process account team member records where this date/time field is older than a specific threshold (e.g., 23 hours). This ensures that the flow will not repeatedly process the same account team members within a short timeframe, breaking the recursive loop.
Avoid boolean fields with scheduled resets: While a Boolean field could be used, it would require a separate scheduled flow to reset the field periodically, adding complexity. A date/time field offers a more self-managing solution.
Apex trigger with static variables or custom setting/metadata: for organizations with Apex development capabilities, a custom Apex trigger on the account team member object can offer more precise control over recursive behavior.
Static Boolean variable: within a single transaction, an Apex trigger can use a static Boolean variable. This variable is set to true when the trigger first executes. Subsequent executions within the same transaction check this variable; if it's true, the logic is bypassed, preventing same-transaction recursion. This is effective for immediate, synchronous recursion.
Custom setting/metadata for cross-transaction control: To manage recursion across multiple transactions (similar to the multi-transaction scenario described earlier), Apex can leverage a Custom Setting or Custom Metadata Type.
Flag or Timestamp: Create a custom field (e.g., a checkbox or a date/time field) within a custom setting or custom metadata record.
Logic: The Apex trigger would check this setting before processing. If the flag is set or the timestamp is recent, the trigger can skip execution. After processing, the trigger updates the flag or timestamp. This approach centralizes the recursion control mechanism, managed via code.
Benefit: This provides a highly customizable and potentially more performant way to manage recursion, especially if complex conditional logic is required before deciding to run the automation.
3. Leverage asynchronous flows
It is highly recommended that any automation you build to manage data coming from Fullcast should be configured as asynchronous (e.g., using scheduled flows or after-save record-triggered flows).
Asynchronous processing ensures that each execution runs in a separate transaction. Even if a flow were to trigger itself again, it would be in a new transaction, mitigating the risk of immediate governor limit issues.
4. Thorough testing
Recursion issues will not appear in debug logs because the debugger operates in a single transaction.
It is crucial to conduct thorough testing in a sandbox environment with realistic data volumes and scenarios to identify and prevent recursive behavior.
Work closely with your Fullcast team, as they can provide valuable insights into potential pitfalls and help you design appropriate testing scenarios.
5. Consider not updating the account owner
Remember, if you don’t have automation to update account owners based on account team changes, recursion risk from Fullcast data and account team changes is greatly reduced.
If your business processes allow, consider not automating the update of the account owner based on the account team member role.
Instead of relying solely on the account owner field, you can utilize custom lookup fields on the account (e.g., "csm lookup," "bdr lookup") to represent key roles. Updating these fields based on account team members will not trigger the standard Salesforce functionality that wipes out the account team.
By understanding the causes of recursion and implementing these preventative strategies, you can build robust and reliable automation to effectively manage Fullcast data within your Salesforce environment. Remember to prioritize asynchronous processing and thorough testing to avoid unexpected issues and ensure the smooth operation of your Fullcast integration.