UiPath Documentation
maestro
latest
false

Maestro user guide

Exit Rules and early stage termination

Audience: Intermediate — Automation Developers, Business Architects, Solution Architects

Overview​

In Maestro Case, every stage can end in one of two ways: it finishes its work normally through a Complete Rule, or it terminates early through an Exit Rule. Exit Rules act as circuit breakers — they cut a stage short the moment conditions change in a way that makes continued processing pointless or incorrect. Understanding the difference between these two mechanisms is essential for designing case plans that handle both happy paths and exception paths cleanly.

The stage lifecycle in brief​

Before examining how stages end, it helps to understand how they begin and progress. Each stage in a case plan is governed by a set of rule types that control its lifecycle:

Rule TypeQuestion It Answers
Entry RuleWhen should this stage activate?
Complete RuleWhen is this stage done?
Exit RuleWhen should this stage bail out early?
Re-entry RuleWhen should a case return here for rework?

A stage transitions from Available to Active when its Entry Rule evaluates to true. Once active, the stage's tasks begin executing according to their own entry rules (for event-driven tasks) or their position in the sequence. The stage remains active until either the Complete Rule or the Exit Rule fires — whichever comes first. Both outcomes cause the Case Manager to evaluate which stage to enter next, based on the rule's action.

What is a complete rule?​

A Complete Rule defines the normal finish condition for a stage. It fires when the stage has accomplished what it was designed to do. In most cases, the Complete Rule evaluates whether all required tasks have finished and produced valid output.

Think of the Complete Rule as the answer to: "Has this stage done its job?"

A typical Complete Rule looks like:

WHEN event("AllRequiredTasksDone")
WHEN event("AllRequiredTasksDone")

Or, for stages where a specific data outcome matters:

WHEN event("AdjusterDecisionMade")
  IF adjusterDecision != null
WHEN event("AdjusterDecisionMade")
  IF adjusterDecision != null

When a Complete Rule fires:

  • The stage transitions to a Completed state.
  • All task outputs are preserved in the Case Entity [Coming Soon].
  • The Case Manager applies the rule's action (advance per the next stage's entry rule, wait for manual selection, return-to-origin, or complete the case) and evaluates entry rules for subsequent stages.

Complete Rules represent the expected, designed outcome. The stage ran, the work happened, and the result is ready for whatever comes next.

What is an exit rule — the "circuit breaker"?​

An Exit Rule defines an early termination condition. It fires when something changes mid-stage that makes continued processing unnecessary, invalid, or counterproductive. When an Exit Rule triggers, the stage terminates immediately — running tasks stop, and the stage ends without satisfying its Complete Rule.

Think of the Exit Rule as the answer to: "Has something changed that means this stage should stop right now?"

The term "circuit breaker" captures this behavior precisely. In electrical engineering, a circuit breaker cuts power the instant it detects a dangerous condition — it does not wait for the circuit to finish its intended work. Exit Rules operate the same way: they interrupt a stage the moment a condition makes further processing wrong or wasteful.

A typical Exit Rule looks like:

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false
WHEN PolicyCheckCompleted event arrives
  IF policyValid == false

The WHEN clause can listen to either an internal event emitted by the case lifecycle (a task completing, a stage entering or exiting, an entity field change, an SLA going at-risk or breached) or an external event arriving from outside the case (a connector webhook, a timer firing, a child case completing, a direct API call). Exit Rules most commonly listen for internal task-completion events and the Case Entity field updates those tasks produce.

When an Exit Rule fires:

  • The stage terminates immediately, regardless of task progress.
  • Running tasks within the stage stop. Task outputs that have already been written to the Case Entity are preserved; any task that was in flight but had not yet written its output is recorded as Terminated and its partial work is discarded.
  • The Case Manager applies the rule's action (the same set as Complete: complete or exit the case, wait for manual selection, return-to-origin) and evaluates what to do next, just as it would after a normal completion.
  • The case does not necessarily end — it may route to a different stage, a secondary (exception) path, or the Case Manager Agent may decide the next action when no deterministic rule covers the situation.
  • The early exit is recorded in the case audit trail: the firing rule, the WHEN event that triggered it, the Case Entity values that satisfied the IF clause, the action taken, and the list of terminated tasks. The entry surfaces in the Case App timeline and in Case Instance Management.

How they differ​

The following comparison summarizes the fundamental distinction between Complete Rules and Exit Rules:

DimensionComplete RuleExit Rule
PurposeMarks the stage as finished when work is doneTerminates the stage early when conditions change
When it firesAfter required tasks complete and produce valid outputAs soon as a monitored condition becomes true, regardless of task progress
Relationship to tasksWaits for tasks to finishDoes not wait — interrupts running tasks
RepresentsThe normal, expected outcomeAn abnormal, conditional, or shortcut scenario
Stage state afterCompletedTerminated (early exit)
What happens nextCase Manager evaluates the next stage based on case dataCase Manager evaluates the next stage based on case data

Both paths — normal completion and early exit — lead to the same downstream behavior: the Case Manager reads the current Case Entity state and determines which stage to activate next. The difference is in why and when the stage ended, not in what happens afterward.

Note:

A single stage can have both a Complete Rule and an Exit Rule defined. At runtime, whichever condition becomes true first determines how the stage ends. They are not mutually exclusive in configuration — they are mutually exclusive in execution.

Why exit rules matter​

Without Exit Rules, case plans would need to handle every exception after a stage finishes all its work. This leads to several problems:

  • Wasted effort. Tasks continue running even when their results are irrelevant. For example, an investigation stage might spend hours dispatching a field inspector and analyzing photos for a claim whose policy has already been found invalid.
  • Delayed routing. The case cannot move to the correct exception path until the current stage fully completes, adding unnecessary latency to the overall case resolution.
  • Complex Complete Rules. Without a separate exit mechanism, the Complete Rule must account for both normal and abnormal finishes, making it harder to read, maintain, and debug.

Exit Rules solve these problems by separating the "done" signal from the "stop" signal. The Complete Rule stays simple — it describes success. The Exit Rule describes the conditions under which success is no longer possible or relevant.

Required stages and early exit​

A stage marked required must end in a Completed state for the case to satisfy a normal Case Complete rule. When an Exit Rule fires on a required stage, the stage ends in a Terminated state — not Completed — so it does not contribute to the "all required stages done" check.

This means an Exit Rule on a required stage should always pair with one of the following, otherwise the case will get stuck (required stage never completed, no downstream stage configured to pick it up):

PairingHow it worksWhen to use
Downstream stage takes overA separate stage's entry rule fires on the same event (often a secondary stage with interrupting = true) and drives the case toward closure. The Exit Rule just stops the wasted work.Most exception paths — for example, Denied, Fraud Hold, Withdrawn. The case continues, it just continues somewhere else.
Exit Rule action = Exit the caseThe Exit Rule's action terminates the case directly. No downstream stage is required.The early exit means the case has no meaningful continuation — for example, the policy is invalid, the claimant withdrew, or fraud has been confirmed.

For an optional stage, an early exit is fine on its own — the case can still complete without it.

Common exit rule patterns​

The knowledge base and L300 course material describe several recurring patterns where Exit Rules provide significant value.

Pattern 1: invalid precondition​

A task early in the stage discovers that a foundational precondition is false. There is no reason for the remaining tasks to execute.

Example — FNOL Intake stage:

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false
  ACTION Exit the case
WHEN PolicyCheckCompleted event arrives
  IF policyValid == false
  ACTION Exit the case

If the claimant's policy is invalid, there is no point extracting claim details or creating a claim number. The Exit Rule terminates the Intake stage immediately. Because the policy is invalid the case has no meaningful continuation, so the action is Exit the case — the case ends and a downstream closing hook can send the denial notification.

Pattern 2: mid-stage rejection​

A decision-making task within the stage produces a negative outcome that invalidates the purpose of the stage.

Example — Assessment stage:

WHEN AdjusterDecisionMade event arrives
  IF adjusterDecision == "deny"
  ACTION advance
WHEN AdjusterDecisionMade event arrives
  IF adjusterDecision == "deny"
  ACTION advance

If the adjuster denies the claim during the Assessment stage, the Settlement stage should never activate. The Exit Rule terminates Assessment early. The action is advance — the same event reaches the Denied secondary stage's entry rule (which fires on adjusterDecision == "deny", interrupting = true by default), and Denied takes over to send notification and close the case.

Pattern 3: fraud or risk detection​

An automated check discovers a high-severity risk signal that demands immediate escalation, bypassing normal stage completion.

Example — Investigation stage:

WHEN FraudCheckCompleted event arrives
  IF fraudScore > 0.9
  ACTION advance
WHEN FraudCheckCompleted event arrives
  IF fraudScore > 0.9
  ACTION advance

A fraud score above the threshold means the case should leave the Investigation stage immediately. The action is advance — a Fraud Hold secondary stage (interrupting = true) activates on the same event and takes over the case. Waiting for the field inspection or police report retrieval to complete would waste time and resources.

Pattern 4: fast-track shortcut​

Not all early exits are negative. An Exit Rule can also accelerate processing when data shows that remaining tasks are unnecessary.

Example — Review stage:

WHEN ValidationComplete event arrives
  IF totalAmount < 500 AND validationResult.status == "pass"
  ACTION advance
WHEN ValidationComplete event arrives
  IF totalAmount < 500 AND validationResult.status == "pass"
  ACTION advance

A low-value, clean submission does not need the full review stage. The Exit Rule short-circuits the stage; the action is advance so the case proceeds directly to the next phase in the primary flow. This pattern reduces cycle time for straightforward cases without removing the Review stage from the plan for cases that need it.

Pattern 5: external system failure​

An integration task fails in a way that means the stage cannot produce a meaningful result.

Example — Settlement stage:

WHEN PaymentProcessed event arrives
  IF paymentFailed == true
  ACTION Wait for manual selection
WHEN PaymentProcessed event arrives
  IF paymentFailed == true
  ACTION Wait for manual selection

If the payment system rejects the transaction, continuing with claimant notification (which would reference a successful payment) is incorrect. The Exit Rule stops the stage; the action is Wait for manual selection so a process operator can pick the recovery path — a payment retry stage, an alternative payout channel, or a manual resolution path.

How exit rules interact with the case manager​

When an Exit Rule fires, the Case Manager takes over. Its behavior depends on the same mechanism it uses after any stage ends: it applies the Exit Rule's action, evaluates the current state of the Case Entity [Coming Soon], and determines which stage to enter next.

This means Exit Rules do not need to specify where the case goes — they only specify when the stage stops (and the action describes the high-level intent: advance, wait for user, return-to-origin, or end the case). The routing logic lives in the Entry Rules of downstream stages and in the Case Manager's orchestration logic (deterministic rules first, Case Manager Agent reasoning as fallback).

For example, when the Assessment stage exits early due to a denial:

  1. The Assessment stage's Exit Rule fires — WHEN the AdjusterDecisionMade event arrives IF adjusterDecision == "deny". The stage terminates and running tasks stop.
  2. The same AdjusterDecisionMade event reaches every other rule whose WHEN matches it. The Denied secondary stage's Entry Rule — WHEN AdjusterDecisionMade arrives IF adjusterDecision == "deny" — evaluates true and the stage activates. Because Denied is a secondary stage, its entry rule defaults to interrupting = true, so any other active stages are exited.
  3. The Denied stage runs its tasks (send denial packet, generate audit report). When all required tasks complete, the case closes via a Case Complete rule.

This separation of concerns — Exit Rules define when to stop, Entry Rules define when to start — keeps the case plan modular and maintainable. Each stage only needs to know its own rules, not the full routing graph. The Case Manager never polls the Case Entity: every rule is event-driven and evaluates only when its WHEN event arrives.

Note:

The Case Manager Agent serves as a fallback when no deterministic rule covers the situation after an early exit. If the Exit Rule fires under unexpected circumstances and no downstream Entry Rule matches, the agent reasons over the Case Entity data and configured policies to decide the next action — or escalates to a human if it cannot determine the correct path.

Note:

Exit Rules are stage-only. Tasks have only an Entry rule — there is no task-level Complete or Exit rule. A task's completion is determined by the underlying work (form submitted, agent finished, RPA returned, etc.). To stop work mid-stage, define the Exit Rule on the stage itself; it terminates all running tasks within the stage.

Design guidelines​

When incorporating Exit Rules into a case plan, consider the following principles:

  • Keep Complete Rules simple. A Complete Rule should describe the happy path: "all required tasks are done" or "the expected decision has been made." Do not embed exception logic in the Complete Rule.
  • Use Exit Rules for the exceptional. Reserve Exit Rules for conditions that genuinely invalidate continued processing. Not every conditional branch needs an Exit Rule — some conditions are better handled by the Case Manager's routing logic after normal completion.
  • Monitor upstream outputs. Exit Rules typically evaluate fields written by tasks earlier in the stage. Design your Case Entity schema so that the fields an Exit Rule monitors are written by specific, identifiable tasks.
  • Pair Exit Rules with downstream Entry Rules. An Exit Rule stops processing; a downstream Entry Rule catches the case and routes it to the correct path. Design these in pairs to avoid cases that terminate a stage but have nowhere to go.
  • Document the intent. Exit Rules are powerful but can be surprising to someone reading a case plan for the first time. Use clear naming and comments to indicate why each Exit Rule exists and what scenario it handles.

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated