The mental model: event, criteria, and action
A Flow question can almost always be organized with three questions: what event starts the process, what criteria decide whether it should continue, and what action must run. If the event is that a record is created, updated, or deleted, you are close to a record-triggered flow. If the event is a date or recurring schedule, check schedule-triggered flow. If the event is that a user needs to move through screens, think about screen flow.
Then look at the action type. Updating the same record is not the same as creating related records, sending a notification, calling an action, waiting several days, or asking the user for data. The exam often gives options that all exist, but only one respects the correct timing and maintenance model. That is why Flow is better studied as declarative architecture, not as a list of buttons.
Practical rule: first identify when the process happens; then decide whether the action touches the same record, related records, the user, or a future date.
Flow types you should recognize
Screen flow guides a user through screens. It is a candidate when the question says someone must capture information, confirm decisions, follow a wizard, or run a process from a button or action. If the process requires human interaction across several steps, screen flow is usually more appropriate than silent automation.
Record-triggered flow runs automatically when a record changes. It is one of the most important types for Administrator because it solves business rules around data: updating fields, creating tasks, keeping data consistent, or firing actions when an opportunity, case, account, or contact meets criteria. Platform event-triggered flow responds to platform events. Schedule-triggered flow runs on a defined schedule and frequency to process records without depending on an immediate change.
Autolaunched flow without a screen is reusable logic that can be invoked by other processes, buttons, Apex, or subflows. In exam questions, it appears when the scenario wants to encapsulate repeatable steps without UI. The key is to distinguish whether the flow should be started by a user, a data change, a schedule, or an external automation piece.
Record-triggered flows
A record-triggered flow is configured for an object and a moment: when the record is created, updated, created or updated, or deleted. You also define entry conditions. This matters because a flow that runs on every update unnecessarily can affect performance and cause side effects. If the question mentions that it should run only when a record starts meeting criteria, look for that option.
Common Administrator scenarios include creating a task when an opportunity changes to Closed Won, copying data from an account to a contact, updating a business field, notifying a user, or creating a related record. The exam does not expect you to code, but it does expect you to understand that Flow Builder can automate declarative processes with clear conditions and testing before activation.
Before-save vs after-save
Before-save, also called fast field updates, is ideal when you only need to update fields on the same record that triggered the flow before it is saved. It is fast and avoids unnecessary work. If the scenario says "when a contact is created without a phone, copy the related account phone to that same contact", before-save can be a candidate if only the triggering record is updated.
After-save is used when you need to do something after the record has been saved: create or update related records, send actions, publish events, or run steps that depend on the record ID. If the question mentions creating a task, creating a contract, updating child records, or sending a notification after a change, after-save is usually more appropriate.
The common trap is choosing before-save because it sounds more efficient even though the flow needs to touch other records. Efficiency matters, but it cannot break the requirement. First satisfy the action type; then optimize. For multiple-choice questions, separate "update the same record" from "create or modify related records" carefully.
Scheduled paths and schedule-triggered flows
A scheduled path belongs to a record-triggered flow. The record change starts the flow, but one branch runs after or before a related date. For example, creating a task five days after an opportunity is won, or sending a reminder one month before a renewal date. The record changed first; the action is delayed.
A schedule-triggered flow does not depend on a record changing at that moment. It runs according to a frequency and can find records that meet criteria. It is better for recurring processes: reviewing overdue accounts each night, updating statuses daily, or processing records that need periodic maintenance. If the question says nightly, daily, weekly, recurring, or at a specific time, think schedule-triggered.
The exam distinction is simple: scheduled path is a future consequence of a record change; schedule-triggered flow is a scheduled job that checks records on its own.
Subflows, order, and maintenance
Subflows let you reuse logic. If several flows need the same steps, such as calculating priority, validating a condition, or creating a set of tasks, it is better to encapsulate that logic. This reduces duplication and makes changes easier to maintain. On the exam, subflow usually appears when the scenario mentions reuse, consistency, or avoiding the same logic in several places.
Flow Trigger Explorer helps you understand and order record-triggered flows for an object. This matters when multiple automations can run on the same record. Many Administrator questions do not go deeply into this, but you should recognize that too many unordered flows make errors hard to diagnose.
Testing is also important. Flow includes debug tools, and changes should be validated in a sandbox or test environment when they affect real data. Poorly tested automation can update incorrect records very quickly. Good exam judgment combines declarative ease with control, testing, and maintainability.
Common mistakes when studying Flow
The first mistake is thinking Flow always replaces everything. Flow is powerful, but if the question asks for formal approval, it may be approval process. If it asks for highly complex logic, specialized integration, or advanced transactions, Apex may appear. If it asks to guide a user through screens, do not choose record-triggered just because it "automates".
The second mistake is ignoring execution timing. Many wrong answers fail because they run too early, too late, or too often. Before choosing, underline words such as before save, after save, related records, scheduled, recurring, user input, and only when updated to meet conditions.
The third mistake is not thinking about maintenance. An answer that creates five duplicated flows may work, but may not be the best answer. An answer that uses subflows, clear entry conditions, and a small scope is usually more defensible. Salesforce Administrator rewards declarative, native, maintainable solutions.
Quick decision checklist:
- Does the process start from a user, record change, schedule, or event?
- Does the action update the same record or related records?
- Should it happen immediately, on a future date, or recurringly?
- Does it need screens and user input?
- Does the solution avoid duplication and allow safe testing?
Frequently asked questions
Does Flow replace Workflow Rules and Process Builder?
For Administrator study, think of Flow as the primary declarative tool for new automation. Workflow Rules and Process Builder are legacy technologies in many orgs, but the modern exam rewards recognizing Flow Builder as the current flexible option for declarative automation. Still, a question may mention an existing org with older automation; in that case, read whether it asks about maintenance, migration, or a new solution.
When should I choose screen flow instead of record-triggered flow?
Choose screen flow when the user must interact with screens, enter data, confirm steps, or follow a guided assistant. Choose record-triggered flow when the process should run automatically because data changed. If the question talks about guiding a support agent through information capture, screen flow is a candidate. If it talks about updating data when a case is saved, record-triggered flow is a candidate.
Why not always use after-save?
After-save is necessary for actions and related records, but it is not always the most efficient option. If you only need to change fields on the same record before it is saved, before-save is usually better. In exam questions, do not choose after-save by habit: confirm whether the flow needs the record ID, related records, or post-save actions.
Official resources and practice
To study Flow, combine theory with small scenarios. Create one flow that updates the same record, another that creates a related task, and another that uses a scheduled path. Then practice questions by asking about timing, affected record, and maintenance. If you miss a question, write whether you confused flow type, entry criteria, before-save, after-save, or schedule.
- Trailhead: Get Started with Flow Builder
- Trailhead: Record-Triggered Flows
- Trailhead: Add a Scheduled Task to Your Flow
- Complete Salesforce Platform Administrator guide
- Practice Platform Administrator questions
BlueForce is not affiliated with Salesforce. This guide is original editorial content based on study experience, public objectives, and official resources.