- Introduction
- Getting started
- Building with Maestro BPMN
- Understanding Maestro BPMN modeling
- Opening the modeling canvas
- Modeling your process
- Aligning and connecting BPMN elements
- Autopilot for Maestro (Preview)
- Process Repository
- Implementing a simple BPMN process
- Implementing a complex BPMN process
- Debugging
- Simulating
- Evaluations (Preview)
- Common implementation scenarios
- Building with Maestro Case
- Introduction to Maestro Case
- Maestro BPMN vs. Maestro Case: when to use case management
- The Maestro Case lifecycle: from event trigger to app experience
- Build your first case with Maestro Case
- Build a Maestro Case with a coding agent (preview)
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Exit rules and early stage termination
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Configuring and testing the Case Manager Agent (preview)
- Case Manager input and output contract
- Maestro Case component dictionary
- Building with Maestro Flow
- Integrations
- Operating
- Understanding operations
- Working with instance management
- Custom instance ID
- Instance throttling
- Publishing and upgrading agentic processes
- Managing live case instances: pause, migrate, and retry
- Variables and element filtering (BPMN)
- Monitoring
- Optimizing
- Reference information
Manage live Maestro Case instances by pausing cases, retrying failed tasks, and migrating running cases to updated case plan versions.
| Maestro Case | Maestro BPMN | Maestro Flow | |
|---|---|---|---|
| Content applies to | ✅ | ❌ | ❌ |
Overview
Case Instance Management in Maestro provides process operators with an operations console to monitor and intervene on running case instances. Use it to pause cases awaiting external input, retry failed tasks after transient errors, and migrate live cases to updated versions of a case plan — all without losing case state or data.
Audience: Intermediate — Process Operators, Incident Managers
Prerequisites
- Access to Maestro with the Case Instance Management console.
- At least one deployed and active case plan with running case instances.
- Appropriate operator permissions to perform lifecycle actions (Pause, Resume, Migrate, Retry) on case instances.
- Familiarity with core case management concepts such as stages, tasks, SLAs, and case plans.
Step 1: pausing and resuming a case instance
Pause a running case instance when it requires an external hold — for example, while waiting for a customer response or a compliance review. Pausing halts all SLA timers and prevents new tasks from activating until you resume the case.
Pausing a case instance
-
Open the Case Instance Management console in Maestro.
-
Locate the case instance you want to pause. Use filters such as case key, status, or stage to narrow the list.
-
Select the target case instance to open its detail view.
-
Select Pause.
-
Confirm the pause action when prompted.
The case instance status changes to Paused. SLA timers stop, and no new tasks activate until the case is resumed.
Resuming a paused case instance
- In the Case Instance Management console, filter by status Paused to find the target case.
- Select the paused case instance to open its detail view.
- Select Resume.
- Confirm the resume action when prompted.
The case instance status returns to Running. SLA timers resume from where they stopped, and task activation continues based on current stage rules.
- SLA timers pause and resume in sync with the case lifecycle. Time spent in a paused state does not count toward SLA calculations.
- No tasks activate while a case is paused. Any tasks that were already running at the time of the pause remain in their current state.
Step 2: resolving case incidents with retry
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. Use the Retry action to re-execute the failed task or transition and recover from transient errors.
Identifying case incidents
-
Open the Case Instance Management console.
-
Filter case instances by Faulted status or look for incident indicators in the case list.
-
Select the faulted case instance to open its detail view. Review the incident details, including which task or transition failed and the associated error message.
Retrying a failed task or transition
- From the case incident detail view, identify the specific failed task or transition.
- Select Retry on the failed item.
- Confirm the retry action when prompted.
Maestro re-executes the failed task or transition. If the transient error is resolved (for example, an external service is back online), the task completes successfully and the case continues its normal lifecycle.
- Retry re-executes only the specific failed task or transition. It does not restart the entire stage or case.
- If a retry fails again, the case instance remains in the faulted state. Investigate the root cause before retrying again or consider migrating the case to an updated case plan version with a fix.
Step 3: migrating a case instance to a newer case plan version
When you publish a bug fix or update to a case plan, use Migrate to move live case instances from the old version to the new one. Migration preserves the current state and data of each case instance.
Publishing the updated case plan
- In Studio Web, make the necessary changes to the case plan (for example, fix a task configuration, update a stage rule, or add a new stage).
- Validate the updated case plan.
- Publish the new version from Studio Web and deploy it to the target folder.
Migrating live case instances
-
Open the Case Instance Management console in Maestro.
-
Locate the case instance you want to migrate. This is particularly useful for instances in a faulted state caused by a plan-level issue.
-
Select the case instance to open its detail view.
-
Select Migrate.
-
Choose the target case plan version from the list of available deployed versions.
-
Confirm the migration when prompted.
Maestro moves the case instance to the selected version of the case plan. The case retains its current stage, data, and audit history.
- Migration preserves the case instance's current state and data. The case continues from its current point in the lifecycle under the new plan version.
- Use migration to resolve case incidents caused by plan-level defects (for example, a misconfigured task or incorrect stage rule) after deploying a corrected version.
- Verify the target case plan version is deployed and active in the same folder before initiating a migration.
Expected outcome
After completing these actions, you can:
- Pause and resume case instances on demand, with SLA timers that accurately reflect only active processing time.
- Retry failed tasks to recover case instances from transient errors without restarting the entire case.
- Migrate live case instances to updated case plan versions, resolving plan-level defects while preserving case state, data, and audit history.
All operator interventions are recorded in the case audit trail for compliance and traceability.
Troubleshooting
| Symptom | Possible Cause | Resolution |
|---|---|---|
| Retry fails repeatedly | The root cause is not a transient error (for example, a misconfigured task or incorrect input mapping). | Investigate the error details in the incident view. Fix the case plan in Studio Web, publish a new version, and use Migrate instead. |
| Migrate option not available | No newer case plan version is deployed in the target folder. | Publish and deploy the updated case plan version from Studio Web before attempting migration. |
| SLA shows incorrect time after resume | Expected behavior verification — SLA timers exclude paused duration. | Confirm that the SLA calculation reflects only active (non-paused) time. This is the intended behavior. |
| Case stuck after resume | The case may depend on an external event or condition that has not yet been met. | Review the current stage's entry and complete rules. Verify that the required conditions or external events are in place for the case to proceed. |
| Process still shows as Running in Orchestrator after the case is completed | Known behavior — Orchestrator keeps the underlying process instance running so that Reopen remains available for the case. The process state in Orchestrator is tracked separately from the case state in the Case App. | Check the case status in the Case App, not the process status in Orchestrator — the Case App reflects the actual case state. If you don't intend to reopen the case, you can manually stop the process instance in Orchestrator; doing so disables Reopen for that case. |
Limitations
- Retry re-executes only the specific failed task or transition — it does not roll back or restart the entire stage.
- Migration moves a case to a new plan version but does not retroactively re-execute previously completed stages or tasks under the new plan logic.
Next steps
- Learn how to design case plans with stages and transitions in Studio Web.
- Explore the Case App for business user views of case lists, task inboxes, and case details.
- Review SLAs and escalation rules to configure time-based expectations for case and stage completion.
- Overview
- Prerequisites
- Step 1: pausing and resuming a case instance
- Pausing a case instance
- Resuming a paused case instance
- Step 2: resolving case incidents with retry
- Identifying case incidents
- Retrying a failed task or transition
- Step 3: migrating a case instance to a newer case plan version
- Publishing the updated case plan
- Migrating live case instances
- Expected outcome
- Troubleshooting
- Limitations
- Next steps