Home / crm-business-applications / Salesforce Certified MuleSoft Hyperautomation Developer (Mule-Dev-202) / Cheat Sheet
Salesforce Certified MuleSoft Hyperautomation Developer (Mule-Dev-202)

Mule-Dev-202 Cheat Sheet

Mule-Dev-202 Tested Picking the Lightest Tool per Step — Not Bots for Everything

Retiring: the last exam date was 31 August 2026 and the credential retires 1 February 2027, with no named successor. This sheet serves holders and anyone learning how Flow, Composer, RPA and Anypoint fit together.

Check Your Readiness →
Among the harder certs
Avg: Not published by Salesforce
Pass: 750 / 1000
Most candidates understand Salesforce Certified MuleSoft Hyperautomation Developer (Mule-Dev-202) concepts — and still fail. This exam tests how you apply knowledge under pressure.

Mule-Dev-202 Domain Map (eight sections)

Scenarios mix systems with and without APIs, human approvals, documents and volume. Each answer names one tool or pattern, and the winner is the simplest that meets the constraints. Weights and objective wording come from secondary sources because the official guide could not be read.

  1. 01
    Hyperautomation best practices (20%) — API before RPA, tool choice, async bot hand-offs, error handling, end-to-end testing
  2. 02
    MuleSoft RPA (17%) — RPA Manager lifecycle, RPA Builder, Recorder, BPMN design, bots, selectors and waits
  3. 03
    Anypoint API delivery (15%) — API-led layers, spec-first design, Runtime Manager vs API Manager, CloudHub 2.0, Runtime Fabric
  4. 04
    Salesforce Flow (13%) — before-save vs after-save, async path callouts, External Services, named credentials, Flow tests
  5. 05
    Composer (12%) — one trigger per flow, If/Else vs For Each, data pills, formulas, test runs, run history
  6. 06
    Exchange (8%) — private Exchange vs public portal, mocking service, fragments, versioning, deprecation
  7. 07
    Flow Orchestration (8%) — sequential stages, parallel steps, interactive vs background steps, evaluation flows
  8. 08
    API monitoring (7%) — basic vs proxy endpoints, autodiscovery, client ID enforcement, rate limiting vs spike control

Wrong instinct vs correct approach

A record-triggered flow must call an external API and write the response back when a case is created
✕ Wrong instinct

Use a before-save flow to make the callout

✓ Correct approach

Before-save flows can only update the triggering record's fields. Use an after-save flow with a Run Asynchronously path, calling through External Services or the HTTP callout action, authenticated by named and external credentials.

Company policy says all integration workloads must run on infrastructure the company owns
✕ Wrong instinct

Deploy to a CloudHub 2.0 private space

✓ Correct approach

Private spaces are isolated but still MuleSoft-managed. Customer-owned hosting means Runtime Fabric, where you run the infrastructure and MuleSoft supplies the control plane, or hybrid standalone runtimes with maximum control and operations burden.

An API Manager policy is applied to a Mule app on a basic endpoint, yet requests pass unchecked
✕ Wrong instinct

Remove and reapply the policy in API Manager

✓ Correct approach

Basic endpoints rely on API autodiscovery in the Mule app referencing the API instance ID. Fix the missing or wrong autodiscovery configuration. Non-Mule or unmodifiable backends need a proxy endpoint instead.

Gold-tier partners need more daily calls than other consumers of the same API
✕ Wrong instinct

Configure spike control with a higher threshold

✓ Correct approach

Spike control smooths short bursts and is not a quota. Apply SLA-based rate limiting with tiers on client contracts, which requires client identification through client ID enforcement.

Consumer teams want to start integrating while the API implementation is still weeks away
✕ Wrong instinct

Tell them to wait until it is deployed

✓ Correct approach

Publish the RAML or OpenAPI spec with examples to Exchange and let teams build against the mocking service. Spec-first design validates the contract early; mocks say nothing about real logic or load.

Know these cold

  • ▸ API first, Composer for simple no-code syncs, Anypoint for complex reusable APIs, RPA last
  • ▸ Composer — ne trigger per flow; If/Else branches once, For Each iterates a list
  • ▸ Composer test runs perform real actions, so point them at sandbox connections
  • ▸ RPA Builder builds bot workflows; RPA Manager designs, deploys and monitors production runs
  • ▸ Wait for UI elements, not fixed sleeps; change bots by new version, never hotfix production
  • ▸ Runtime Manager deploys and scales apps; API Manager owns policies, contracts and SLA tiers
  • ▸ System APIs unlock data, process APIs combine, experience APIs shape output per channel
  • ▸ Exchange versions — ajor bump means breaking change; deprecate old versions, never delete them
  • ▸ Orchestration interactive steps run screen flows for users or queues; background steps run autolaunched
  • ▸ In-flight orchestration runs stay on their starting version; activating a fix does not rescue them

Can you answer these without checking your notes?

In this scenario: "A record-triggered flow must call an external API and write the response back when a case is created" — what should you do first?
Before-save flows can only update the triggering record's fields. Use an after-save flow with a Run Asynchronously path, calling through External Services or the HTTP callout action, authenticated by named and external credentials.
In this scenario: "Company policy says all integration workloads must run on infrastructure the company owns" — what should you do first?
Private spaces are isolated but still MuleSoft-managed. Customer-owned hosting means Runtime Fabric, where you run the infrastructure and MuleSoft supplies the control plane, or hybrid standalone runtimes with maximum control and operations burden.
In this scenario: "An API Manager policy is applied to a Mule app on a basic endpoint, yet requests pass unchecked" — what should you do first?
Basic endpoints rely on API autodiscovery in the Mule app referencing the API instance ID. Fix the missing or wrong autodiscovery configuration. Non-Mule or unmodifiable backends need a proxy endpoint instead.

Common Exam Mistakes — What candidates get wrong

Automating a screen task with a bot when the system already exposes an API

RPA is the fallback for applications reachable only through their interface. If a REST API or a Composer connector exists, integrate through it: faster, more stable and easier to govern than MuleSoft RPA screen automation.

Building a Mule application for a simple two-app field sync

Composer covers admin-owned, connector-supported, simple-mapping integrations with no code. Complexity, volume, governance and reuse are what push work to Anypoint and API-led layers. Over-engineering costs design, build and deployment time.

Waiting synchronously for an RPA bot inside a record-triggered flow

Bots run on Windows machines and can take minutes. Start the RPA process asynchronously through the Composer or Mule RPA connector and return the result via a later record update or platform event, never by holding the transaction.

Wrapping Mule flows in On Error Continue so callers never fail

On Error Continue marks the error handled and returns success, so callers see HTTP 200 while data silently diverges. On Error Propagate rethrows to the caller and is right whenever a downstream system must know the request failed.

Putting independent department tasks into separate orchestration stages

In Flow Orchestration, stages run one after another while steps inside a stage run in parallel by default. Independent tasks belong as steps in one stage; use step entry conditions rather than new stages to delay a single step.

Resources to help you pass MuleSoft Hyperautomation Developer on your first attempt

Hold Mule-Dev-202 or studying hyperautomation? Check how well you choose between Flow, Composer, RPA and Anypoint.