Home / admin / process-automation-selection

process-automation-selection

Use when deciding which Salesforce automation tool should own a requirement, including before-save and after-save Flow, screen Flow, scheduled Flow, invocable Apex, Apex triggers, and migration off Workflow Rules or Process Builder.

• v1.1.0
• Salesforce Spring '25+
• Updated 2026-09-04
• Scalability
• Reliability
• Operational Excellence

• automation-selection
• flow-vs-apex
• process-builder-migration
• workflow-rule-retirement
• trigger-decision
• decision-record

Open the skill folder on GitHub

Process Automation Selection

Use this skill when the hard question is not how to build the automation, but which automation surface should own it. Salesforce gives teams several ways to automate work, and most production problems start with the wrong boundary choice: using Apex when a before-save Flow was enough, forcing a Flow to behave like a service layer, or leaving legacy Workflow Rules and Process Builder logic in place because it still appears to work.

This skill does not hold the routing logic — the decision trees do. standards/decision-trees/automation-selection.md picks the technology, standards/decision-trees/flow-pattern-selector.md picks which kind of Flow once that tree has said Flow, and standards/decision-trees/async-selection.md picks the async mechanism once it has said Apex. What this skill adds is the worked application for an admin: how to run those trees against one real requirement, write the answer down as a decision record that survives the person who made it, and hand the record to whoever builds it. Cite tree question numbers (automation-selection.md Q3), never paraphrase the branch.

Treat legacy tools as migration targets, not fresh design options. Workflow Rules and Process Builder reached end of support on 31 December 2025; existing rules and processes still execute and can still be activated, deactivated and edited, but they receive no fixes and no enhancements, so build nothing new in them (standards/decision-trees/automation-selection.md, Strategic defaults). UNVERIFIED (2026-09-04): the end-of-support date does not appear in the extracted Summer '26 Metadata API, Apex Developer or Object Reference guides — the tree sources it to Salesforce Help article 001096524, which cannot be fetched from this environment. Do not restate a date beyond that citation.

Before Starting

Gather this context before working on anything in this domain:

• What actually triggers the process: record save, user click, time schedule, event, or external call?
• Does the automation only update the triggering record, or does it coordinate related records, integrations, or user interaction?
• What record volume or transaction pressure exists in real life, not just in demo data?
• Is legacy Workflow Rule, Process Builder, or overlapping trigger logic already attached to the same business process?

Questions to Ask Before Configuring

Ask these before opening Flow Builder or a .trigger file. Each one maps to a tree question and to a gotcha in references/gotchas.md; an agent that skips them produces a defensible-sounding recommendation with no record of what it rejected.

What a proper configuration adds over just picking a tool: the choice is traceable to a numbered tree step, the alternatives carry recorded reasons instead of taste, the object's existing automation was inventoried before anything new was attached, and the record names an owner and a date at which the choice gets re-examined.

Core Concepts

Choose By Execution Model, Not Team Habit

Before-save Flow, after-save Flow, scheduled Flow, screen Flow, and Apex trigger all solve different execution problems. Pick the one whose runtime behavior matches the requirement rather than the one the team is most comfortable editing.

Flow First Does Not Mean Flow For Everything

Flow is the preferred default for declarative, maintainable automation, especially when the logic is readable and the platform already provides the needed behavior. Apex becomes the right choice when strict transaction control, heavier reuse, complex looping, or fine-grained performance control matter more than declarative ownership.

Same-Record Versus Related-Record Work Is A Major Split

Simple updates to the triggering record belong in before-save record-triggered Flow whenever possible. Related-record DML, richer orchestration, or custom service boundaries usually move the decision to after-save Flow, invocable Apex, or triggers.

The Decision Is Positional, Not Just Technological

The save procedure runs before-save record-triggered flows at step 3, all before triggers at step 4, all after triggers at step 8 and after-save record-triggered flows at step 14 (Apex Developer Guide, Triggers and Order of Execution). Choosing a tool therefore chooses a position in that sequence, which is what makes a rule split across Flow and Apex hard to reason about later.

Legacy Automation Must Be Retired Deliberately

Workflow Rules and Process Builder should be treated as migration inventory. Even if they are still present in metadata, they should not remain the design center for new work.

The Output Is A Record, Not An Opinion

The deliverable of this skill is a decision record: requirement, trigger, volume, cross-object answer, timing, chosen mechanism, the tree steps cited, the rejected alternatives with their reasons, an owner and a review date. references/decision-record-examples.md holds the shape, three worked records, the skeleton each choice hands off to, and the inventory queries.

Common Patterns

Before-Save Declarative Update Pattern

When to use: The requirement only changes fields on the record being saved.

How it works: Use before-save record-triggered Flow for field defaulting, normalization, or light calculations.

Why not the alternative: An Apex trigger or after-save Flow adds cost and complexity without real benefit.

After-Save Plus Invocable Pattern

When to use: The process needs related-record work, orchestration, or a small custom Apex boundary.

How it works: Keep orchestration in Flow, but delegate non-trivial business logic to a bulk-safe invocable Apex action when declarative elements would become brittle.

Apex Trigger For High-Control Transaction Logic

When to use: The requirement needs careful ordering, advanced bulk handling, heavy reuse, or behavior that Flow cannot express efficiently.

How it works: Use a trigger handler and service layer, then keep declarative automation off the same boundary unless the split is intentional and documented.

Decision Guidance

Resolve the technology in standards/decision-trees/automation-selection.md, then use this table only to sanity-check that the tree's answer matches the shape of the requirement. The tree wins where they disagree.

Recommended Workflow

1. Inventory the object before adding to it — run the FlowDefinitionView and ApexTrigger queries in references/decision-record-examples.md § One Object, One Order, then run python3 scripts/check_process_automation_selection.py --manifest-dir <retrieved-metadata-dir> to surface Workflow Rule files, flows whose processType is Workflow, and objects carrying both Flow and trigger automation.
2. Answer the Questions table above, writing each answer down verbatim — those seven answers become the top half of the decision record.
3. Walk standards/decision-trees/automation-selection.md from Q1 and note the question number that resolved each branch. If it lands on Flow, continue into flow-pattern-selector.md Q1–Q9; if it lands on Apex with work that cannot finish in the synchronous transaction, continue into async-selection.md Q1–Q8. Do not restate a branch — cite it.
4. Write the record from templates/process-automation-selection-template.md, filling every field including the rejected alternatives and their reasons, then lint it with python3 scripts/check_process_automation_selection.py --decision-record <file.md>.
5. Scaffold from the canonical skeleton the decision names — templates/flow/RecordTriggered_Skeleton.flow-meta.xml for a record-triggered Flow, templates/apex/TriggerHandler.cls for a trigger. Excerpts and the deploy commands are in references/decision-record-examples.md.
6. Hand off and diarise — name the follow-on skill (flow/record-triggered-flow-patterns, apex/trigger-framework, flow/scheduled-flows, apex/batch-apex-patterns), set the record's review_date, and check the outcome against references/gotchas.md before the build starts.

Review Checklist

Run through these before marking work in this area complete:

• [ ] The chosen tool matches the trigger and execution model.
• [ ] Every branch of the choice cites a tree question number that a reader can look up.
• [ ] Each rejected alternative has a recorded reason, not just a strikethrough.
• [ ] The object's existing automation was inventoried before anything new was proposed.
• [ ] Same-record work was not pushed into heavier automation by habit.
• [ ] Flow and Apex boundaries are separated intentionally where both exist.
• [ ] Legacy Workflow Rule and Process Builder logic is treated as migration scope.
• [ ] Transaction budget was estimated across the whole save, not per automation.
• [ ] The record names an owner and a review date.
• [ ] check_process_automation_selection.py --decision-record passes on the finished record.

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Tool choice is also a position choice — the save procedure fixes where each surface runs, so splitting one rule across Flow and Apex splits it across steps 3, 4, 8 and 14.
2. A workflow field update re-runs update triggers, and only update triggers — flows, validation rules, duplicate rules and Process Builder processes do not get a second pass.
3. A recursive save skips a block of the sequence — automation that re-enters the save procedure loses steps 9 through 17.
4. The transaction has one budget, not one per automation — a Flow and a trigger on the same save draw from the same SOQL, DML and CPU allowances.
5. Retrieved Process Builder metadata is read-only in practice — editing and redeploying it makes the process unopenable in the target org.
6. A Flow that works at low volume may still belong in Apex at higher scale — tool choice is partly a transaction design decision.

Full treatment, with the guide line ranges each rests on, in references/gotchas.md.

Output Artifacts

Reference Files

Related Skills

• admin/flow-for-admins - use when Flow is already the chosen boundary and the design needs to be built or reviewed.
• apex/trigger-framework - use when the requirement clearly belongs in Apex trigger architecture.
• flow/record-triggered-flow-patterns - use when the main remaining decision is before-save versus after-save Flow structure.
• admin/approval-processes - use when the requirement is a human approval chain rather than an automation boundary.
• admin/assignment-rules - use when the requirement is ownership routing on create; its references/routing-selector.md is the sibling selector for rules vs Omni-Channel vs Flow vs Apex.
• admin/workflow-field-update-patterns - use when the question narrows to which surface stamps a field on save and whether it recurses.
• flow/process-builder-to-flow-migration - use when the decision is made and the legacy process now has to be converted.
• flow/scheduled-flows - use when the decision landed on a schedule-triggered Flow.
• apex/batch-apex-patterns - use when the decision landed above the scheduled-Flow volume line.

Package files

• references/decision-record-examples.md
• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/well-architected.md
• templates/process-automation-selection-template.md
• scripts/check_process_automation_selection.py