Overview
MuleSoft RPA has three main parts. RPA Manager is the web application where teams evaluate candidate processes, model them, manage the lifecycle, deploy them to bots and monitor runs. RPA Builder is the Windows desktop tool where developers build the automated steps, often starting from recordings made with RPA Recorder. RPA Bots are the runtime that executes deployed processes on Windows machines.
A process moves through defined lifecycle phases in RPA Manager. Evaluation scores whether a manual process is worth automating. Design captures the process as a BPMN model with automated activities for bots and manual or human activities for people. Build implements each automated activity in RPA Builder. Test runs the process with test plans on bots. Production deploys the tested version, sets schedules or triggers, and lets you monitor results and troubleshoot failures. Processes can also be started from Composer and Mule applications through RPA connectors, which is how bots fit into a wider hyperautomation solution.
How it's tested
RPA questions follow the lifecycle. They ask which phase or component handles a task, what to do before promoting a process to production, how to start a bot from another tool, or where to look when runs fail. The correct answer names the specific RPA Manager or RPA Builder feature rather than a generic automation idea.
-
Where in the lifecycle
A task such as scoring a process, modelling it, building steps or scheduling runs is described, and you name the phase or component.
-
Bot design choices
A workflow must handle a pop-up, a login, variable data or an error, and you choose the Builder technique.
-
Production problem
Runs fail or slow down after deployment, and you choose the monitoring view, log or fix that addresses it.
An operations lead wants to know whether automating a weekly vendor reconciliation is worth it before anyone builds a bot. That is the evaluation phase in RPA Manager, where the process is described with metrics such as frequency, duration and rule-based steps to estimate automation potential and savings. Opening RPA Builder first would skip the business case and risk automating a process that is not a good fit.
Objectives 4
Official objectives from the Salesforce outline, in outline order.
3.1 Evaluate an RPA process in MuleSoft RPA Manager.Scoring candidate processes for automation potential and value.
- What it means
- The evaluation phase in RPA Manager captures a candidate process with details such as how often it runs, how long it takes, how many people perform it, how rule-based and stable it is, and what data it uses. RPA Manager uses this input to estimate automation potential and expected benefit so teams can prioritize.
- What to understand
- Good RPA candidates are high-volume, repetitive, rule-based, use structured digital input and run against stable interfaces. Processes that need judgment, change often or already have API access are weak candidates. Evaluation happens before design and build, and a process can be rejected or deferred at this stage.
- How it shows up
- You are asked which process is the best candidate, or which phase determines whether automation is worthwhile.
- Common confusion
- A process being tedious does not make it a good candidate; frequent interface changes or judgment calls undermine bot reliability.
3.2 Perform general RPA process development tasks including designing, building, and testing RPA processes.BPMN design in RPA Manager, bot workflows in RPA Builder, test plans.
- What it means
- In the design phase you model the process in RPA Manager with BPMN, marking automated activities for bots and manual activities for people, plus process variables for data passed between steps. In the build phase each automated activity is implemented in RPA Builder as a workflow of action steps, often from an RPA Recorder capture. The test phase runs the process on bots using test plans and data.
- What to understand
- Design decisions shape everything later: which steps are automated, where people intervene, and which inputs and outputs the process exposes to callers. In Builder, use robust selectors, waits and exception handling instead of fixed delays, and store credentials securely rather than in the workflow. Testing should cover expected data and error paths on a bot environment that matches production.
- How it shows up
- A step needs a human decision, a bot must handle an unexpected dialog, or a test must run before release, and you pick the right design or build feature.
- Common confusion
- RPA Recorder produces a starting workflow, not a finished bot; recordings still need cleanup, parameters and error handling in Builder.
3.3 Deploy RPA processes.Promoting tested processes to production bots and starting them.
- What it means
- After testing, a process version moves to production in RPA Manager, where you assign it to bots, define how it starts (a schedule, a manual start, or an external call through the RPA API or connectors from Composer and Mule applications) and supply input parameters.
- What to understand
- Only tested versions should reach production, and new versions follow the same lifecycle rather than being edited live. Bots need capacity and the right applications installed on their machines. External callers start processes asynchronously and should handle the result later, for example by reading output or receiving an update when the run finishes.
- How it shows up
- A tested process must start whenever a Composer flow detects a new record, and you choose the deployment and invocation setup.
- Common confusion
- Deploying a process does not make it run; it also needs a schedule, manual start or external trigger.
3.4 Monitor and troubleshoot RPA processes.Using RPA Manager run data, logs and screenshots to fix failures.
- What it means
- RPA Manager shows production runs with status, duration and failures, along with logs and run details that help locate the failing activity. Dashboards summarise volumes and outcomes so teams can see whether the automation delivers the expected benefit.
- What to understand
- Common failure causes are changed user interfaces, expired or locked credentials, slow application responses, unexpected pop-ups, missing input data and bot machine issues. Troubleshooting starts with the failed run's details, then reproduces the problem in a test phase before a corrected version is redeployed. Exception handling in the workflow should route business errors to people rather than stopping silently.
- How it shows up
- Runs started failing after a target application update, and you identify the cause and the correct fix path.
- Common confusion
- Patching a production process directly skips testing; fixes should go through a new version and the test phase.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
RPA Manager
Web application for evaluating, designing, testing, deploying, monitoring and administering RPA processes and bots.
- Remember
- The lifecycle and all production monitoring live here.
- Tested as
- Most lifecycle questions point to it.
- Trap
- Looking for monitoring in RPA Builder.
-
RPA Builder
Windows desktop tool where developers build bot workflows for automated activities.
- Remember
- Implements the build phase for activities designed in RPA Manager.
- Tested as
- Build-phase questions.
- Trap
- Using it to model the overall process.
-
RPA Recorder
Captures a user's actions in applications to generate a starting workflow.
- Remember
- Output needs refinement before it is robust.
- Tested as
- Speeding up build tasks.
- Trap
- Treating a recording as production-ready.
-
RPA Bot
Runtime that executes deployed processes on a Windows machine.
- Remember
- Needs the target applications and access configured on its machine.
- Tested as
- Deployment and failure scenarios.
- Trap
- Assuming any bot can run any process without setup.
-
Lifecycle phases
Evaluation, design, build, test and production for each process.
- Remember
- Changes go through a new version and testing before production.
- Tested as
- Sequence questions.
- Trap
- Editing production directly.
-
BPMN process model
The design-phase diagram of activities, gateways and flow in RPA Manager.
- Remember
- Separates automated activities for bots from manual activities for people.
- Tested as
- Design questions involving human steps.
- Trap
- Forcing judgment steps into the bot.
-
Process evaluation
Scoring a candidate by frequency, effort, rules and stability to estimate automation potential.
- Remember
- Rule-based, repetitive, stable and high-volume processes score best.
- Tested as
- Choosing candidates.
- Trap
- Picking a judgment-heavy process because it is tedious.
-
Process variables and parameters
Data passed into a process, between activities and back to callers.
- Remember
- Define inputs and outputs so Composer or Mule callers can supply data.
- Tested as
- Invocation questions.
- Trap
- Hardcoding values that change per run.
-
RPA connectors
Composer and Mule connectors that start RPA processes from other tools.
- Remember
- Start processes asynchronously and handle results later.
- Tested as
- Cross-tool patterns.
- Trap
- Waiting synchronously on bot completion.
-
Selector and wait robustness
Identifying UI elements reliably and waiting for conditions rather than fixed delays.
- Remember
- Fixed delays cause failures when applications slow down.
- Tested as
- Build and troubleshooting questions.
- Trap
- Adding longer sleeps to fix timing failures.
-
Credential storage
Storing application logins securely for bots instead of inside workflows.
- Remember
- Expired credentials are a common production failure.
- Tested as
- Security and troubleshooting.
- Trap
- Embedding passwords in workflow steps.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
RPA Manager vs. RPA Builder vs. RPA Recorder vs. RPA Bot
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| RPA Manager | Web lifecycle and operations console | Evaluate, design, test, deploy, monitor | Expecting to build detailed steps here |
| RPA Builder | Desktop workflow development tool | Implements automated activities | Using it for process evaluation |
| RPA Recorder | Captures user actions | Generates a draft workflow | Shipping a raw recording |
| RPA Bot | Execution runtime on Windows | Runs deployed processes | Ignoring machine setup |
Automated vs. manual activities in a process design
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Automated activity | Work performed by a bot | Rule-based, repeatable steps | Including judgment calls |
| Manual activity | Work performed by a person | Decisions, exceptions, approvals | Removing all people from the design |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Automate the judgment step
- What candidates pick
- Have the bot decide which exceptions to approve.
- Why it looks right
- Full automation sounds better.
- Why it's wrong
- Judgment steps belong in manual activities for people; bots handle rule-based steps reliably.
Clue to watch for The scenario mentions review, discretion or unclear rules.
-
Monitoring in Builder
- What candidates pick
- Open RPA Builder to see production run failures.
- Why it looks right
- Builder is where the workflow lives.
- Why it's wrong
- Production run status, logs and dashboards are in RPA Manager.
Clue to watch for The process is already deployed.
-
Bigger sleep
- What candidates pick
- Increase fixed waits until the bot stops failing.
- Why it looks right
- It quickly hides timing errors.
- Why it's wrong
- Fixed delays waste time and still fail when the application is slower; wait for an element or condition instead.
Clue to watch for Failures are intermittent and tied to slow screens.
-
Deployed means running
- What candidates pick
- Assume a process starts once moved to production.
- Why it looks right
- Deployment feels like the last step.
- Why it's wrong
- It also needs a schedule, manual start or an external trigger from Composer, a Mule app or the API.
Clue to watch for The process never runs after deployment.
-
Hotfix in production
- What candidates pick
- Edit the live process to fix a broken selector.
- Why it looks right
- It is the fastest way back to service.
- Why it's wrong
- Changes should be made as a new version and tested before redeployment to avoid new failures.
Clue to watch for The question asks for the recommended fix process.
Answer framework
Place every RPA question on the lifecycle first, then pick the component.
- Decide which lifecycle phase the scenario is in: evaluation, design, build, test or production, as each phase has its own RPA Manager or RPA Builder task.
- For evaluation, favour rule-based, repetitive, high-volume processes on stable interfaces and reject those with APIs or heavy judgment.
- For design and build, separate automated from manual activities, define variables, and build robust workflows with proper waits and exception handling.
- For deployment, promote only tested versions, assign the bot to suitable RPA Bots, and set the start method: schedule, manual start or an asynchronous call from another tool.
- For failures, read run details in RPA Manager, identify interface, credential, data or timing causes, and fix through a new tested version.
Practice question
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
Start with the lifecycle, because most questions place you somewhere on it. Draw the five phases and, under each, write which component you use, what you produce and what must be true before moving on. Then work through the Trailhead MuleSoft RPA modules and the RPA documentation pages for RPA Manager and RPA Builder, noting the names of screens and features as they appear.
High-priority topics are evaluation criteria, the split between automated and manual activities, deployment and start options, and where monitoring data lives. Underestimated areas are robustness techniques in Builder, such as waiting for elements instead of fixed delays, and the operational causes of failures like expired credentials and changed screens.
If you cannot access an RPA environment, study the documentation screenshots and walk through a sample process on paper: evaluate it, model it in BPMN, list its automated steps and their inputs, define test cases, and choose how it starts in production. When practising questions, name the phase before reading the options; that alone removes most distractors.
FAQ
How much of the Mule-Dev-202 exam is Design, build, and manage MuleSoft RPA processes used in hyperautomation?
This RPA section is 17% of the exam, the second-largest share, or about 10 of 60 questions as an editorial estimate.
Do I need hands-on RPA experience?
It helps a great deal. The questions name specific components and lifecycle phases, so at least walk through the RPA Manager and RPA Builder documentation and Trailhead content in detail if you have no environment.
What is the difference between RPA Manager and RPA Builder?
RPA Manager is the web console for the process lifecycle, deployment and monitoring. RPA Builder is the desktop tool where developers build the bot workflows for automated activities.
How do other tools start an RPA process?
A production process can run on a schedule, be started manually, or be called by Composer or a Mule application through RPA connectors or the RPA API. Calls should be treated as asynchronous.
What makes a process a good RPA candidate?
High volume, repetitive and rule-based work with structured inputs on a stable interface that has no suitable API. Processes needing judgment or with frequently changing screens score poorly.
How long should I study this section?
Plan about 10 to 13 hours as an editorial estimate, more if RPA is new to you.
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 3 knowledge
You have covered RPA process evaluation, BPMN design, building in RPA Builder, testing, deployment and monitoring. Check whether you can place RPA tasks on the lifecycle under timed conditions.
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