Overview
Salesforce Flow is the declarative automation engine inside Salesforce, and in a hyperautomation solution it usually starts or finishes the process: a record change triggers work, a screen guides a user, or a scheduled job sweeps records. This section covers five objectives. You build the right flow for a scenario, choosing between screen flows, record-triggered flows (before-save and after-save), schedule-triggered flows, platform event-triggered flows and autolaunched flows.
You work with Einstein Bots, which can call autolaunched flows to look up and update data during a customer conversation. You create Flow tests for record-triggered flows with assertions on the results. You connect flows to other APIs through External Services, which turns an OpenAPI specification into invocable actions, or through HTTP callout actions, using named credentials for authentication. Finally, you know the Flow basics that matter for hyperautomation, such as transactions, governor limits, asynchronous paths and fault paths.
How it's tested
Flow questions present a Salesforce event or user interaction and ask which flow type, element or connection pattern to use, or how to test it. The best answer uses the lightest flow type that meets the requirement, keeps callouts out of synchronous save contexts, and authenticates external calls through named credentials.
-
Which flow type
A requirement mentions a record change, a schedule, a user screen or an event, and you choose the flow type and trigger settings.
-
Call the outside world
A flow must reach an external API or Composer, and you choose External Services, an HTTP callout action or an asynchronous path.
-
Prove it works
A record-triggered flow must be verified before deployment, and you choose a Flow test with the right initial record and assertions.
When a case is closed, a flow must send case details to an external survey API. A before-save flow cannot make callouts and only updates the triggering record, so it is ruled out. An after-save record-triggered flow with a run asynchronously path can call an External Services action registered from the survey API's OpenAPI specification, authenticated by a named credential, without holding up the user's save.
Objectives 5
Official objectives from the Salesforce outline, in outline order.
4.1 Given a hyperautomation scenario, build the appropriate flow using Salesforce Flow.Choosing flow types and triggers for each part of a process.
- What it means
- Flow types map to triggers: screen flows guide users, record-triggered flows run when records are created, updated or deleted, schedule-triggered flows process batches of records at set times, platform event-triggered flows react to events, and autolaunched flows run when called by other automation, Apex, APIs or bots.
- What to understand
- Before-save record-triggered flows are fastest for updating fields on the triggering record but cannot perform other actions. After-save flows can update related records, send notifications and, through asynchronous paths, make callouts. Platform events decouple Salesforce from external systems, so Mule applications or other tools can publish or subscribe to them.
- How it shows up
- A process step happens on a record change, schedule or event, and you choose the flow type and trigger options.
- Common confusion
- Before-save flows only change fields on the triggering record; anything else needs an after-save flow.
4.2 Work with Einstein Bots to automate customer service.Bot dialogs that call flows to act on Salesforce data.
- What it means
- Einstein Bots handle customer conversations in channels such as chat and messaging. Dialogs collect information from the customer and can invoke autolaunched flows (and Apex) as actions to look up order status, create cases or update records, then return results to the conversation or transfer to an agent.
- What to understand
- Bot actions call autolaunched flows with input and output variables, so the flow must be designed for that contract. Bots should hand off to a human agent when they cannot resolve a request. Salesforce now positions Agentforce Service Agent as the AI successor for service conversations, but the exam objective names Einstein Bots.
- How it shows up
- A bot must check an order status in Salesforce or an external system, and you choose an autolaunched flow invoked as a bot action.
- Common confusion
- Bots call autolaunched flows, not screen flows; the conversation itself replaces the screen.
4.3 Create tests for record-triggered flows with Flow Testing.Flow tests with initial records, triggers and assertions.
- What it means
- Flow Builder lets you create tests for record-triggered flows. A test defines the triggering record and its values (and, for updates, the changed values), which path to run, and assertions that check the expected outcome, such as a field value after the flow runs.
- What to understand
- Tests run the flow against the defined record without needing manual data entry, so they can be rerun after every change. Create tests for each decision outcome and for boundary values. Flow tests complement end-to-end testing; they do not prove external systems responded correctly.
- How it shows up
- A developer must verify that a record-triggered flow sets a field correctly under several conditions, and you choose Flow tests with assertions.
- Common confusion
- Flow Testing as described in this objective applies to record-triggered flows; screen flows are checked with debug runs instead.
4.4 Given a scenario, connect Salesforce flows with other APIs.External Services, HTTP callout actions and named credentials.
- What it means
- External Services registers an API from an OpenAPI specification and exposes its operations as invocable actions in Flow. HTTP callout actions let a flow call a REST endpoint by configuring the request and generating the data structure from a sample response. Both use named credentials and external credentials to store the endpoint and authentication.
- What to understand
- Callouts are not allowed in before-save flows and must run where the transaction allows them, such as screen flows, autolaunched flows, scheduled flows or the asynchronous path of an after-save record-triggered flow. Specifications published in Anypoint Exchange can be registered as External Services, which ties Flow to the API-led layer.
- How it shows up
- A flow must call a MuleSoft API described in Exchange, and you choose External Services with a named credential.
- Common confusion
- A named credential stores endpoint and authentication; it does not itself create Flow actions.
4.5 Identify the basics of Salesforce flows that are applicable to hyperautomation implementation.Transactions, limits, fault paths and invocation for multi-tool processes.
- What it means
- Flows run within Salesforce transactions and governor limits, can be called from other flows as subflows, from Apex, from the REST API, from bots and from orchestrations, and can publish platform events that external tools consume.
- What to understand
- Bulkify flows by avoiding data operations inside loops, add fault paths to elements that can fail, and use asynchronous paths or platform events for work that should not delay the user. Autolaunched flows are the reusable building blocks that Flow Orchestration, bots and integrations call.
- How it shows up
- A flow hits limits or must be reused by several tools, and you choose subflows, autolaunched flows or bulk-safe design.
- Common confusion
- Placing Get or Update Records elements inside a loop risks governor limits when many records arrive together.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Before-save vs. after-save
Before-save record-triggered flows update the triggering record's fields; after-save flows can do anything else.
- Remember
- Callouts, related-record updates and notifications need after-save.
- Tested as
- Most flow type questions.
- Trap
- Choosing before-save for a callout.
-
Run asynchronously path
An after-save path that runs after the transaction commits, allowing callouts.
- Remember
- Use it to call external APIs from record changes.
- Tested as
- Integration from record events.
- Trap
- Making callouts in the immediate path.
-
External Services
Registers an OpenAPI specification and exposes operations as invocable Flow actions.
- Remember
- Requires a named credential and a valid spec.
- Tested as
- Connecting Flow to MuleSoft or other APIs.
- Trap
- Confusing it with a named credential.
-
HTTP callout action
Flow action that calls a REST endpoint configured in Flow Builder using a sample response.
- Remember
- Useful when no OpenAPI spec exists.
- Tested as
- Quick API connections.
- Trap
- Assuming a spec is always required.
-
Named and external credentials
Store endpoint URLs and authentication for callouts.
- Remember
- Never hardcode tokens in flow variables.
- Tested as
- Secure integration answers.
- Trap
- Storing a password in a custom setting read by the flow.
-
Flow tests
Saved tests with a triggering record and assertions for record-triggered flows.
- Remember
- Rerun after every change to catch regressions.
- Tested as
- Testing objective.
- Trap
- Relying only on manual debug runs.
-
Einstein Bots actions
Bot dialogs call autolaunched flows or Apex with inputs and outputs.
- Remember
- Design the flow's variables as available for input and output.
- Tested as
- Customer service scenarios.
- Trap
- Pointing a bot at a screen flow.
-
Platform events
Event messages that flows can publish or subscribe to, consumable by external systems.
- Remember
- Decouple Salesforce from integration timing.
- Tested as
- Event-driven hand-offs to MuleSoft.
- Trap
- Polling external systems instead.
-
Fault path
Connector for handling element failures.
- Remember
- Log, notify or route to a person on failure.
- Tested as
- Reliability questions.
- Trap
- Letting callouts fail without handling.
-
Bulkification
Designing flows to handle many records in one transaction without hitting limits.
- Remember
- Keep data operations outside loops.
- Tested as
- Data load and integration scenarios.
- Trap
- Updates inside a loop.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Flow types for hyperautomation
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Screen flow | Guided user interaction | A person drives it | Using it for unattended work |
| Record-triggered flow | Runs on create, update or delete | Before-save or after-save contexts | Callouts in before-save |
| Schedule-triggered flow | Runs at set times over a batch | Time-driven sweeps | Using it where an event exists |
| Platform event-triggered flow | Runs when an event is received | Decoupled from the publisher | Expecting a synchronous reply |
| Autolaunched flow | Called by other automation, bots or APIs | Reusable building block | Duplicating its logic elsewhere |
External Services vs. HTTP callout action
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| External Services | Actions generated from an OpenAPI spec | Spec-driven, many operations at once | Expecting it without a spec |
| HTTP callout action | Single REST call configured in Flow Builder | Built from a sample response | Using it for a large, documented API |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Callout from before-save
- What candidates pick
- Use a before-save flow to call the API and set a field from the response.
- Why it looks right
- Before-save is the fastest flow type.
- Why it's wrong
- Before-save flows cannot make callouts or perform actions beyond updating the triggering record.
Clue to watch for The flow must reach an external system.
-
Screen flow for the bot
- What candidates pick
- Have the Einstein Bot launch a screen flow to collect order details.
- Why it looks right
- Screen flows collect user input.
- Why it's wrong
- Bots collect input in dialogs and call autolaunched flows as actions.
Clue to watch for The interaction happens in a chat or messaging channel.
-
Credential in a variable
- What candidates pick
- Store the API key in a constant and add it to the request header.
- Why it looks right
- It works immediately.
- Why it's wrong
- It exposes secrets in metadata; named and external credentials manage authentication securely.
Clue to watch for The question mentions security or credential rotation.
-
Debug equals test
- What candidates pick
- Debug the flow once in Flow Builder before deployment.
- Why it looks right
- Debug shows each element running.
- Why it's wrong
- A one-off debug run is not repeatable; Flow tests with assertions catch regressions after each change.
Clue to watch for The requirement is repeatable verification of a record-triggered flow.
-
Scheduled sweep for real-time needs
- What candidates pick
- Run a nightly scheduled flow to send new cases to the API.
- Why it looks right
- Batch processing is simple.
- Why it's wrong
- The requirement is near real time; an after-save asynchronous path or platform event fits better.
Clue to watch for The scenario says as soon as the record changes.
Answer framework
Work out the Flow answer from trigger to outcome before comparing options.
- Identify what starts the work: a user, a record change, a schedule, a platform event, a bot or another automation such as Composer or an orchestration.
- For record changes, use before-save only for same-record field updates and after-save for related records, callouts or emails.
- For external APIs, pick External Services when an OpenAPI spec exists or an HTTP callout action when it does not, both with named credentials.
- Place callouts where they are allowed, such as an asynchronous path, and add fault paths to every element that can fail.
- Verify record-triggered flows with Flow tests and assertions, then check bulk safety for high-volume triggers by keeping queries and DML out of loops.
Practice question
Want more like this? The Mule-Dev-202 practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Use a free Developer Edition org and build rather than read. Create one record-triggered flow in each context, before-save and after-save, then add a run asynchronously path that calls a public test API through an HTTP callout action. Next, register an External Service from a small OpenAPI specification with a named credential, and call one of its actions from an autolaunched flow.
High-priority topics are before-save versus after-save, callout placement, External Services and Flow tests. Underestimated areas are bot actions calling autolaunched flows and the input and output variable settings they require, and bulk safety when integrations load many records at once.
Create Flow tests for your record-triggered flow covering each decision outcome, and break the flow deliberately to see the tests fail. In practice questions, find the trigger first, then check whether a callout is involved, because that single detail removes most wrong options. If you already know Flow well, spend your time on the integration features rather than basic elements.
FAQ
How much of the Mule-Dev-202 exam is Use Salesforce Flow to build hyperautomation workflows?
This Flow section is 13% of the exam, about eight of 60 questions as an editorial estimate. Flow also features in tool-selection questions in the best-practices section.
Are Einstein Bots still relevant given Agentforce?
The exam objective names Einstein Bots, so learn how bot dialogs call autolaunched flows. Salesforce now steers new service automation toward Agentforce, which reuses flows as actions in a similar way.
Can a record-triggered flow call an external API?
Yes, from an after-save flow using a run asynchronously path, which runs after the record is committed. Before-save flows and the immediate path cannot make callouts.
What is the difference between External Services and a named credential?
A named credential stores the endpoint and authentication. External Services uses an OpenAPI specification and that credential to generate invocable Flow actions.
Which flows can Flow Testing cover?
The objective focuses on record-triggered flows, where a test defines the triggering record and assertions on the outcome.
How long should I study this section?
Plan around 8 to 10 hours as an editorial estimate, less if you already build record-triggered flows regularly.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- HubSpot Inbound Marketing Certification Study guide
- Salesforce Certified Platform Developer I Study guide
- Google Ads Search Certification Study guide
- ServiceNow Certified System Administrator Study guide
- Salesforce Certified Platform Administrator Study guide
- ServiceNow Certified Application Developer Study guide
Test your Domain 4 knowledge
You have covered flow types, Einstein Bots, Flow tests, External Services and callout placement. Check whether you can pick the right flow design in timed scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Mule-Dev-202 AI tutor Get any concept explained your way