Overview
Routers decide where an event goes next. The Choice router evaluates DataWeave conditions in order and sends the event down the first route whose condition is true, or to the default route when none match. Scatter-Gather copies the event to every route, runs the routes concurrently, waits for all of them and combines their results into one object. The Validation module checks an event against rules, such as not null, email format or a regex, and raises an error when a rule fails.
The three objectives in the exam guide follow these tools exactly: route messages using DataWeave conditions in a Choice router, scatter and gather messages, and validate Mule events, each time predicting outcomes. Expect to read short XML or diagrams and answer which route runs, what the Scatter-Gather payload looks like, or what happens when one route fails or a validation rule is broken.
How it's tested
Questions show a router with two to four routes and some input, then ask which processors run or what the final payload is. Scatter-Gather items often add a failing route. Validation items ask which validator meets a requirement or which error type a failed check raises.
-
Which route runs
Given input and Choice conditions, you pick the single route that executes, considering order and the default.
-
Shape of gathered results
You predict the Scatter-Gather payload structure and how to read one route's result.
-
Fail fast on bad data
A requirement to reject invalid input leads you to the right validator and its error type.
A Choice router has a first route with payload.amount > 100 and a second with payload.amount > 1000, plus a default. For an amount of 5000, both conditions are true, but Choice evaluates in order and runs only the first matching route. The second route never executes. To treat large orders differently, the stricter condition must be listed first.
Objectives 3
Official objectives from the Salesforce outline, in outline order.
9.1 Apply correct processors/syntax to route messages using DataWeave conditions within a choice router, and predict outcomes.Ordered when conditions and the default route.
- What it means
- The Choice router contains one or more when routes, each with a DataWeave expression that returns a Boolean, and an optional default route. Conditions are evaluated in order, and only the first true route runs. After that route, processing continues with the processor following the router.
- What to understand
- Write conditions that reference payload, attributes or variables, such as #[attributes.queryParams.type == 'premium'] or #[vars.total > 500]. Because evaluation stops at the first match, list more specific conditions before general ones. Beware of null values: comparing a missing field may evaluate to false or raise an error depending on the expression, so use default where data may be missing. Changes made in the chosen route, including payload and variables, are carried forward after the router.
- How it shows up
- Input matching several conditions is shown, and you choose the single route that runs.
- Common confusion
- Choice is not a multicast; it never runs more than one route for an event.
9.2 Apply correct processors/syntax to scatter and gather messages, and predict outcomes.Concurrent routes, the combined result and composite errors.
- What it means
- Scatter-Gather sends a copy of the event to each route, runs the routes concurrently and waits until all complete. The resulting payload is an object whose keys are the route indexes, "0", "1" and so on, and each value is a Mule message with its own payload and attributes.
- What to understand
- Read a route's body with payload['0'].payload, and combine results with DataWeave, for example flatten(payload pluck $.payload). Variables set in the routes are merged into the event after the router. If any route fails, Scatter-Gather waits for the others and then raises MULE:COMPOSITE_ROUTING, whose error details include successful results and failures. A timeout and a maximum concurrency can be configured. Use it for independent calls; when one call needs another's output, call them sequentially.
- How it shows up
- You predict the payload structure after Scatter-Gather, or what happens when one route fails.
- Common confusion
- The result is an object of messages keyed by index, not an array of payloads.
9.3 Apply correct processors/syntax to validate Mule events, and predict outcomes.Validation module operations and error types.
- What it means
- The Validation module provides operations such as Is not null, Is true, Is false, Is email, Is number, Matches regex, Validate size and Is not blank string. Each checks a value and either lets the event continue unchanged or raises a VALIDATION error.
- What to understand
- Failed checks raise typed errors in the VALIDATION namespace, such as VALIDATION:NULL or VALIDATION:INVALID_EMAIL, with a configurable message. Error handlers can catch them by type and return a 400 response. The All scope runs several validations and reports every failure together as VALIDATION:MULTIPLE instead of stopping at the first. Validation does not transform data; it only allows or blocks the event, so the payload is unchanged when it passes.
- How it shows up
- A requirement to reject bad input leads you to the correct validator or error type.
- Common confusion
- A passing validation does not return true as the payload; the event continues unchanged.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Choice router
Routes an event to the first route whose condition is true.
- Remember
- Only one route runs; the default runs when none match.
- Tested as
- Route prediction questions.
- Trap
- Expecting every true route to run.
-
Condition order
Choice evaluates when expressions top to bottom.
- Remember
- Place specific conditions before general ones.
- Tested as
- Overlapping-condition questions.
- Trap
- Ignoring order.
-
Default route
The otherwise branch for events that match no condition.
- Remember
- Use it to handle unexpected values explicitly.
- Tested as
- Fallback questions.
- Trap
- Assuming a default is always generated.
-
Scatter-Gather
Sends copies of the event to routes concurrently and waits for all.
- Remember
- Independent calls only.
- Tested as
- Parallel processing questions.
- Trap
- Using it for dependent calls.
-
Scatter-Gather payload
Object keyed by route index with a message per route.
- Remember
- Use payload['0'].payload for a route body.
- Tested as
- Result-shape questions.
- Trap
- Expecting a flat array.
-
MULE:COMPOSITE_ROUTING
Error raised when one or more Scatter-Gather routes fail.
- Remember
- Raised after all routes finish.
- Tested as
- Failure behaviour questions.
- Trap
- Thinking the router stops at the first failure.
-
Validation module
Operations that check values and raise VALIDATION errors.
- Remember
- Payload is unchanged on success.
- Tested as
- Input checking questions.
- Trap
- Expecting a Boolean payload.
-
All scope
Runs several validators and reports all failures together.
- Remember
- Raises VALIDATION:MULTIPLE.
- Tested as
- Collecting every input problem.
- Trap
- Assuming validators already aggregate failures.
-
Is not null and Matches regex
Common validators for required fields and formats.
- Remember
- Combine with error handlers for 400 responses.
- Tested as
- Choosing a validator for a rule.
- Trap
- Using a Choice router to hand-code each check.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Choice vs Scatter-Gather
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Choice | Runs one route based on conditions | Sequential; first match wins | Expecting several routes to run |
| Scatter-Gather | Runs all routes concurrently | Combines results into an object of messages | Expecting conditions on routes |
Validation approaches
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Single validator | Checks one rule and stops at failure | Raises a specific VALIDATION error | Missing other problems in the same request |
| All scope | Runs many validators and aggregates failures | Raises VALIDATION:MULTIPLE | Expecting it to continue the flow after failures |
| Choice-based checks | Hand-written conditions and Raise Error | More code and custom types | Rebuilding what the module offers |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Multiple matches
- What candidates pick
- Selecting the option where two Choice routes run.
- Why it looks right
- Both conditions are true.
- Why it's wrong
- Choice runs only the first matching route in order.
Clue to watch for Overlapping numeric thresholds.
-
Flat result
- What candidates pick
- Choosing [payload1, payload2] as the Scatter-Gather output.
- Why it looks right
- It is the simplest shape to imagine.
- Why it's wrong
- The result is an object keyed by index, each value a message with payload and attributes.
Clue to watch for Options differ in brackets and nesting.
-
Fail fast routes
- What candidates pick
- Believing Scatter-Gather aborts other routes on failure.
- Why it looks right
- Fail-fast is common in parallel code.
- Why it's wrong
- Mule waits for all routes, then raises MULE:COMPOSITE_ROUTING with successes and failures.
Clue to watch for One route calls a failing endpoint.
-
Scatter-Gather for chained calls
- What candidates pick
- Using Scatter-Gather when call B needs data from call A.
- Why it looks right
- It looks faster.
- Why it's wrong
- Routes run on copies of the same event concurrently, so B cannot see A's result.
Clue to watch for A dependency between calls is described.
-
Validator returns Boolean
- What candidates pick
- Expecting payload true after Is email passes.
- Why it looks right
- Validation sounds like a test that returns a value.
- Why it's wrong
- Validators leave the event unchanged on success and raise an error on failure.
Clue to watch for A Logger after a validator prints the payload.
Answer framework
Answer routing and validation questions by working through these steps.
- Decide whether the requirement is to choose one path, run several paths in parallel, or block invalid input.
- For Choice, evaluate conditions in listed order against the actual input and stop at the first true one, falling back to the default.
- For Scatter-Gather, confirm the routes are independent, then predict an object of messages keyed by route index.
- If any Scatter-Gather route fails, expect MULE:COMPOSITE_ROUTING after all routes complete, handled by the flow's error handling.
- For validation, pick the validator that matches the rule, note its VALIDATION error type, and use the All scope when every failure must be reported.
Practice question
Want more like this? The Mule-Dev-201 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
Routing is a compact section, so plan about one week of short sessions. Start with a Choice router that has three overlapping numeric conditions and a default route, and send inputs that hit each branch. Reorder the routes and repeat to see how order changes the result.
Next, build a Scatter-Gather with two HTTP Request routes to mock or public APIs. Log the whole payload, then write DataWeave to pull out each body and merge them. Make one route fail on purpose and inspect the MULE:COMPOSITE_ROUTING error in the debugger, including which results succeeded.
Finish with the Validation module: validate an email, a required field and a regex, then wrap them in an All scope and send a request that breaks all three. Catch the errors in an error handler that returns 400. This last step ties routing to the Handling Errors section, which you should study next while the routing errors are still fresh.
FAQ
How many Routing Events questions are on Mule-Dev-201?
Routing Events is 8% of the exam, about five of the 60 scored questions. They cover the Choice router, Scatter-Gather and the Validation module.
Can a Choice router run more than one route?
No. It evaluates conditions in order and runs only the first route whose condition is true, or the default route if none match.
What does the Scatter-Gather payload look like?
An object with keys "0", "1" and so on, one per route, where each value is a Mule message with payload and attributes.
What error does Scatter-Gather raise when a route fails?
MULE:COMPOSITE_ROUTING, raised after all routes finish. The error includes details of successful and failed routes.
Is the First Successful or Round Robin router on the exam?
They exist in Mule 4, but the current objectives name only the Choice router, Scatter-Gather and validation. Focus on those three.
What does a validator return when the check passes?
Nothing new. The event continues unchanged. On failure the validator raises a VALIDATION error that error handlers can catch.
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 9 knowledge
You have studied the Choice router, Scatter-Gather and the Validation module. Practise Mule-Dev-201 questions that ask which route runs and what the result looks like.
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-201 AI tutor Get any concept explained your way