maestro

latest

false

Maestro user guide

Maestro case management component dictionary

	Case Management	BPMN Process
Content applies to	✅	❌

Overview

This reference document provides a factual breakdown of every component in Maestro Case Management. Use it as a dictionary to understand what each construct is, what properties it exposes, and how it relates to other constructs. For step-by-step guidance on building a case, refer to the Case Management tutorial.

Audience: Intermediate to Advanced — Automation Developers, Solution Architects, Technical Leads.

Product status: Preview.

How constructs relate

The following hierarchy shows how Maestro Case Management constructs fit together at design time and runtime.

Case (runtime instance, identified by Case Key)

DESIGN-TIME (Studio Web)
├── Case Manager (rules-based orchestration)
├── Case Personas (human roles, scoped to stages)
└── Case Plan (visual blueprint)
    ├── Event Triggers
    └── Stages + Stage Transitions (entry / complete / exit / re-entry)
        └── Tasks (Human, Agent, External Agent, RPA, Connector,
                    Agentic Process, Child Case, Wait Timer,
                    Wait Event, Ad-hoc)

CROSS-CUTTING
└── SLAs & Escalations (case-level and stage-level)

RUNTIME
├── Case App (business users — view, track, act)
└── Case Instance Management (operators — pause, resume, cancel, migrate, retry)
Case (runtime instance, identified by Case Key)

DESIGN-TIME (Studio Web)
├── Case Manager (rules-based orchestration)
├── Case Personas (human roles, scoped to stages)
└── Case Plan (visual blueprint)
    ├── Event Triggers
    └── Stages + Stage Transitions (entry / complete / exit / re-entry)
        └── Tasks (Human, Agent, External Agent, RPA, Connector,
                    Agentic Process, Child Case, Wait Timer,
                    Wait Event, Ad-hoc)

CROSS-CUTTING
└── SLAs & Escalations (case-level and stage-level)

RUNTIME
├── Case App (business users — view, track, act)
└── Case Instance Management (operators — pause, resume, cancel, migrate, retry)

Case key

The case key uniquely identifies a case instance across Maestro and external systems.

Key type	Description	Example
System key	Auto-generated by Maestro on case creation. Uses a configurable constant prefix.	`HC-1234`, `CLM-00891`
External (customer-defined) key	An upstream ID passed at case creation so the same real-world case is recognized across tools.	CRM case number, policy number, ERP order ID

Configure the case key when you create the case type in Studio Web. Select Constant Prefix key and provide a prefix string (for example, HO-). Maestro appends an auto-incremented identifier.

Use an external key when the case originates in another system (CRM, ERP, ticketing tool) and humans or integrations must correlate the case across tools without maintaining a separate mapping table.

Stages

A stage is a named phase in the case lifecycle (for example, Intake, Review, Settlement). Stages are the columns on the case plan canvas, each grouping related tasks that execute during that phase.

Stage types

Maestro supports two categories of stages:

Type	Description	Example
Primary stage	Represents the happy-path progression of a case.	Intake, Review, Settlement, Closure
Secondary stage	Represents exception paths branching off the primary flow. May return to origin or be terminal.	Pending with Customer, Denied, Withdrawn

Stage properties

Property	Description
`name`	Display name (for example, "Submitted", "Manager Review").
`required`	Whether the case must pass through this stage to complete. If `true` and the entry rule never evaluates to true, the case blocks. If `false`, the case can complete even if this stage was never entered.
`entryRule`	Condition that must be true for this stage to activate.
`completeRule`	Condition that determines when this stage is finished. Often "when all required tasks are done."
`exitRule`	Early exit condition. When met, the stage terminates immediately even if the complete rule has not been satisfied.
`reentryCondition`	Condition that allows a case to return to this stage for rework.
`autoComplete`	Automatically mark the stage complete when all required tasks finish.
`runOnReentry`	Controls whether the stage resets and re-executes when re-entered after previous completion. Default: `false`.
`sla`	Time limit for stage completion (business days or calendar days).

Required vs optional stages

	Required stage	Optional stage
Case completion	Case cannot complete until this stage has been completed.	Case can complete even if this stage was never entered.
When to use	Core phases every case must pass through (for example, "Submitted", "Payment").	Conditional phases that only apply sometimes (for example, "VP Review" for high-value cases).
Behavior if entry rule is never true	Case blocks.	Case skips the stage.

Secondary stage exit behaviors

Behavior	Description	Example
Return to origin	When all tasks in the secondary stage complete, the case routes back to the stage that sent it.	A Pending with Customer stage returns to Review after documents are received.
Terminal	When all tasks in the secondary stage complete, the case ends.	A Denied stage closes the case after sending a denial packet.
Connector-driven entry	The secondary stage activates when an external connector event arrives, regardless of which primary stage the case occupies.	A Withdrawn stage enters automatically when a Microsoft Teams channel message is posted.

Run on re-entry behavior (stages)

`runOnReentry`	Behavior	Use case
`true`	Stage resets to Active. All tasks are re-evaluated — required tasks with `runOnReentry: true` re-execute.	Correction loop: "Submitted" stage needs to re-validate after rejection.
`false` (default)	Stage remains Completed. Re-entry is a no-op. Previous results are preserved.	One-time stages that should only run once (for example, "Initial Intake").

Task types

A task is a discrete unit of work inside a stage. Tasks are the atomic building blocks of case processing.

Supported task types

Task type	Description	Example use
Human (Action)	Assigned to a person via a persona. Opens a form or work item in the Case App queue. The human reviews, makes a decision, and submits.	Manager approval, adjuster review, finance sign-off.
Agent (UiPath)	A UiPath AI agent performs autonomous reasoning over data. Useful for judgment-based work.	Categorize expenses, flag anomalies, draft a customer response.
External Agent	Invokes a third-party AI agent outside UiPath (for example, via A2A protocol or API). Enables multi-vendor agent orchestration.	Call an external compliance agent from a partner system.
RPA Workflow	Triggers a UiPath robot to perform UI automation in legacy systems where no API exists.	Process reimbursement in a legacy payroll system, enter data into a mainframe.
Connector (Integration Services)	Calls an external system via a pre-built or custom connector. Executes synchronously or asynchronously with callback.	Look up policy details in Salesforce, run a credit check.
API workflow	Calls an external system via a custom API request. Executes synchronously or asynchronously with callback.	Call scheduling software to gain available slots, create new ticket.
Maestro Agentic Process	Invokes a Maestro agentic process (BPMN-based) as a task. The process runs with its own orchestration and returns a result.	Multi-step audit workflow with its own agent logic.
Case Management (Child Case)	Spawns another case definition as a child case. The child has its own lifecycle, stages, and tasks, linked to the parent via `caseID`.	A claims case spawns a child fraud investigation case.
Wait for Timer	Pauses execution until a specified duration elapses or a target date/time is reached.	Wait 48 hours before sending a follow-up notice.
Wait for Connector Event	Pauses execution until an external event arrives via a connector (webhook, message queue, system callback).	Wait for a payment confirmation from the banking system.

Ad-hoc tasks

Ad-hoc tasks are created at runtime by a human user when an unplanned task is needed that is not part of the original case plan. For example: Human case processoradds a "Request additional documentation" task during investigation.

Task properties

Property	Description
`name`	Display name.
`type`	One of: `human`, `agent`, `externalAgent`, `rpa`, `connector`, `agenticProcess`, `childCase`, `waitTimer`, `waitEvent`, `adhoc`.
`required`	Whether the parent stage must wait for this task to complete. If `true`, the stage cannot complete until the task is done. If `false`, the stage can complete even if this task has not finished.
`entryRule`	Condition that determines when this task starts. Enables conditional execution (for example, run only when `amount >= 1000`).
`completeRule`	Condition that determines when this task is considered done.
`exitRule`	Early exit condition for the task. When met, the task terminates immediately.
`runOnReentry`	Whether this task resets and re-executes if the parent stage is re-entered. Default: `false`.
`linkedWorkflow`	Reference to the implementing workflow, form, or agent configuration.
`assignment`	For human tasks: the persona, user, team, or routing rule that determines the assignee.
`sla`	For human tasks: due time, warning thresholds, and escalation recipients.

Required vs optional tasks

	Required task	Optional task
Stage completion	Parent stage cannot complete until this task is done.	Parent stage can complete even if this task is not done.
When to use	Must-do work (for example, "Manager Approval" in review stage).	Nice-to-have work (for example, "Flag Anomalies" — helpful but stage can proceed without it).
Auto-complete interaction	If the stage has `autoComplete: true`, completion waits for all required tasks.	Not considered in auto-completion check.

Run on re-entry behavior (tasks)

`runOnReentry`	Behavior	Use case
`true`	Task resets and re-executes, producing fresh output.	Validation tasks that must re-check corrected data.
`false` (default)	Task retains its previous result; does not re-execute.	Tasks whose output is still valid (for example, "Categorize Expenses" does not need to re-run).

Conditions

Conditions (also called transition conditions or rules) control lifecycle movement at both the stage and task levels. Maestro supports four condition types.

Entry condition

Evaluates against case fields. When the condition becomes true, the stage or task transitions from Available to Active.

Scope	Description	Example
Stage	Gates the start of a stage.	`vars.validationPassed == true` activates the Review stage.
Task	Enables conditional execution of a task within an active stage.	Run only when `amount >= 1000`.

Complete condition

Defines when a stage or task is finished under normal circumstances. For stages, this is often "when all required tasks are done." For tasks, it is typically "when the task produces output."

Scope	Description	Example
Stage	Marks a stage as done when the work is finished.	All required tasks have completed.
Task	Marks a task as done when its output is received.	`taskOutput.status != "error"`.

Exit condition (early exit)

An early exit mechanism. When the condition is met, the stage or task terminates immediately — even if the complete rule has not been satisfied. Exit conditions act as circuit breakers for abnormal or conditional scenarios.

Scope	Description	Example
Stage	Terminates a stage before all tasks finish.	`vars.action == "Reject"` terminates the Review stage, and the case moves to the Denied secondary stage.
Task	Stops a task before its normal completion.	`policyValid == false` stops further validation.

Note:

Do not confuse exit conditions with complete conditions. A complete condition fires when the work is done (normal finish). An exit condition fires when something changes that means the work should stop (early bailout). Both result in the Case Manager evaluating which stage to enter next.

Re-entry condition

Allows a case to return to a previously completed stage in a structured and auditable way. This capability enables non-linear case flows for controlled rework loops.

Scope	Description	Example
Stage	Returns the case to a prior stage when additional work is needed.	`vars.decision == "Claim is missing key incident reports"` returns the case from Review to Intake.

When re-entry occurs, configure which specific tasks to re-run within the target stage. Tasks with runOnReentry: true re-execute; tasks with runOnReentry: false retain their previous results.

Skip rule

An optional condition on a stage that bypasses the stage entirely when the condition is true.

Scope	Description	Example
Stage	Skips a stage when it is not applicable.	`riskScore < 30` skips the detailed investigation stage.

SLAs and escalations

Define SLAs (Service Level Agreements) and escalation rules at case and stage levels to enforce time-based expectations.

SLA levels

Level	Description	Example
Case-level SLA	Overall target for case resolution from creation to close.	Resolve claim within 48 business hours.
Stage-level SLA	Localized due time for a specific stage.	Complete FNOL Intake within 4 hours; Manager Review within 24 hours.

SLA states

State	Description
On-track	Case or stage is within the allotted time.
At-risk	SLA is approaching its limit (for example, at 80% of the allotted time).
Breached	SLA time limit has been exceeded.

SLA states surface as badges in case lists and detail views within the Case App.

Escalation rules

Trigger	Description	Typical action
At-risk escalation	Triggered when the SLA is approaching its limit.	Notify the case owner and supervisor.
Breach escalation	Triggered when the SLA is exceeded.	Reassign to a senior worker, notify management, create a priority flag.

Pause and resume

SLA timers can be paused when the case is waiting on external input (for example, a customer response) and resumed when the case becomes actionable again.

Case manager

The Case Manager orchestrates the case lifecycle using deterministic rules . Rules handle known, predictable patterns.

How the case manager works

Event received — a trigger fires and creates (or updates) a case instance.
Rule evaluation — the Case Manager evaluates entry conditions for all stages to determine which stages should become active.
Task activation — within active stages, entry conditions for tasks are evaluated to start the appropriate work.
Monitoring — as tasks complete, the Case Manager evaluates complete conditions (normal finish) and exit conditions (early bailout).
Case completion — when all required stages are complete, the case closes.

Rules scope

Rules (entry, complete, exit) can be defined at three levels:

Case level — govern the overall case lifecycle (when is the case complete?).
Stage level — control stage transitions (when does this stage activate, complete, or bail out?).
Task level — control individual task activation and completion.

Case manager configuration

Setting	Description
`model`	The LLM powering the agent (for example, `claude-3.5-sonnet`, `gpt-4o`).
`userPrompt`	System instructions that define the agent's role, policies, and constraints.
`tools`	Actions the agent can take (for example, move stage, escalate, send notification).
`context`	Memory for the agent, built automatically based on execution history. The agent accumulates context from prior decisions, task outcomes, and case state changes.

Note:

If the Case Manager cannot make a decision — due to ambiguous data, conflicting rules, or a scenario outside its policies — it automatically escalates to a human.

Case personas

Case personas define the human participant roles that interact with a case throughout its lifecycle. Personas control who can view and act within each stage. Personas are for people, not agents. AI agents are configured separately as task types.

Built-in persona types

Persona	Role	Typical capabilities
Case Creator	Initiates the case — submits the original trigger (portal form, API call, email).	Create new case instances; view status of cases they created; limited ability to update open cases before the first stage completes.
Case Owner	Accountable for the case end-to-end. Often assigned at creation.	Full case visibility across all stages; can reassign tasks, override decisions (within policy), reopen closed cases.
Case Worker	Executes assigned human tasks within specific stages.	View and complete tasks in their queue (My Work); update case fields scoped to their task's output; stage-level visibility only.
Supervisor / Manager	Oversees a team's portfolio of cases; handles escalations.	View all cases assigned to their team; reassign tasks; approve escalations; pause/resume SLA timers; access dashboards and KPIs.
Subject Matter Expert (SME)	Consulted on specific cases or stages requiring specialist knowledge.	Read access to relevant case data; can complete SME-designated tasks; does not have broad case management permissions.

Beyond the built-in types, case developers can create custom personas — give the persona a name and scope it to one or more specific stages. Custom personas do not automatically appear everywhere.

Stage-level persona permissions

For every stage in the case plan, define two access dimensions for each persona:

View access — which personas can see this stage's data, tasks, and history in the Case App.
Act access — which personas can take actions within this stage (complete tasks, add notes, reassign, escalate, trigger transitions).

Tasks inherit the stage's persona settings by default but can further narrow the permitted roles.

Assignment strategies

Strategy	How it works	When to use
Static	A fixed user, team, or group is assigned at design time.	Tasks that always go to the same team (for example, Finance Review always goes to the Finance group).
Dynamic	A rule or expression resolves the assignee at runtime.	Workload-balanced assignment, territory/region routing, skill-based routing.

Note:

Case user roles and access support is not yet available.

Case app

The Case App is the business user-facing runtime application where case workers, managers, and other personas view, track, and act on live case instances.

What business users see

View	Description
Case list / queue	Filterable view of all case instances, with status, priority, and SLA indicators (on-track, at-risk, breached).
Case detail view	Current stage, task statuses, timeline of events, and full audit trail.
Task inbox (My Work)	Pending human tasks awaiting action: forms, approvals, reviews.
Actions	Contextual actions based on role and current stage: complete, reopen, escalate, reassign, add notes, request info, create ad-hoc tasks.
Dashboards	Aggregate KPIs: throughput, resolution time, SLA compliance, bottleneck identification.

Configuration

Configure the Case App from the Configure case app option in Case Management settings within Studio Web. Configurable elements include:

Case title — the display title shown in the case list and detail views.
Case details — the fields and layout displayed on the case detail view.

Case app vs UiPath apps

Aspect	Case App	UiPath Apps
Purpose	Opinionated, case-centric workspace — lists, details, tasks, incidents, and SLA views for case operations.	General-purpose low-code builder for fully custom or composite business apps.
When to use	Rapid case operations with out-of-the-box views.	Bespoke UI requirements beyond case operations.

Human task forms continue to be built with Action apps and are referenced by case tasks.

Case instance management

Case Instance Management is the operations console where process operators monitor and manage all running case instances.

Operator actions

Action	Description
Pause	Temporarily halt a running case instance. SLA timers pause. No tasks are activated until resumed.
Resume	Restart a paused case. SLA timers resume from where they stopped.
Cancel	Terminate a case instance permanently. All running tasks are stopped.
Migrate	Move a live case instance to a newer version of the case plan (for example, after a bug fix or plan update), preserving its current state and data.
Retry	Re-execute the failed task or transition to recover from transient errors.
Update Variables	Modify case variable values on a running instance to unblock processing.

Case incidents

When a case instance enters an error state (for example, a task fails, an integration times out, or the case gets stuck), it becomes a case incident. Process operators use Migrate, Retry, and Update Variables to resolve incidents.

Event triggers

Event triggers are the entry points into a case. They define what starts a case and where the data comes from. A single case plan can have multiple triggers.

Trigger type	Source	Example
Form / Portal	User submits through a web form.	Employee submits an expense report through a portal.
Email	Incoming email parsed for data.	Forwarded receipt email creates a new case.
API	External system calls the case creation endpoint.	ERP system triggers a claim case on a policy event.
Queue / Event	Message from a queue or event stream.	Kafka topic publishes a new order event.
Scheduled	Time-based trigger.	Daily check creates follow-up cases for stale items.
Data Fabric entity event	A row-level event on a Data Fabric entity or VDO (for example, "Row created").	A new row in the Home Claims entity triggers a case.
Wait for connector	A connector event from Integration Service (for example, Microsoft Teams channel message posted).	A Teams message triggers a Withdrawn stage entry.

Each trigger maps incoming data to case fields.

Billing and consumables

No separate billing for Maestro Case Management
Work that runs inside a case consumes the native consumables of the task types used:
- AI agents
- Maestro Agentic Processes (BPMN Processes)
- RPA workflows
- API workflows / integrations

Glossary

Term	Definition
Ad-hoc Task	A task created at runtime (not part of the original case plan) by the a human user when an unplanned action is needed.
Case	A runtime instance representing a real-world business situation that needs resolution (a claim, dispute, investigation, exception). Identified by a case key.
Case App	The business user-facing application where people view, track, and act on live case instances.
Case Comments	Out-of-the-box object storing notes, annotations, and communication threads, linked via the immutable `caseID`.
Case Documents	Out-of-the-box object storing files and attachments related to the case, linked via the immutable `caseID`.
Case Incident	An error state on a case instance (task failure, integration timeout, stuck case) that requires operator intervention.
Case Instance Management	Operations console in Maestro where process operators view all running case instances and perform actions: pause, resume, cancel, migrate, retry.
Case Key	Unique identifier for a case instance. Can be system-generated or an external/customer-defined value.
Case Manager	Orchestration engine that uses deterministic rules.
Case Persona	A human participant role scoped to specific stages. Built-in types: Case Creator, Case Owner, Case Worker, Supervisor/Manager, SME. Developers can create custom personas.
Case Plan	Visual blueprint defining stages, tasks, triggers, and rules. Describes the possible paths, not a fixed sequence. Designed in Studio Web.
Complete Condition	Condition that determines when a stage or task is finished under normal circumstances.
Entry Condition	Condition that must be true for a stage or task to activate.
Event Trigger	Entry point that creates or influences a case instance. Maps incoming data to case fields.
Exit Condition	Early exit condition. When met, the stage or task terminates immediately even if the complete rule has not been satisfied.
Primary Stage	A stage on the happy-path progression of a case.
Re-entry Condition	Condition that allows a case to return to a previously completed stage for rework.
Required	Flag on stages and tasks. Required stages must be completed for the case to close. Required tasks must complete for the stage to complete.
Run on Re-entry	Flag that controls whether a stage or task resets and re-executes when re-entered after previous completion.
Secondary Stage	A stage representing an exception path branching off the primary flow. May return to origin or be terminal.
Skip Rule	Optional condition on a stage that bypasses the stage entirely when the condition is true.
SLA	Service Level Agreement. Time-based expectation for case or stage completion, with states: on-track, at-risk, breached.
Stage	A named phase in the case lifecycle that groups related tasks. Governed by entry, complete, exit, and re-entry conditions.
Task	A discrete unit of work within a stage. Ten types: Human, Agent, External Agent, RPA, Connector, Agentic Process, Child Case, Wait Timer, Wait Event, Ad-hoc.

Case Management tutorial — end-to-end walkthrough of building a case from scratch.
Case Plan Designer in Studio Web — reference for the visual design canvas.
Action apps documentation — how to build forms for human tasks referenced by case tasks.

On this page

Overview
How constructs relate
Case key
Stages
Stage types
Stage properties
Required vs optional stages
Secondary stage exit behaviors
Run on re-entry behavior (stages)
Task types
Supported task types
Ad-hoc tasks
Task properties
Required vs optional tasks
Run on re-entry behavior (tasks)
Conditions
Entry condition
Complete condition
Exit condition (early exit)
Re-entry condition
Skip rule
SLAs and escalations
SLA levels
SLA states
Escalation rules
Pause and resume
Case manager
How the case manager works
Rules scope
Case manager configuration
Case personas
Built-in persona types
Stage-level persona permissions
Assignment strategies
Case app
What business users see
Configuration
Case app vs UiPath apps
Case instance management
Operator actions
Case incidents
Event triggers
Billing and consumables
Glossary
Related resources

Was this page helpful?

PREVIOUSManaging live case instances: pause, migrate, and retry

NEXTUnderstanding Process implementation

Maestro user guide

Overview​

How constructs relate​

Case key​

Stages​

Stage types​

Stage properties​

Required vs optional stages​

Secondary stage exit behaviors​

Run on re-entry behavior (stages)​

Task types​

Supported task types​

Ad-hoc tasks​

Task properties​

Required vs optional tasks​

Run on re-entry behavior (tasks)​

Conditions​

Entry condition​

Complete condition​

Exit condition (early exit)​

Re-entry condition​

Skip rule​

SLAs and escalations​

SLA levels​

SLA states​

Escalation rules​

Pause and resume​

Case manager​

How the case manager works​

Rules scope​

Case manager configuration​

Case personas​

Built-in persona types​

Stage-level persona permissions​

Assignment strategies​

Case app​

What business users see​

Configuration​

Case app vs UiPath apps​

Case instance management​

Operator actions​

Case incidents​

Event triggers​

Billing and consumables​

Glossary​

Related resources​

Was this page helpful?

Overview

How constructs relate

Case key

Stages

Stage types

Stage properties

Required vs optional stages

Secondary stage exit behaviors

Run on re-entry behavior (stages)

Task types

Supported task types

Ad-hoc tasks

Task properties

Required vs optional tasks

Run on re-entry behavior (tasks)

Conditions

Entry condition

Complete condition

Exit condition (early exit)

Re-entry condition

Skip rule

SLAs and escalations

SLA levels

SLA states

Escalation rules

Pause and resume

Case manager

How the case manager works

Rules scope

Case manager configuration

Case personas

Built-in persona types

Stage-level persona permissions

Assignment strategies

Case app

What business users see

Configuration

Case app vs UiPath apps

Case instance management

Operator actions

Case incidents

Event triggers

Billing and consumables

Glossary

Related resources