Maestro user guide

• Design robust case plans that account for the non-linear nature of real-world work.
• Avoid common pitfalls such as rigid stage sequencing, unclear field ownership, or missing re-entry logic.
• Communicate across roles — from the developer who models stages in Studio Web to the case worker who completes tasks in the Case App.

Out-of-the-box data objects​

How data reaches the entity​

Why a central entity matters​

• Task independence — Tasks do not need to know about each other. Each task reads from and writes to the entity through input/output mappings.
• Orchestration context — The Case Manager evaluates transition rules against entity fields. When a task writes adjusterDecision = "approve" back to the entity, downstream entry rules that reference adjusterDecision immediately evaluate.
• Audit trail — Every change to the entity is tracked with who, when, and what changed.
• Single source of truth — There is no ambiguity about the current state of the case for any participant or system.

The write-back pattern​

1. A task reads specific fields from the Case Entity via input mapping.
2. The task performs its work (validation, agent reasoning, human review, RPA extraction).
3. The task writes its results back to the Case Entity via output mapping.
4. Updated entity values cause transition rules to re-evaluate, potentially activating the next stage or task.

Task A writes → Case Entity updates → Rules evaluate → Next stage activates
Task A writes → Case Entity updates → Rules evaluate → Next stage activates

• Event Triggers — the events that create or influence a case instance (described in Layer 1).
• Stages — the named phases of the case.
• Tasks — the work items within each stage.
• Rules — the WHEN/IF/ACTION definitions that govern entry, completion, exit, and re-entry of stages and tasks.

Stages​

• Entry rule — when the stage activates. Carries an interrupting toggle that controls take-over behavior. Defaults: primary stages = false (parallel); secondary stages = true (take-over).
• Complete rule — the normal finish (for example, when required tasks are done). Carries an action (complete/exit the case, wait for manual selection, return-to-origin).
• Exit rule — an early bailout when continued processing is pointless. Carries the same action options as the complete rule.
• Re-entry rule — how rework returns the case to a previously completed stage.
• Stage SLA and escalations — due time, warning thresholds, and escalation recipients.

Tasks​

• Sequential — the task runs in a defined order within the stage. Sequences can include parallel branches that fan out and rejoin.
• Event-driven — the task has an entry rule and fires whenever the event makes the rule evaluate true. Can fire multiple times if the event recurs.
• Ad-hoc — the task is defined in the case plan but only starts when a user manually triggers it at runtime.

• Inputs / Outputs — mapped to and from the Case Entity [Coming Soon] .
• Required flag — determines whether the parent stage must wait for this task.
• Entry rule — required for event-driven tasks; optional for sequential and ad-hoc tasks (where it acts as a guard).
• Run only once — if true, the task is skipped on stage re-entry and its previous output is retained; if false (default), the task re-executes on every re-entry, producing fresh output.
• Assignment and SLA — for human actions, who should do the work and when it is due.

Rules​

• WHEN — the event that triggers evaluation. Events come in two kinds:
  • Internal events emitted by the case lifecycle itself — CaseCreated, StageEntered, StageCompleted, StageExited, TaskCompleted, CaseSlaAtRisk, CaseSlaBreached, StageSlaAtRisk, StageSlaBreached, and changes to Case Entity fields written by tasks.
  • External events arriving from outside the case — Integration Service connector events (webhooks, queue messages), timer firings, child case completion or exit, and direct API calls to the case.
• IF (optional) — a condition over the Case Entity that must also be true for the rule to take effect. If omitted, the rule fires on every matching WHEN event.
• ACTION — what the rule does when it fires (start a stage, complete a stage, exit a stage, complete the case, etc.).

1. Rules (primary) — Deterministic CMMN rules defined in the Case Plan. For every decision point, the Case Manager first evaluates the applicable rules. If a rule resolves the decision, it is taken. This keeps the high-volume happy paths predictable, auditable, and cheap.
2. Agent reasoning (fallback) — When no rule covers the situation (a gap, an exception, or a judgment call), the Case Manager Agent reasons over the Case Entity, the case plan, and configured policies to pick the next action. This lets cases keep moving without escalating to a human for every uncovered branch.

How the Case Manager processes an event​

1. Event received — a trigger fires, a task completes, a Case Entity field changes, a timer or connector event arrives, or a stage transitions.
2. Rule evaluation — the Case Manager evaluates all applicable case-, stage-, and task-level rules whose WHEN matches the event and whose IF condition (if present) holds. Matching rule actions are applied (activate a stage, complete a stage, exit a stage, etc.).
3. Agent fallback — for decisions not covered by a deterministic rule, the Case Manager Agent reasons over case state and policies to choose the next action.
4. State update — stages and tasks transition; the Case Entity is updated; new events may be emitted, triggering the next cycle.
5. Case completion — when a case-level Case complete or Case exit rule fires (or the agent decides the case is done), the case closes.

Rules and the agent work together​

Case Manager Agent configuration​

• A model (the LLM powering the agent).
• A user prompt (policies, constraints, and behavioral instructions).
• Tools (actions the agent can take, such as moving a stage, escalating, or updating the entity).
• Context (automatically accumulated from execution history, task outcomes, and entity changes).
• An escalation policy (conditions under which the agent escalates to a human instead of acting autonomously).

Case app (for business users)​

• Case list — A filterable view of all case instances with status, priority, and SLA indicators (on-track, at-risk, breached).
• Case detail view — The current stage, Case Entity data, task statuses, timeline of events, and full audit trail.
• Task inbox (My Work) — Pending human tasks awaiting action: forms, approvals, reviews.
• Quick actions — Contextual actions based on role and current stage: complete, reopen, reassign, escalate, add notes.

Case instance management (for operators)​

1. Event trigger fires. A new row is created in a Home Claims Data Fabric entity. The trigger maps entity fields (policy number, claimant name, loss description) into the Case Entity [Coming Soon] and creates a case instance with key HO-1234.

2. Case Manager activates the first stage. The entry rule for Intake evaluates to true (WHEN CaseCreated event arrives). The stage becomes active.

3. Tasks execute within Intake. An extraction task (AI Agent) processes claim details. A lookup task (Execute Connector) verifies the policy. An anomaly-detection agent checks historical claims. Each task writes results back to the Case Entity.

4. Intake completes, Review activates. When all required Intake tasks finish and validationPassed == true, the Intake Complete rule fires. The Case Manager evaluates entry rules for the next stages and activates Review.

5. Review tasks run. A coverage-check connector, a human claim-officer verification task, and an auditor agent produce outputs. The claim officer writes decision = "Approve" back to the entity.

6. Conditional routing at Review. The Review Complete and Exit rules evaluate the decision field. If "Approve", the Complete rule fires and the case moves to Settlement. If "Reject", the Exit rule fires and routes the case into the secondary Denied stage. If "Claim is missing key incident reports", the Re-entry rule sends the case back to Intake, re-running only the tasks whose runOnlyOnce is false (for example, the Incident Reports Robot and Anomaly Agent).

7. Settlement tasks execute. A fulfilment process, a settlement process, and a communications agent handle payout and notifications. Each writes back to the entity.

8. Case closes. When all required stages complete, the case reaches a terminal state. The full audit trail — every task execution, entity change, decision, and timestamp — is preserved.

9. Throughout the lifecycle, a case worker views assigned tasks in the Case App's My Work inbox. A case manager monitors the portfolio, reassigns tasks, and handles escalations. An operator watches for incidents in the Case Instance Management console.

• At-risk — SLA is approaching its limit. Notify the case owner and supervisor.
• Breached — SLA is exceeded. Reassign to a senior worker or escalate to management.
• Pause / Resume — SLA timers pause when the case is waiting on external input and resume when it becomes actionable again.

• Core concepts in Maestro Case — Reference definitions for case keys, entities, stages, tasks, rules, and SLAs.
• Case Plan Designer overview — How to model case plans in Studio Web.
• Configuring stage rules — Detailed guidance on entry, complete, exit, and re-entry rules.
• Case App overview — What business users see and how to configure the Case App layout.
• Case Instance Management — Operator actions for monitoring, incident resolution, and live migration.