Mule-Dev-201 · Domain 7 of 12

Mule-Dev-201 Domain 7: Processing Records

Processing Records tests how Mule handles collections: the For Each scope, Batch Jobs with steps and aggregators, database listeners that pick up new rows, and the Object Store for keeping data between flow executions.

Exam weight
10%
Official objectives
4
Estimated questions estimate
~6
Suggested study time estimate
7–9 hrs

About 12 min read Reviewed October 2026

Overview

Integrations often move many records at once: rows from a database, lines from a CSV file or items returned by an API. Mule 4 offers several ways to process them. The For Each scope loops synchronously over a collection inside the current flow. A Batch Job splits input into records and processes them asynchronously through batch steps, with an optional Batch Aggregator to group records for bulk operations and an On Complete phase that reports results.

The exam guide lists four objectives: process records with For Each scopes, with batch scopes, and with DB listeners, predicting outcomes each time, and persist data between flow executions. DB listeners, such as the Database connector's On Table Row source, poll a table and trigger a flow per new row, often using a watermark column so rows are not processed twice. To remember state between runs, such as the last processed ID, you use the Object Store rather than variables, which vanish when each event ends.

How it's tested

Expect flows with a For Each or Batch Job and a Logger after them, asking what is logged. Other items describe a volume and reliability requirement and ask which construct fits. Watermark and Object Store questions describe a scheduled job that must resume where it stopped.

  • After the loop

    You predict the payload and variables once a For Each scope has finished processing a collection.

  • Batch behaviour

    Records fail in one step, and you predict which later steps run for them based on accept policies.

  • Remember the position

    A polling flow must not reprocess rows after a restart, and you choose watermarking or the Object Store.

Reasoning it through

A flow receives an array of five orders, sets vars.total to 0, and runs a For Each that adds each order amount to vars.total and sets the payload to the order ID. After the scope, the payload is the original array of five orders, because For Each restores it, while vars.total holds the sum, because variable changes made inside the scope persist. A Logger printing sizeOf(payload) shows 5.

Objectives 4

Official objectives from the Salesforce outline, in outline order.

7.1 Apply correct processors/syntax to process individual records in a collection using For Each scopes, and predict outcomes.Synchronous iteration over a collection in the current flow.
What it means
For Each splits a collection, by default #[payload], and runs its processors once per element, sequentially. Inside the scope the payload is the current element, vars.counter holds the position starting at 1, and vars.rootMessage holds the original message. A batchSize setting can group elements into sub-arrays.
What to understand
When the scope ends, the payload returns to the original collection, not the results of the iterations. Variable changes made inside the scope remain afterwards, which is how you accumulate totals or results. If an element raises an unhandled error, the For Each stops and the error goes to the flow's handler; wrap the inner steps in a Try scope to continue with other elements. Parallel For Each runs elements concurrently and, unlike For Each, outputs a collection of the results.
How it shows up
A Logger after a For Each asks for the payload or a variable updated in the loop.
Common confusion
For Each does not return the modified elements; the original collection becomes the payload again.
7.2 Apply correct processors/syntax to process individual records in a collection using batch scopes, and predict outcomes.Batch Job phases, steps, accept policies and aggregators.
What it means
A Batch Job has a Load and Dispatch phase that splits the input into records and queues them, a Process phase made of one or more Batch Steps, and an On Complete phase. Records are processed asynchronously in blocks, by default of 100, on multiple threads. A Batch Aggregator inside a step collects a set number of records, or streams them, for bulk operations such as a database bulk insert.
What to understand
Each step has an accept policy: NO_FAILURES, the default, processes only records that have not failed; ONLY_FAILURES processes failed records; ALL processes every record. An accept expression can add a condition. Max failed records controls when the whole job stops; the default of 0 stops it after the first failure, and -1 allows unlimited failures. The On Complete phase receives a BatchJobResult with counts such as totalRecords, successfulRecords and failedRecords. The flow that starts a batch job does not wait for it to finish.
How it shows up
Records fail in step one, and you predict which steps process them or what On Complete reports.
Common confusion
Batch processing is asynchronous, so processors after the Batch Job in the flow run before records finish.
7.3 Apply correct processors/syntax to process individual records in a collection using DB listeners, and predict outcomes.On Table Row listeners, ID and watermark columns.
What it means
The Database connector's On Table Row source polls a table on a schedule and triggers the flow once per row returned. Its Watermark column setting tracks the highest value seen, such as a timestamp or increasing ID, so later polls only return newer rows. An ID column prevents the same row from being processed twice while it is still in flight.
What to understand
Watermarks are stored automatically in an object store, so they survive between polls and, with a persistent store, across restarts. Each row arrives as its own event with the row as payload, which is different from a Select that returns all rows in one array. Other connectors, such as the File and FTP listeners and some SaaS connectors, offer similar automatic watermarking. When a source lacks it, a Scheduler plus a Select with a manually stored watermark achieves the same result.
How it shows up
A table gains new rows over time, and you choose the listener settings so each row is processed once.
Common confusion
Without a watermark column, each poll can return rows that were already processed.
7.4 Apply correct processors/syntax to persist data between flow executions.Using the Object Store to keep state across events and restarts.
What it means
Variables exist only for the life of one event. To keep data between executions, such as the last processed timestamp, a cache of tokens or a counter, you use the Object Store connector's operations: Store, Retrieve, Contains, Remove and Retrieve All Keys.
What to understand
Object stores can be persistent or in memory, and can have entry time-to-live and maximum entries. On CloudHub, the Object Store v2 service backs persistent stores so data survives restarts and is shared across workers or replicas of the same application. A Retrieve with a default value avoids errors on the first run when the key does not exist. Use persistent stores for watermarks and in-memory stores for short-lived caching.
How it shows up
A scheduled flow must remember a value from its last run, and you choose an Object Store operation and setting.
Common confusion
A variable set in one scheduled run is not available in the next run.

High-yield concepts

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

  • For Each

    Synchronous loop over a collection inside the current flow.

    Remember
    Payload is restored to the original collection afterwards.
    Tested as
    Payload-after-loop questions.
    Trap
    Expecting transformed elements as the output.

  • vars.counter and vars.rootMessage

    Variables available inside For Each for position and the original message.

    Remember
    Counter starts at 1.
    Tested as
    Loop expression questions.
    Trap
    Assuming a zero-based counter.

  • Parallel For Each

    Processes elements concurrently and outputs a collection of results.

    Remember
    Elements may run in any order.
    Tested as
    Contrasting with For Each.
    Trap
    Thinking For Each also returns results.

  • Batch Job phases

    Load and Dispatch, Process with Batch Steps, and On Complete.

    Remember
    Records are processed asynchronously in blocks.
    Tested as
    Batch structure questions.
    Trap
    Placing record logic in On Complete.

  • Accept policy

    Controls which records a step processes: NO_FAILURES, ONLY_FAILURES or ALL.

    Remember
    Default is NO_FAILURES.
    Tested as
    Predicting steps for failed records.
    Trap
    Assuming failed records continue by default.

  • Batch Aggregator

    Groups records within a step by size or streaming for bulk operations.

    Remember
    Payload inside is an array of records.
    Tested as
    Bulk insert scenarios.
    Trap
    Expecting single-record payloads inside it.

  • Max failed records

    Job-level limit for failures before the job stops.

    Remember
    0 stops at the first failure; -1 is unlimited.
    Tested as
    Job stop behaviour.
    Trap
    Thinking 0 means unlimited.

  • On Table Row listener

    Database source that triggers per row with watermark and ID column options.

    Remember
    Each row is a separate event.
    Tested as
    DB listener objective.
    Trap
    Expecting one array of all rows.

  • Watermark

    Stored position marker so later polls fetch only new data.

    Remember
    Kept automatically in an object store.
    Tested as
    Avoiding reprocessing.
    Trap
    Storing it in a variable.

  • Object Store

    Key-value store that persists data between executions.

    Remember
    Persistent stores survive restarts; Object Store v2 backs them on CloudHub.
    Tested as
    Persist-data objective.
    Trap
    Using variables across runs.

Side by side

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

For Each vs Parallel For Each vs Batch Job

ConceptMeaningKey differenceCommon trap
For Each Sequential loop in the same flow Restores original payload; synchronous Expecting results collected as output
Parallel For Each Concurrent loop in the same flow Outputs a collection of results Assuming element order of execution
Batch Job Asynchronous record processing in steps Scales to large volumes; reports in On Complete Expecting the calling flow to wait

Where state lives

ConceptMeaningKey differenceCommon trap
Variable Value on one event Lost when the event ends Using it to remember the last run
Object Store (persistent) Key-value data kept between executions Survives restarts Forgetting a default for the first run
Watermark Automatic position marker for a listener Managed by the connector in an object store Building it manually when the listener supports it

Exam traps

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

  1. Loop output

    What candidates pick
    The payload after For Each is the list of modified elements.
    Why it looks right
    Most languages' map functions return transformed results.
    Why it's wrong
    For Each restores the original collection; collect results in a variable or use Parallel For Each or DataWeave map.

    Clue to watch for A Logger right after the scope.

  2. Failed record continues

    What candidates pick
    A record that failed in step 1 is processed by step 2.
    Why it looks right
    Batch seems to push every record through all steps.
    Why it's wrong
    The default NO_FAILURES policy skips failed records in later steps.

    Clue to watch for No accept policy is shown on step 2.

  3. Batch is synchronous

    What candidates pick
    Processors after the Batch Job see processed results.
    Why it looks right
    Most scopes complete before the next processor.
    Why it's wrong
    Batch Job runs asynchronously; the calling flow continues immediately.

    Clue to watch for A Logger placed after the Batch Job, not in On Complete.

  4. Max failed 0 is unlimited

    What candidates pick
    Reading 0 as no limit.
    Why it looks right
    Zero often means unlimited elsewhere.
    Why it's wrong
    In Mule batch, 0 allows no failures; -1 allows unlimited.

    Clue to watch for The job should keep going despite errors.

  5. Variables survive runs

    What candidates pick
    Reading a variable set in the previous Scheduler run.
    Why it looks right
    The flow is the same each time.
    Why it's wrong
    Each run is a new event, so the value must be stored in an Object Store.

    Clue to watch for Words like last run, resume or restart.

Answer framework

Choose the right record-processing construct for a scenario with these five steps.

  1. Estimate volume and timing: small collections that must finish before the response suit For Each; large asynchronous loads suit a Batch Job.
  2. If elements are independent and you need their results returned, consider Parallel For Each or a DataWeave map instead of For Each.
  3. For batch, define steps with accept policies and use a Batch Aggregator where the target supports bulk operations.
  4. For new rows or files appearing over time, use a connector listener with a watermark so each record is processed once.
  5. Store any state that must survive between executions, such as positions or tokens, in a persistent Object Store with a sensible default.

Practice question

A Batch Job has three steps with default settings and max failed records set to -1. Of 200 records, 15 raise errors in step 1. Step 3 has accept policy ONLY_FAILURES. How many records does each step process?

Want more like this? The Mule-Dev-201 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

Begin with For Each, because it is the simplest and the most tested for prediction. Build a flow that loops over an array, changes the payload inside the loop and accumulates a total in a variable, then log both after the scope. Repeat with Parallel For Each and note the different output.

Next, build a Batch Job that reads a CSV file with a few hundred lines, deliberately fails some records in the first step, and uses a second step with ONLY_FAILURES. Log the BatchJobResult in On Complete and change max failed records to see the job stop. Add a Batch Aggregator that writes records in groups.

Finish with a database table, an On Table Row listener using a timestamp watermark, and a Scheduler flow that stores a counter in the Object Store. Restart the application and confirm which values survive. Write a one-page comparison of the constructs from your own results; this table is the best revision tool for exam week.

FAQ

What is the weight of Processing Records on Mule-Dev-201?

Processing Records is 10% of the exam, about six of the 60 scored questions. It covers For Each, batch processing, DB listeners and persisting data between executions.

What is the payload after a For Each scope?

The original collection. For Each restores the payload it started with, while variable changes made inside the loop remain.

Does the flow wait for a Batch Job to finish?

No. The Batch Job runs asynchronously, so processors after it in the flow continue immediately. Use the On Complete phase for actions that depend on the outcome.

What does the default accept policy do?

NO_FAILURES means a step processes only records that have not failed in earlier steps. Use ONLY_FAILURES or ALL to change that.

How do watermarks avoid duplicate processing?

The listener records the highest watermark column value it has processed, stored in an object store, and later polls request only rows beyond that value.

When should I use the Object Store instead of a variable?

Whenever a value must outlive a single event, such as the last processed ID for a scheduled job or a token reused across requests.

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 7 knowledge

You have studied For Each, Batch Jobs, DB listeners, watermarks and the Object Store. Check whether you can predict record-processing outcomes in Mule-Dev-201 practice questions.

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

Keep going