- Introduction
- Getting started
- Process modeling with BPMN
- Process modeling with Case Management
- Designing a persistent case entity schema
- 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)
- Managing live case instances: pause, migrate, and retry
- Maestro case management component dictionary
- Process modeling with Flow
- Getting started
- Core concepts
- Node reference
- Build guides
- Best practices
- Reference
- Process implementation
- Debugging
- Simulating
- Publishing and upgrading agentic processes
- Common implementation scenarios
- Extracting and validating documents
- Process operations
- Process monitoring
- Process optimization
- Reference information
Maestro user guide
Once a Flow is deployed and running, the execution history gives you a complete view of every run — what triggered it, which path it took, what each node produced, and how long each step took.
Execution history
The execution history lists every run of the workflow, with the following information for each:
| Field | Description |
|---|---|
| Status | Succeeded, Failed, or Running. |
| Trigger | What started the run (manual, scheduled, or integration event). |
| Started at | Timestamp of when the run began. |
| Duration | Total time from start to completion. |
| Version | Which published version of the workflow ran. |
Selecting any row opens the execution trace for that run.
Execution trace
The execution trace is a step-by-step record of what happened during a specific run. For each node, it shows:
- Input values — what the node received.
- Output values — what the node produced.
- Status — whether the node succeeded or failed.
- Duration — how long the node took to execute.
- Error details — if the node failed, the error message, type, and stack trace.
The trace highlights the path actually taken through the workflow (for example, which branch a Decision node took), making it easy to understand the full execution without reading the workflow definition.
Filtering and searching runs
You can filter the execution history by:
- Status (succeeded, failed, running)
- Trigger type
- Date range
- Version number
Filters help narrow down failed runs after a deployment or compare behavior between two versions.
Failure monitoring
Failure notifications can come from workflow settings or from the workflow itself:
- The Alerts configuration in the workflow settings sends a notification to a specified email or Slack channel when a run reaches the
Failedstatus. - A notification step on a node's error path provides more control over the alert content.
Common mistakes
- Only checking failed runs — Slow successful runs can indicate performance problems. Duration trends matter even when the run succeeds.
- Ignoring version numbers in traces — The version number identifies which workflow version produced the trace. A rollback does not explain what went wrong if the failed run used an older version.