Mule-Dev-202 · Domain 1 of 8

Mule-Dev-202 Domain 1: Employ best practices when using hyperautomation

The heaviest section asks you to pick the right tool among Salesforce Flow, Composer, MuleSoft RPA and Anypoint Platform, wire them together, test the whole chain and handle failures. Note that this credential is retiring.

Exam weight estimate
20%
Official objectives estimate
6
Estimated questions estimate
~12
Suggested study time estimate
12–15 hrs

About 17 min read Reviewed October 2026

Overview

This section is the glue of the exam. It tests whether you can look at a business process and assign each piece to the right tool: Salesforce Flow and Flow Orchestration for logic and people inside Salesforce, MuleSoft Composer for clicks-not-code integration between Salesforce and other SaaS apps, MuleSoft RPA for systems that only offer a user interface, and Anypoint Platform for governed, reusable APIs. It then covers how those tools call each other, how to build test data for a chain that spans several systems, how each tool reports and recovers from errors, when to reuse an existing asset, and how quickly each tool lets a team deliver.

Status: Salesforce is retiring this credential. The last day to take the Mule-Dev-202 exam was 31 August 2026 and the certification retires on 1 February 2027, with no named successor. Holders keep a valid credential until then, and the skills on this page still apply to live MuleSoft and Salesforce projects.

How it's tested

Expect short business scenarios that mix systems with and without APIs, human approvals, document handling and data volumes. Each answer names one tool or one integration pattern. The best answer uses the simplest tool that meets the stated constraints, prefers an API over screen automation, and keeps error handling and reuse in mind.

  • Which tool fits this step

    A process step is described with its system, interface and volume, and you choose Flow, Composer, RPA, Anypoint or Flow Orchestration.

  • How do the tools talk

    Two tools must exchange data or trigger each other, and you pick the supported connection such as an invocable Composer flow, External Services or the RPA connector.

  • Something fails mid-chain

    A step breaks in production and you decide where the failure is caught, logged, retried or routed to a person.

Reasoning it through

A finance team re-keys invoice totals from a vendor portal that has no API into Salesforce, then a manager approves large amounts. The portal step has only a user interface, so it belongs to a MuleSoft RPA bot. Writing the data into Salesforce and routing the approval are native platform work, so a record-triggered flow or Flow Orchestration handles them. Anypoint Platform would add cost and build time without solving the missing API.

Objectives 6

Official objectives from the Salesforce outline, in outline order.

1.1 Given a scenario, identify the correct tools to use.Matching each process step to Flow, Composer, RPA, Anypoint or Orchestrator.
What it means
Each hyperautomation tool has a home ground. Salesforce Flow automates logic on Salesforce data, Flow Orchestration coordinates multi-user, multi-stage work, Composer connects Salesforce with SaaS apps through prebuilt connectors without code, MuleSoft RPA drives desktop and web interfaces that lack APIs, and Anypoint Platform builds and governs reusable APIs and complex integrations.
What to understand
Selection rests on a few signals: where the data lives, whether the target system has an API, how complex the transformation and error handling must be, expected volume, who builds and maintains the solution, and whether people must act between steps. RPA is the fallback for interface-only systems, not the default for every legacy app. Anypoint is chosen when reuse, governance, security policies or high volume justify a pro-code build.
How it shows up
A scenario lists several systems and constraints, and you choose the tool for one step or the combination for the whole process.
Common confusion
Composer and Anypoint both integrate systems, but Composer is a no-code tool for admins with fixed connectors, while Anypoint is a developer platform for governed, reusable APIs.
1.2 Model suitable tests and create data to test an end-to-end hyperautomation solution.Planning test cases and data that exercise every tool in the chain.
What it means
An end-to-end test follows one business transaction from the trigger through every tool to the final result, such as a case created in Salesforce, enriched by a Composer flow, completed by an RPA bot in a legacy app and closed by an orchestration step.
What to understand
Test data must exist consistently in every connected system, ideally sandboxes or test tenants, with records designed for the happy path, boundary values and each error branch. Each tool also has its own unit test option: Flow tests for record-triggered flows, Composer test runs, the RPA Manager test phase and the Exchange mocking service for APIs not yet built. Unit tests do not prove that the hand-offs between tools work.
How it shows up
Questions ask which data or environment setup lets a cross-system test run safely without touching production records.
Common confusion
Passing each tool's own test is not an end-to-end test; the integration points need their own cases.
1.3 Implement key common design patterns for communicating between Salesforce, Anypoint, Composer, and RPA.The supported ways each tool triggers or calls another.
What it means
The tools connect through a small set of patterns: Salesforce Flow calling external APIs through External Services or HTTP callout actions, Flow invoking a Composer flow, Composer and Mule applications starting RPA processes through their RPA connectors, Salesforce events such as record changes triggering Composer flows, and Mule applications publishing or consuming Salesforce data through the Salesforce connector.
What to understand
Prefer event-driven or API-based hand-offs over polling and screen automation. Know which direction each pattern runs, what credentials it needs (named credentials in Salesforce, connections in Composer, connected apps or credentials for Anypoint and RPA), and whether the call is synchronous or long-running. RPA processes run asynchronously, so callers should not wait on a bot inside a short transaction.
How it shows up
You pick the native connection between two named tools, or spot a pattern that would block a transaction or bypass governance.
Common confusion
External Services registers an OpenAPI description as Flow actions; it is not the same as calling a Composer flow, which uses Composer's own invocation.
1.4 Employ typical fault handling approaches for each tool.How Flow, Composer, RPA and Mule applications catch and report errors.
What it means
Each tool handles errors differently. Salesforce Flow uses fault paths on elements that can fail, Composer records failed runs in flow history and lets you guard steps with If/Else checks, MuleSoft RPA workflows use exception handling inside the bot and surface failed runs in RPA Manager monitoring, and Mule applications use error handlers such as On Error Continue and On Error Propagate.
What to understand
Good designs decide in advance whether an error should stop the process, retry, or be routed to a person. Log enough context to trace a transaction across tools, notify an owner, and avoid silent failures. In Flow, an element without a fault path rolls back the transaction and sends an unhandled fault email. In Mule, On Error Continue returns a success response to the caller while On Error Propagate rethrows the error.
How it shows up
A step fails and you choose the tool-appropriate handling, such as a fault connector creating a task or a bot exception routed for review.
Common confusion
On Error Continue does not retry anything; it swallows the error and lets the flow complete with a handled result.
1.5 Identify scenarios and techniques for reuse.Building once and sharing APIs, flows, subflows and bot steps.
What it means
Reuse appears at every layer: API specifications, fragments, connectors and templates published to Anypoint Exchange; system APIs that many process APIs call; subflows and invocable autolaunched flows in Salesforce; and reusable RPA workflow components shared across bot processes.
What to understand
Reuse pays off when several consumers need the same data or action, when governance requires one controlled access path to a system, or when the same logic would otherwise be copied into several flows. Exchange search should happen before any new build. Over-engineering a reusable API for a one-off, single-consumer integration slows delivery without benefit.
How it shows up
A second team needs the same customer lookup, and you choose to discover and consume the existing asset rather than build a copy.
Common confusion
Copying a working flow or bot into another project is duplication, not reuse; changes then have to be made twice.
1.6 Identify velocity of development based on hyperautomation tools and use case complexity.Estimating how fast each tool delivers for a given complexity.
What it means
Velocity compares how quickly a solution can be built and changed. Clicks-based tools such as Flow and Composer deliver simple use cases fastest, RPA needs recording, building and testing against a live interface, and Anypoint applications involve design, coding, testing and deployment by integration developers.
What to understand
Speed depends on complexity as much as tool. Composer is quickest for straightforward record sync between supported apps, but complex transformations, high volume or custom security can push the same requirement to Anypoint. RPA is quick to start but brittle when the target interface changes, which adds maintenance time. The exam expects you to balance time to value with long-term maintainability.
How it shows up
A team needs a working integration this week with no developers available, and you choose the tool that meets that timeline.
Common confusion
Fastest to build is not always fastest overall; an RPA bot built quickly against an unstable screen can cost more time later than an API.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Hyperautomation

    Combining integration, RPA, workflow, AI and human steps to automate a whole business process rather than single tasks.

    Remember
    In this exam the toolset is Salesforce Flow, Flow Orchestration, Composer, MuleSoft RPA and Anypoint Platform working together.
    Tested as
    Frames every scenario as a multi-tool process.
    Trap
    Treating it as a synonym for RPA alone.

  • API before RPA

    If a system offers a usable API, integrate through it; use RPA only where the interface is the only access point.

    Remember
    APIs are faster, more stable and easier to govern than screen automation.
    Tested as
    Decides many tool-selection questions.
    Trap
    Choosing a bot because the users currently do the task through the screen.

  • Composer vs. Anypoint

    Composer is no-code integration with prebuilt connectors for admins; Anypoint is a developer platform for designing, building, securing and reusing APIs.

    Remember
    Complexity, volume, governance and reuse push work from Composer to Anypoint.
    Tested as
    Common pairwise choice in integration scenarios.
    Trap
    Using Anypoint for a simple two-app sync that Composer handles.

  • Flow vs. Flow Orchestration

    A flow automates one process path; an orchestration sequences several flows into stages with steps for different users or background work.

    Remember
    Multi-user, multi-stage, long-running work points to Orchestration.
    Tested as
    Appears when approvals or hand-offs span teams.
    Trap
    Building a single screen flow with pauses to simulate several people's work.

  • Asynchronous RPA hand-off

    RPA processes run on bots and may take minutes, so callers start them and handle results later.

    Remember
    Do not hold a Salesforce transaction or API request open waiting for a bot.
    Tested as
    Design-pattern questions about calling RPA from other tools.
    Trap
    Expecting a synchronous response from a bot inside a record-triggered flow.

  • Flow fault path

    A connector from a Flow element that runs when the element fails, used to log, notify or recover.

    Remember
    Without one, the flow fails, the transaction rolls back and an error email goes out.
    Tested as
    Fault-handling questions on the Salesforce side.
    Trap
    Assuming a failed callout is ignored and the flow continues.

  • On Error Continue vs. On Error Propagate

    Mule error handlers: Continue treats the error as handled and returns success; Propagate rethrows it to the caller.

    Remember
    Use Propagate when the caller must know the request failed.
    Tested as
    Fault handling for Anypoint pieces of a solution.
    Trap
    Using Continue and then wondering why callers see HTTP 200 for failures.

  • End-to-end test data

    Coordinated records in every connected test system so one transaction can flow through all tools.

    Remember
    Cover happy path, boundaries and each error branch in non-production environments.
    Tested as
    Testing objective scenarios.
    Trap
    Testing against production data because a sandbox lacks matching records.

  • Exchange-first reuse

    Search Anypoint Exchange for existing APIs, connectors and templates before building.

    Remember
    Reuse is the reason the catalog exists.
    Tested as
    Reuse scenarios across teams.
    Trap
    Building a duplicate system API because the team did not check the catalog.

  • Development velocity

    The time to build and change a solution, driven by tool and use case complexity.

    Remember
    No-code is fastest for simple cases; complexity can reverse the ranking.
    Tested as
    Timeline-driven tool choices.
    Trap
    Ignoring maintenance effort when ranking speed.

  • Credential handling

    Named credentials in Salesforce, Composer connections, and stored credentials for bots and Mule apps keep secrets out of logic.

    Remember
    Never hardcode credentials in flows, bot steps or application code.
    Tested as
    Design-pattern and security distractors.
    Trap
    Choosing an option that embeds a password in a formula or variable.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Which tool for which job

ConceptMeaningKey differenceCommon trap
Salesforce Flow Declarative automation on Salesforce data Runs inside the org; triggers on records, schedules, events or screens Using it for heavy cross-system transformation
MuleSoft Composer No-code integration with prebuilt connectors Fast for simple syncs between supported apps Pushing complex, high-volume or custom-secured integrations into it
MuleSoft RPA Bots that operate user interfaces Only option when the system has no API Choosing it where an API exists
Anypoint Platform Design, build, secure and manage APIs Governed, reusable, pro-code integration Using it for a one-off two-app sync
Flow Orchestration Stages and steps across users and flows Coordinates long-running, multi-user work Replacing it with one long screen flow

Fault handling by tool

ConceptMeaningKey differenceCommon trap
Salesforce Flow Fault connector on failing elements Unhandled faults roll back and email the admin No fault path on callouts
Composer Run history shows failed executions Guard steps with If/Else checks on data Assuming Composer retries silently
MuleSoft RPA Exception handling in the bot workflow and run monitoring Failures surface per process run in RPA Manager Ignoring interface changes as a failure cause
Mule application On Error Continue or On Error Propagate Continue returns success; Propagate rethrows Hiding failures with Continue

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Bot for everything

    What candidates pick
    Automate the task with an RPA bot because staff do it through the screen today.
    Why it looks right
    It mirrors the current manual process exactly.
    Why it's wrong
    If the application has an API, an API-based integration is faster, more reliable and easier to govern than screen automation.

    Clue to watch for The scenario mentions that the system has a REST API or a Composer connector.

  2. Pro-code by default

    What candidates pick
    Build a Mule application with API-led layers for a two-system field sync.
    Why it looks right
    Anypoint is the most powerful option.
    Why it's wrong
    It adds design, build and deployment time where a Composer flow meets the requirement with no code.

    Clue to watch for Simple mapping, supported connectors, admin-owned, needed quickly.

  3. Waiting on the bot

    What candidates pick
    Call an RPA process from a record-triggered flow and wait for its output in the same transaction.
    Why it looks right
    It keeps the logic in one place.
    Why it's wrong
    Bots run asynchronously and can take minutes; the result must come back through a later update or event.

    Clue to watch for The bot works in a slow legacy desktop application.

  4. Unit tests as proof

    What candidates pick
    Declare the solution tested because each flow, bot and API passed its own tests.
    Why it looks right
    Every component shows green.
    Why it's wrong
    The integration points between tools carry most cross-system risk and need an end-to-end case with coordinated data.

    Clue to watch for The question asks how to validate the whole process.

  5. Swallowing errors

    What candidates pick
    Wrap every Mule flow in On Error Continue so callers never see failures.
    Why it looks right
    It looks robust and keeps responses clean.
    Why it's wrong
    Callers then treat failed requests as successes and data silently diverges between systems.

    Clue to watch for A downstream system must know when the request failed.

  6. Copy as reuse

    What candidates pick
    Duplicate a working integration into the new project.
    Why it looks right
    It is quick and already tested.
    Why it's wrong
    Copies drift apart and double maintenance; reuse means consuming one shared asset.

    Clue to watch for A second team needs the same capability.

Answer framework

For any hyperautomation scenario, assign tools step by step before reading the answer options.

  1. Break the process into steps and note for each one the system involved, whether it offers an API, and whether a person must act.
  2. Use Salesforce Flow for logic on Salesforce data and Flow Orchestration when several people or stages are involved over time.
  3. Use Composer for straightforward integrations between Salesforce and supported apps, and Anypoint when governance, volume, complex transformation or reuse matter.
  4. Use MuleSoft RPA only for steps where the target system has no usable API, and design the hand-off as asynchronous.
  5. Add fault handling, end-to-end test data and a check of Exchange for reusable assets before settling on the design.

Practice question

An insurer wants claims created in Salesforce to be entered automatically into a 20-year-old desktop claims system that has no API, then have adjusters approve them in stages. Which combination should the developer propose?

Want more like this? The Mule-Dev-202 practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Treat this section as a capstone and study it twice: once at the start to learn what each tool is for, and again after the tool-specific sections to sharpen the judgment calls. Build a one-page matrix with the tools as columns and rows for trigger types, who builds it, interface needed, error handling, testing option, reuse mechanism and typical delivery time.

High-priority ideas are API before RPA, Composer versus Anypoint, Flow versus Flow Orchestration and asynchronous bot hand-offs. Commonly underestimated areas are end-to-end test data across several systems and the differences in fault handling between tools, because candidates tend to know one tool well and guess at the rest.

For practice, take any multi-system process you know from work and write down which tool you would use for every step and why, then check each choice against the constraints in the scenario. In practice questions, underline phrases such as no API, several approvers, no developers, high volume and reuse, because they usually decide the answer. If you studied before the 31 August 2026 cutoff and hold the credential, use this matrix as a reference for project design rather than exam drilling.

FAQ

How much of the Mule-Dev-202 exam is Employ best practices when using hyperautomation?

This section carries 20% of the exam, the largest single share. On a 60-question exam that is about 12 questions as a planning estimate, and its tool-selection logic also shows up inside the other seven sections.

Is the MuleSoft Hyperautomation Developer certification retiring?

Yes. Salesforce's 2027 certification retirements FAQ lists it. Registration closed 24 July 2026, the last exam day was 31 August 2026, and the credential retires on 1 February 2027. Salesforce named no successor and says it is assessing the skills for future certification offerings.

Does my credential stay valid until it retires?

According to Salesforce's announcement, retiring certifications remain valid through 1 February 2027 with no maintenance required before then. After that date it is shown as retired on the Trailblazer profile.

Was this exam previously called something else?

Yes. It launched as Salesforce Certified Hyperautomation Specialist and was later renamed MuleSoft Hyperautomation Developer with the exam code Mule-Dev-202. Some Salesforce URLs and the official preparation trailmix still carry the older hyperautomation specialist name.

When should I choose RPA over an API integration?

Only when the system has no usable API, or the API cannot provide the needed function. RPA bots depend on the user interface, so layout changes can break them, which makes them a fallback rather than a first choice.

How long should I spend on this section?

Plan roughly 12 to 15 hours as an editorial estimate, split between an early pass and a review after the tool-specific sections. Most of that time should go into scenario practice rather than reading.

Which other sections connect most closely to this one?

The Composer, RPA and Anypoint API sections supply the detail behind each tool choice made here. Reading them after a first pass of this section makes the trade-offs easier to judge.

Other CRM & Business Applications certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 1 knowledge

You have worked through tool selection, end-to-end testing, cross-tool patterns, fault handling, reuse and delivery speed. Check whether you can choose the right tool combination under timed scenario pressure.

Take the Mule-Dev-202 practice test Check your Mule-Dev-202 readiness

Keep going