7.6 Automation Performance, Recursion, and Maintainability

Salesforce Admin Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Administrator Orientation and Official Source Control

1.1 Credential Name, Current Outline, and Search Language 1.2 Exam Format, Fee, Score, and Reference Rules 1.3 Trailhead, Trailhead Academy, and Pearson VUE Delivery Workflow 1.4 Domain Weights, Agentforce, and Study Prioritization 1.5 Maintenance Modules, Credential Ethics, and Exam Security 1.6 Developer Edition, Trailhead Playground, and Practice Bank Workflow

2 Chapter 2: Configuration, Setup, User Management, and Org Controls

2.1 Company Information, Fiscal Year, Business Hours, and Locale 2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access 2.3 Login Security, Session Settings, and Identity Basics 2.4 Setup Navigation, Release Readiness, and Change Control 2.5 UI Settings, Home Pages, Apps, and Navigation 2.6 Configuration and Setup Case Lab

3 Chapter 3: Security, Access, Identity, and Sharing Model

3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams 3.2 Profiles, Permission Sets, Permission Set Groups, and Muting 3.3 Field-Level Security, Page Layouts, and Dynamic Forms 3.4 Record Access Troubleshooting and Login-As Workflow 3.5 Identity, Login History, MFA, and Session Risk 3.6 Data Visibility, Reporting, and Analytics Security 3.7 Security and Access Case Lab

4 Chapter 4: Object Manager, Lightning App Builder, and Data Modeling

4.1 Standard Objects, Custom Objects, and Schema Fit 4.2 Fields, Formulas, Rollups, Validation, and Requiredness 4.3 Lookup, Master-Detail, and Junction Relationships 4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages 4.5 Dynamic Forms, Dynamic Actions, and User Experience 4.6 Schema Change Risk, Data Quality, and Deployment Readiness 4.7 Object Modeling Case Lab

5 Chapter 5: Sales, Marketing, Service, and Support Applications

5.1 Lead, Campaign, Account, Contact, and Opportunity Flow 5.2 Sales Processes, Path, Products, Price Books, and Forecasting 5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation 5.4 Knowledge, Entitlements, Service Console, and Support Productivity 5.5 Sales-Service Data Quality and Automation Boundaries 5.6 Application Configuration Troubleshooting 5.7 Sales and Service Applications Case Lab

6 Chapter 6: Data and Analytics Management

6.1 Data Import Wizard, Data Loader, Export, and Backup 6.2 Duplicate Management, Validation, and Data Quality Controls 6.3 Data Transfer, Ownership, Mass Update, and Mass Delete 6.4 Report Types, Filters, Summary Formulas, and Buckets 6.5 Dashboards, Components, Subscriptions, and Sharing Impact 6.6 Analytics Security, Visibility, and Executive Reporting 6.7 Data and Analytics Case Lab

7 Chapter 7: Automation, Flow, Approval, and Operational Processes

7.1 Automation Tool Selection and Order of Execution 7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows 7.3 Approval Processes, Email Alerts, and Notification Patterns 7.4 Validation Rules, Assignment Rules, and Escalation Rules 7.5 Automation Testing, Debugging, and Governance 7.6 Automation Performance, Recursion, and Maintainability 7.7 Automation Case Lab

8 Chapter 8: Productivity, Collaboration, Mobile, and AppExchange

8.1 Activities, Tasks, Events, Calendar, and Email Productivity 8.2 Chatter, Feeds, Groups, Notifications, and Collaboration Governance 8.3 Salesforce Mobile Navigation, Actions, and Page Design 8.4 List Views, Kanban, Path, and User Adoption Tools 8.5 AppExchange Evaluation, Installation, Permissions, and Risk 8.6 Productivity and Collaboration Case Lab

9 Chapter 9: Agentforce for Platform Administrators

9.1 Agentforce Use Cases, Admin Boundaries, and Fit 9.2 Trusted AI, Security, Data Access, and Permission Implications 9.3 Agent Builder, Prompt Builder, and Grounding Concepts 9.4 Testing, Deployment, Monitoring, and Feedback Workflows 9.5 Agentforce Service, Sales, and Internal Productivity Scenarios 9.6 Agentforce Risk, Troubleshooting, and Governance 9.7 Agentforce Case Lab

10 Chapter 10: Integrated Salesforce Admin Scenario Labs

10.1 New Sales Org Setup Integrated Lab 10.2 Service Team Case Management Integrated Lab 10.3 Data Quality and Analytics Integrated Lab 10.4 Security, Access, and Reporting Integrated Lab 10.5 Flow Automation and Change Control Integrated Lab 10.6 Agentforce and Adoption Integrated Lab 10.7 Full Admin Simulation Strategy

11 Chapter 11: Final Review, Maintenance, and Test-Day Strategy

11.1 Final 30-Day Salesforce Admin Review Plan 11.2 Trailhead Playground Hands-On Drill Plan 11.3 105-Minute Exam Timing, Flagging, and Review Workflow 11.4 Test-Day Checklist: Online or Test Center 11.5 Post-Exam Maintenance Modules and Next Certifications 11.6 Salesforce Admin Final Mixed Review

7.6 Automation Performance, Recursion, and Maintainability

Key Takeaways Explain This Topic AI

Performance problems often come from unnecessary interviews, record operations inside loops, broad criteria, and duplicated automation on the same object.

Recursion happens when automation causes additional saves that re-enter the same or related automation without a stopping condition.

Maintainability improves when flows are named, scoped, documented, consolidated thoughtfully, and monitored after release.

Admins should design for limits by reducing queries, batching record updates, using before-save flows when appropriate, and testing bulk scenarios.

Last updated: May 2026

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

Risk What it looks like Prevention

Same-object recursion A flow updates the record or object that triggered it and fires again Use before-save for same-record changes, entry criteria, and prior-value checks.

Cross-object loop Account update changes opportunities, which update the account again Map object interactions and add stopping conditions.

Duplicate automation Multiple flows set the same field or send the same alert Inventory active automation and consolidate where practical.

Broad scheduled work A scheduled flow processes too many records every run Use narrow filters, indexes where supported by design, and operational reports.

Hidden fault volume Failures happen but no one reviews them Assign monitoring ownership and use fault paths or logs.

Unclear ownership Nobody knows why a flow exists Add descriptions, business owner, and release notes.

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.