- 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
Output mocking lets you define a fixed output for any node during a test run, without actually executing the node's real action. This is useful for testing downstream logic when the real action is slow, expensive, or requires external dependencies that are not available during a Debug run.
How mocking works
When you enable a mock on a node, Flow skips the node's actual execution during the test run and injects the mocked output values directly. All downstream nodes receive the mocked values as if the node had run normally.
Mocks apply only during test runs. They are never active in published, production workflows.
Setting up a mock
- Select the node you want to mock on the canvas.
- In the configuration panel, open the Mock output section.
- Enable the mock toggle.
- Enter the output values you want to inject. Use valid JSON that matches the node's output schema.
Result: The node is mocked. On the next test run, Flow skips its real execution and injects your values downstream instead.
Common use cases
- Human Task nodes — Simulate an approved or rejected response without waiting for a real approver.
- HTTP Request nodes — Simulate a specific API response, including error responses, to test your error handling paths.
- Agent nodes — Simulate the output of an AI agent to test how your workflow handles different agent responses.
- Subflow nodes — Simulate the output of a child workflow to test the parent workflow in isolation.
Resetting mocks
To run a workflow with real execution, disable the mock toggle on each mocked node before running the test. Mocks are not saved as part of the published workflow definition.
Common mistakes
- Publishing with a mock still enabled — Mocks are automatically disabled on publish, so this isn't a production risk. But if you forget to disable a mock before your final test run, you're testing against fake data, not real execution.
- Entering mock data that doesn't match the node's output schema — If the mocked JSON doesn't match the shape the downstream nodes expect, you'll get runtime errors downstream that wouldn't happen with real data. Match the schema exactly.
- Mocking too many nodes at once — If you mock five nodes to test the sixth, a passing test doesn't tell you much. Mock only the nodes that block you from testing the part you actually care about.