7.1 Automation Tool Selection and Order of Execution

Tool selection starts with the business event

Automation should begin with a precise sentence: when this business event happens, Salesforce should do this outcome, for these records, under these conditions. That sentence tells the admin whether the automation needs a screen, a record save, a schedule, an approval gate, a notification, a routing rule, or a human checklist. If the event is vague, the tool choice will be fragile.

Flow is the main declarative automation platform for modern admins. Screen flows guide users through interactive steps. Record-triggered flows run when records are created, updated, or deleted. Scheduled-triggered flows run at a chosen cadence. Autolaunched flows can be invoked by other automation, buttons, actions, Apex, external calls, or orchestrated processes. Flow is powerful, so the admin must design it like production logic.

Not every request belongs in Flow. A formula field is better when the result is derived and does not need storage. A validation rule is better when the goal is to block a bad save with a clear message. An approval process is better when a record must be locked, routed, approved, rejected, and audited through a formal gate. Assignment and escalation rules are still purpose-built for lead and case operations.

Setup navigation is part of hands-on readiness. Flows are managed from Setup > Process Automation > Flows. Approval processes are configured from Setup > Process Automation > Approval Processes. Validation rules are under Object Manager > Object > Validation Rules. Lead and case assignment rules, case escalation rules, email alerts, and classic workflow actions live in Setup areas tied to their feature families.

Decision table and order awareness

Order of execution is the reason simple automations collide. A record save can trigger system validation, before-save flows, custom validation rules, duplicate rules, after-save flows, assignment rules, auto-response rules, workflow actions, process-style actions in legacy orgs, escalation logic, roll-up calculations, sharing evaluation, and commit behavior. The exact platform sequence is detailed, but admin judgment focuses on what can change values before validation, what can still fail the transaction, and what might cause another save.

Before-save record-triggered flows are usually preferred for same-record field updates because they are fast and avoid an extra database update. After-save flows are used when the flow must create related records, update other records, send notifications, call subflows that need saved IDs, or perform actions that require the record to exist in the database. A common trap is using after-save logic for a same-record update that could be handled before save.

Automation should be designed to be bulk-safe. A flow that works for one opportunity edit can fail when Data Loader updates 10,000 opportunities. Avoid Get Records inside loops when one query can collect data first. Avoid Update Records inside loops when records can be collected and updated once. Consider scheduled paths, async paths, and batch size effects when operations could hit limits.

Scenario judgment and admin controls

Imagine a sales operations manager asks for this: when a high-discount opportunity moves to proposal, require approval, notify the deal desk, create a task for legal if the amount is above a threshold, and prevent the sales rep from closing the deal until approval is complete. This is not one tool. The approval process handles submission, approvers, locking, and final approval or rejection actions. A validation rule or flow entry condition can prevent Closed Won when approval status is not approved.

A record-triggered flow can create the legal task after submission or status change if the requirement is outside the approval action pattern.

A simpler request may not need automation at all. If a manager wants a reminder that renewal opportunities need a next step, a required field on a path stage, a validation rule, or report subscription may be easier to support than a new flow. If the team wants a calculated renewal risk score, a formula may be enough until the score must create work or integrate with another system. Good admins reduce automation when metadata or reporting can solve the need cleanly.

Admin-safe checklist:

• Name automation with object, event, and outcome so future owners can scan it.
• Document entry criteria, fields updated, related objects touched, and expected exceptions.
• Test create, update, bulk update, import, integration user, and permission edge cases.
• Decide how to pause, deactivate, or bypass automation during data repair.
• Monitor failed flow interviews, email deliverability, approval queues, and user feedback after release.
• Keep Agentforce and AI actions behind clear permissions, trusted data grounding, and human review when outcomes affect records.

Agentforce can surface actions, guide support, and help users find next steps, but deterministic record changes still need controlled automation. Do not use an AI agent to make a compliance decision that should be an approval process, a validation rule, or a policy-controlled flow. The admin boundary is to configure access, data grounding, action permissions, testing, monitoring, and fallback paths. If the result must be repeatable and auditable, use a governed automation pattern and let AI assist rather than decide.

Study scenarios often hide the tool behind wording. Look for words such as guide, route, approve, block, calculate, notify, schedule, assign, escalate, and integrate. Then ask whether the action is interactive, synchronous, asynchronous, save-blocking, bulk, cross-object, or approval-based. The best answer is usually the smallest durable tool that satisfies the business control without creating hidden operational debt.