I am looking to replace several legacy Workflow Rules and Process Builders with Salesforce Flow. However, I’m worried about hitting governor limits with complex loops. What are the best design patterns for a Salesforce Admin to use to ensure these flows remain scalable and don't cause row locking issues when multiple users update records simultaneously?
3 answers
To avoid governor limits, the golden rule is to never put a Data Element—like a Get, Update, or Create—inside a Loop. Instead, use a Collection Filter or Collection Sort to handle data within the flow's memory. Always try to bulkify your logic by gathering all changes into a record collection variable and performing a single Update at the very end of the process. This significantly reduces the number of DML statements. Also, consider using "Fast Field Updates" (Before-Save Flows) whenever possible, as they are much faster and more efficient than traditional after-save triggers
Are you planning to use a "One Flow Per Object" strategy to manage your automation, or are you creating individual flows for every specific business requirement? I am trying to figure out which approach is easier to maintain long-term for a growing org with multiple stakeholders.
Always use Subflows for repetitive logic. If you find yourself building the same notification or calculation in five different places, move it to a single auto-launched flow.
Spot on, Michael. Subflows are a lifesaver for maintenance. If the logic changes, you only update it once, and every parent flow reflects that change immediately.
Jennifer, the "One Flow Per Object" rule is becoming less strict now that Salesforce introduced Flow Trigger Explorer. It’s often better to have a few well-defined flows with clear naming conventions. This allows you to reorder execution without needing one giant, unmanageable flow that is impossible to debug or document for other admins.