UiPath Documentation
maestro
latest
false

Maestro user guide

Configuring a rework loop (re-entry)

Overview​

A rework loop (re-entry) sends a case back to a previously completed stage so that specific tasks can re-execute with corrected or additional data. Configure a re-entry rule on the originating stage that fires when rework is needed; the target stage re-activates and its tasks re-run by default. Use the per-task runOnlyOnce flag to opt specific tasks out of re-execution when their previous output is still valid.

Audience: Intermediate — Automation Developers and Business Architects working in Studio Web.

Prerequisites​

  • Access to Studio Web.
  • An existing case plan with at least two stages and tasks already configured.
  • A case entity [Coming Soon] (native Data Fabric entity, VDO, or trigger-supplied fields) with at least one field that captures a decision or validation outcome (for example, decision, docsComplete, or adjusterDecision).
  • Familiarity with stage rules (entry, complete, exit, and re-entry).

Step 1: identifying the rework scenario​

Before configuring rules, determine the rework path:

Defining which stage initiates the rework​

Identify the stage whose task output or decision triggers the need to return to an earlier stage. For example, a Review stage may determine that key incident reports are missing from the Intake stage.

Defining which stage receives the rework​

Identify the target stage that the case must re-enter. This is the stage where data correction or additional work takes place (for example, Intake).

Identifying the event and condition that trigger re-entry​

Re-entry rules follow the universal WHEN … IF … structure. Identify:

  • The WHEN event that signals rework is needed (for example, the claim officer review task completing, or a decision field changing on the case entity).
  • The IF condition over the case entity that must also hold (for example, decision == "Claim is missing key incident reports").

Identifying which tasks should NOT re-run​

By default, every task in a re-entered stage re-executes and produces fresh output. List only the tasks whose previous result is still valid and should be skipped on re-entry — these are the ones you will mark runOnlyOnce: true. For example, an initial extraction that does not depend on the corrected data may safely keep its previous output.

Step 2: confirm the target stage allows re-entry​

Opening the target stage settings​

In the Case Plan designer canvas, select the target stage (for example, Intake) to open its configuration panel.

Verifying the stage-level runOnlyOnce flag​

Re-entry is allowed by default. Confirm the stage's runOnlyOnce flag is false (the default).

Stage runOnlyOnceBehavior
false (default)The stage can be re-entered when its re-entry rule fires. Per-task runOnlyOnce flags control which tasks re-execute.
trueThe stage runs only once over the lifetime of the case and cannot be re-entered, regardless of any re-entry rule. Use this for one-time stages that should never re-process (for example, an Initial Intake that only runs once).

For a rework loop, leave the target stage at the default false.

Step 3: configure runOnlyOnce for individual tasks​

Selecting tasks that should be skipped on re-entry​

Within the target stage, open each task's configuration and set runOnlyOnce based on whether the task should produce fresh output on re-entry. Defaults are now flipped: tasks re-run by default; you opt them out individually.

TaskrunOnlyOnceBehavior on re-entry
Tasks that validate or check corrected datafalse (default)Re-execute on every re-entry; produce fresh output
Tasks whose previous output is still validtrueSkipped on re-entry; previous output retained

For example, in a HomeClaims Intake stage:

  • Incident reports Robot — leave runOnlyOnce: false (default). Must re-fetch missing reports.
  • Anomaly agent (Snowflake) — leave runOnlyOnce: false (default). Must re-check after new reports arrive.
  • Extract claim details (IXP) — set runOnlyOnce: true. Original extraction is still valid; skip on re-entry.

Verifying the required flag on each task​

Confirm that tasks marked as required: true align with the rework intent. The stage cannot complete until all required tasks finish — on re-entry, required tasks with runOnlyOnce: false must re-execute before the stage can complete again.

Step 4: configure the re-entry rule on the originating stage​

Opening the originating stage​

Select the stage that routes the case back (for example, Review).

Opening the re-entry rule panel​

In the stage configuration, select Re-entry rule.

Defining the re-entry rule​

Express the rule in WHEN / IF form. Use internal events (such as a task completing or a case-entity field change) for the WHEN, and a condition over the case entity for the IF.

Example — Review sends the case back to Intake when key reports are missing:

WHEN claim officer review task completes
  IF decision == "Claim is missing key incident reports"
WHEN claim officer review task completes
  IF decision == "Claim is missing key incident reports"

Example — Assessment sends the case back to Investigation for further review:

WHEN adjusterDecision field changes
  IF adjusterDecision == "investigate_more"
WHEN adjusterDecision field changes
  IF adjusterDecision == "investigate_more"

Selecting the tasks to re-run in the target stage​

In the re-entry configuration, confirm the per-task runOnlyOnce settings on the target stage (set in Step 3) reflect the rework intent. Tasks with runOnlyOnce: false re-execute; tasks with runOnlyOnce: true retain their previous output.

For the Review → Intake example, Extract claim details (IXP) stays skipped (runOnlyOnce: true), while Incident reports Robot and Anomaly agent (Snowflake) re-execute on re-entry.

Step 5: preventing infinite rework loops​

Adding a re-entry counter to the case entity (recommended)​

Add a field to the case entity [Coming Soon] (for example, reentryCount) that increments each time the case re-enters the target stage. Reference this counter in either the re-entry rule's IF clause or an exit rule that ends the loop after a defined number of iterations.

Configuring escalation after repeated re-entries​

Define an escalation rule, or rely on the Case Manager Agent fallback policy, to reassign the case to a senior worker or manager after a set number of re-entries (for example, escalate after two re-entries to the same stage).

Step 6: validating and publishing​

Validating the case plan​

Run the plan validation in Studio Web to confirm that all stage rules, re-entry rules, and task configurations are consistent.

Publishing and deploying​

Publish the case plan from Studio Web and deploy it to a folder. Activate the deployment so new case instances use the updated re-entry configuration.

Expected outcome​

When a case instance reaches the originating stage and the re-entry rule's WHEN event arrives and IF condition evaluates true:

  1. The case returns to the target stage.
  2. The target stage re-activates.
  3. Tasks with runOnlyOnce: false (the default) re-execute and produce fresh output.
  4. Tasks with runOnlyOnce: true are skipped; their previous output is retained.
  5. Once all required tasks complete, the target stage completes and the case advances forward through the normal flow.
  6. The full rework cycle is recorded in the case audit trail, including which tasks re-executed and the data changes that triggered the loop.

Use case example​

Scenario: Property insurance claims — Review discovers missing incident reports.

StageRoleAction
IntakeSystemExtracts claim details, looks up policy, runs incident report robot, runs anomaly agent.
ReviewClaim officerReviews claim data. Determines that key incident reports are missing. Sets decision to "Claim is missing key incident reports".
Re-entry → IntakeSystemRe-entry rule fires (WHEN the review task completes, IF decision == "Claim is missing key incident reports"). Incident reports Robot and Anomaly agent (Snowflake) re-execute with updated parameters. Extract claim details (IXP) is skipped because its runOnlyOnce is true.
Review (second pass)Claim officerReviews updated data. Reports are now present. Approves the claim. Case advances to Settlement.

Troubleshooting​

SymptomPossible causeResolution
Case does not return to the target stageTarget stage has runOnlyOnce: true (hard no-re-entry)Open the target stage settings and set runOnlyOnce to false.
All tasks re-execute when only some shouldAll tasks have the default runOnlyOnce: falseSet runOnlyOnce: true on tasks whose previous output should be retained.
Some tasks fail to re-executeThose tasks have runOnlyOnce: trueSet runOnlyOnce to false on tasks that must re-validate or re-process updated data.
Re-entry rule never firesThe case entity field referenced in the IF clause is not updated by any task in the originating stage, or the WHEN event never occursVerify that a task in the originating stage writes to the field and that the WHEN event is actually emitted (task completion, field change, etc.).
Case enters an infinite rework loopNo loop-prevention mechanism configuredAdd a re-entry counter field to the case entity [Coming Soon] and reference it in the re-entry rule's IF clause or in an exit rule that ends the loop after N iterations.
Re-entry rule does not appear in the stage configurationWrong stage selectedConfigure the re-entry rule on the originating stage (the stage that sends the case back), not on the target stage.

Limitations​

  • Re-entry applies only to previously completed stages. A case cannot re-enter a stage it has not yet visited.
  • runOnlyOnce defaults to false for tasks. Tasks without an explicit runOnlyOnce value re-execute on every re-entry.
  • Case user roles and access support for stage-aware permissions is not yet available.

Next steps​

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated