maestro
latest
false
Maestro user guide
- 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
- Maestro Automate
- Integrations
- Operating
- Monitoring
- Optimizing
- Reference information
Implement advanced BPMN patterns in Maestro, including asynchronous request-reply flows with event-based gateways, SLA windows, and timeout paths.
Request and wait handshake
Use when
- You send an asynchronous request and wait for a reply or a timeout.
- You need an SLA window and a clean outcome on either path.
Pattern in simple words
- Start.
- Send task: Send payment request.
- Event‑based gateway: wait for one of the following.
- Message event: Payment received. End Paid.
- Timer event: Fourteen days elapsed. Service task Close unpaid. End Closed unpaid.
Result
The process routes to one of two outcomes depending on which event occurs first: the paid path if a payment message is received, or the closed-unpaid path if the fourteen-day timer elapses.
Note:
This pattern cleanly models asynchronous communication with an SLA.
Other scenarios
- Finance: Invoice payment versus due‑date closure.
- Insurance: Claim evidence versus expiry.
- Retail: Supplier confirmation versus alternate sourcing.
- Public sector: Response received versus auto‑close.
- Manufacturing: Order acknowledgment versus cancel.
Wait for a specific message with a deadline
Use when
- A precise message is expected before continuing.
- A deadline must trigger escalation if the message does not arrive.
Pattern in simple words
- Start.
- Receive task: Await specialist report, with an interrupting boundary timer set to five days.
- On timer: User task Escalate. End Escalated.
- Normal path: Receive report. User task Review report. End Reviewed.
Result
The process completes on one of two paths: the reviewed path if the specialist report arrives within five days, or the escalated path if the boundary timer fires before the message is received.
Note:
The timer defines the SLA and triggers escalation.
Other scenarios
- Finance: Await audit response versus escalation.
- Healthcare: Await patient records versus escalation.
- Retail: Await vendor confirmation versus procurement escalation.
- Manufacturing: Await QA test results versus manager escalation.
- Public sector: Await citizen reply versus auto‑close.