5.1 Record-Triggered Flows & Declarative Automation

5.1 Record-Triggered Flows & Declarative Automation

Quick Answer: On Platform Developer I, Salesforce Flow is the primary declarative automation engine. Use before-save record-triggered flows (Fast Field Updates) for efficient updates to the triggering record, after-save flows (Actions and Related Records) for related DML and side effects, and choose screen, scheduled, or autolaunched flows when the work is user-guided, time-based, or invoked on demand. Prefer Flow over new Workflow Rules or Process Builder, and design entry criteria and bulk patterns so interviews stay inside governor limits.

Process Automation and Logic is the heaviest domain on the current Platform Developer blueprint. The exam expects you to configure Flow correctly, place it in the order of execution relative to Apex, and know when declarative automation is enough—and when it is not.

Why Flow Is the Preferred Declarative Tool

Salesforce has made Flow the long-term replacement path for Workflow Rules and Process Builder. Those older tools still appear in legacy orgs and migration stories, but for new automation the platform guidance and exam “best solution” answers converge on Flow when the requirement is declarative.

Reasons Flow wins for new work:

On scenario questions that say “admin maintainable,” “no code required,” or “update fields when a record is saved,” start with record-triggered Flow unless a stated constraint forces Apex (bulk recursion control, complex callouts, packageable algorithms, and similar cases covered in 5.3).

Flow Types You Must Recognize

Record-triggered flows

Fire automatically when a record is created, updated, created or updated, or (when configured) deleted, on a chosen object. You set entry conditions so the interview runs only when those criteria are true—critical for performance and for avoiding re-entrancy when your own updates would otherwise re-fire the flow.

Two save paths matter on the exam:

1. Fast Field Updates (before-save)

   • Runs before the record is committed and before before Apex triggers in the standard order of execution.
   • May update only fields on the triggering record.
   • Cannot create related records, send emails, post to Chatter, or perform other after-save actions.
   • Extremely efficient: no extra DML for same-record field stamps compared with after-save patterns that update the same record again.

2. Actions and Related Records (after-save)

   • Runs after the record is saved (still inside the broader transaction sequence, after after-triggers and after legacy workflow/process steps in the documented order).
   • Can create/update related records, invoke subflows, call invocable Apex, send emails, submit for approval, and use many action elements.
   • Use when the business outcome needs side effects beyond stamping the triggering record.

Exam tip: If the requirement is “set a field on the Opportunity when Stage changes” and nothing else is needed, before-save Flow is usually better than after-save Flow or a before trigger. If the requirement is “create a Task on the related Account and email the owner,” you need after-save (or Apex).

Scheduled (schedule-triggered) flows

Run on a time schedule against a set of records matching conditions (for example, nightly process open Cases older than 30 days). Think batch-style declarative work without writing a schedulable Apex class—within Flow’s limits and design constraints.

Screen flows

Interactive flows with screens, inputs, choices, and navigation. Ideal for guided data capture, multi-step wizards, and service or sales scripts launched from buttons, Lightning pages, utility bars, or Experience Cloud. Screen flows are the declarative answer when users must participate in the process, not when a silent backend save must complete alone.

Autolaunched flows

No screens and no record trigger of their own. They are started by other automation, Apex (Flow.Interview), REST, platform events (related patterns), subflow calls, or buttons that launch without UI. Autolaunched flows package reusable server-side logic that admins can maintain while developers invoke it from code or from other flows.

(You may also see platform-event-triggered and other specialized start types in the product; for PDI, master the four patterns above and map the scenario’s start and user interaction first.)

Entry Conditions and Optimization

Entry conditions are not cosmetic. Poorly filtered record-triggered flows run on every save, burn CPU and element limits, and can cascade when they update records that re-enter automation.

Design habits:

• Restrict object, triggering event (create vs update), and condition logic to the smallest true set of business cases.
• Prefer conditions that exclude “no meaningful field change” when the platform options support that pattern for your scenario.
• Avoid entry criteria so broad that every bulk Data Loader update fires heavy after-save work.
• When an after-save flow updates related records, anticipate order of execution and additional automations on those related objects.

Order of Execution: Flow vs Apex (Exam-Critical)

You do not need every numbered step of Salesforce’s long order-of-execution list memorized, but you must place Flow correctly relative to Apex:

1. Early system validation runs.
2. Before-save record-triggered flows run.
3. Before Apex triggers run.
4. Custom validation rules (and further validation) run—so a before-save flow that sets an invalid value can still fail validation.
5. Record is saved (not yet fully committed in the mental model of later steps).
6. After Apex triggers run.
7. Assignment rules, auto-response rules, and legacy workflow/process steps may run as documented.
8. After-save record-triggered flows run.
9. Later steps include roll-ups, sharing recalculation, commit, and post-commit work (emails, async paths, and so on).

Implications:

• Before-save Flow can prepare field values that before triggers and validation rules will see.
• After-save Flow runs after after-triggers, so trigger-based logic has already executed for that save path.
• Updating the same record again from after-save automation can re-enter parts of the save order—prefer before-save for pure same-record stamps to avoid extra recursion risk and extra DML.

Governor Considerations for Flow

Flow interviews participate in the same multi-tenant governor model as Apex for many limits (SOQL, DML rows, CPU time, and related transaction caps). Bulk API or mass UI edits can run one interview per record in a bulkified transaction context, but careless designs still fail:

• Get Records / Update Records inside loops without collection patterns can explode SOQL/DML usage.
• Unbounded related-record queries without filters risk row limits.
• Deep chains of subflows, process-builder leftovers, and triggers on the same save can stack element and CPU consumption.
• Asynchronous paths and scheduled flows have their own limit envelopes—do not assume unlimited batch size.

Developer-minded Flow design: think in collections, minimize queries, put work in entry conditions, prefer before-save for same-record updates, and escalate to Apex when the algorithm needs fine-grained bulk maps, recursion guards, or complex error handling (section 5.3).

Debugging and Delivery Habits

Use Flow Builder debug, fault paths, and descriptive element names. Prefer one well-structured flow (or a parent plus clear subflows) over dozens of overlapping Process Builder processes. Document entry criteria so admins know when automation fires. In packaged or multi-team orgs, coordinate Flow and Apex so both layers do not implement the same rule twice.

Putting It Together for Scenario Stems

Master these types, save paths, entry filters, order-of-execution placement, and governors, and you cover the declarative automation core of Process Automation and Logic before you write a single trigger.