7.6 Automation Performance, Recursion, and Maintainability

Performance is an admin responsibility

Salesforce automation runs inside platform limits. Admins do not need to memorize every technical limit to make good decisions, but they must understand the pattern: too many queries, too many record operations, too much work per transaction, broad criteria, and repeated re-entry can fail or slow users down. A flow that seems small in the builder may run thousands of times during an integration job.

The first performance control is entry criteria. Do not start a record-triggered flow for every update if only one meaningful field change matters. Use conditions such as when a record is updated to meet criteria where appropriate. Compare prior and current values when the logic depends on a change. If the automation should run only for open cases, exclude closed cases at entry instead of checking much later.

The second control is where record operations happen. Avoid Get Records inside a loop when the flow can collect IDs and query once. Avoid Create, Update, or Delete Records inside a loop when the flow can build a collection and perform one operation. In screen flows, avoid expensive queries on every screen if the choices can be loaded once or filtered more tightly. Every record operation is a cost.

The third control is choosing the right timing. Before-save flows are faster for same-record updates because they do not perform a separate save. After-save flows are appropriate for related records and actions, but they can be more expensive and more prone to re-entry. Scheduled or async paths can reduce user wait time when the work does not need to finish before the user continues, but they require monitoring and different error handling.

Recursion and maintainability aid

Recursion is not always obvious. Suppose an after-save opportunity flow updates the parent account's Customer Status. An account after-save flow then updates all open opportunities to reflect account status. Those opportunity updates can start the original opportunity flow again. Even if the outcome eventually stops, the transaction may hit limits or create confusing field history. The admin should diagram cross-object updates before activation.

Maintainability does not always mean fewer flows at any cost. One giant flow with dozens of unrelated decisions can be hard to test and risky to edit. Many tiny flows on the same object can also be hard to predict. A common admin pattern is to organize record-triggered flows by object, timing, and business purpose, then document the order and responsibilities. The right structure depends on team size, release process, and how often the logic changes.

Subflows can improve maintainability when they represent stable reusable work. For example, a subflow that creates a standard onboarding task set may be called by a screen flow and a record-triggered flow. But subflows also create dependencies. A change for one caller can break another. Use explicit inputs and outputs, version notes, and regression tests for every caller.

Designing automation that lasts

A maintainable automation design can be explained in a few minutes. The admin can identify what starts it, which records it touches, which conditions stop it, what happens on failure, and how to deactivate or bypass it safely. If that explanation requires tracing ten unlabeled elements and three undocumented flows, the system is carrying support risk even if it currently works.

Performance checklist:

• Narrow entry criteria before the flow interview starts.
• Use before-save flows for same-record updates when no related action is needed.
• Query only needed records and fields, and avoid queries inside loops.
• Collect records and update them in bulk rather than one by one.
• Use scheduled or async paths only when delayed processing is acceptable.
• Test with bulk data and integration-style updates, not just one UI save.
• Monitor failed interviews and user reports after release.

Maintainability checklist:

• Use names that include object, event, timing, and outcome.
• Add descriptions that state business owner, purpose, and bypass assumptions.
• Keep decision names and outcome labels readable to non-builders.
• Remove obsolete versions and retired automation through a controlled cleanup process.
• Review active automation before creating new logic on the same object.
• Keep approval, validation, assignment, and escalation features in their natural lanes when they fit.

Agentforce and automation maintainability also intersect. If an agent invokes a flow, the flow still needs efficient criteria, permissions, fault handling, and monitoring. If an agent suggests next best actions, the underlying actions should be deterministic and bounded. Avoid giving an AI-assisted experience broad record-changing ability when a smaller screen flow, approval process, or guided action would meet the need with clearer auditability.

Study traps include assuming performance is only a developer concern, ignoring recursion because testing one record passed, and fixing every new request by adding another after-save flow. The admin exam perspective is practical: choose efficient flow timing, keep logic bulk-safe, prevent repeated saves, and make the automation understandable. The most impressive automation is often the one future admins can safely modify.