- 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
What it is
A trigger defines how a process starts. Every process requires at least one trigger, and new processes include a Manual Trigger by default.
Trigger types
Flow supports the following trigger types:
| Type | Description | Use case |
|---|---|---|
| Manual Trigger | Starts the process on demand when you select Debug | Testing, debugging, and ad-hoc execution |
| Scheduled Trigger | Runs the process on a recurring schedule, defined as an interval or a cron expression | Periodic data syncs, daily reports, recurring cleanup tasks |
| Connector-based triggers | Starts the process when an event occurs in an Integration Service connector (for example, new email received or form submitted) | Event-driven automation that reacts to external systems in real time |
Trigger placement
Triggers are added from the node palette in the bottom toolbar. You can't add a trigger from a node's output handle.
After a trigger is added, it appears on the canvas as a circular node. Its output handle connects to the first node in the process to complete the entry point.
Every trigger must connect to at least one downstream node. Flow displays a warning if a trigger has no outgoing connection.
Trigger inputs
Input variables are owned by their trigger, not by the process. Each trigger defines its own set of inputs, and those inputs are only populated when that specific trigger fires.
To reference a trigger's input in a downstream node, use the syntax:
$vars.<triggerName>.output.<inputName>
$vars.<triggerName>.output.<inputName>
For example, if a Manual Trigger named manualTrigger1 defines an input called userId:
$vars.manualTrigger1.output.userId
$vars.manualTrigger1.output.userId
Trigger inputs are configured from the Variables panel. Each input belongs under the trigger that owns it and has its own name and type.
After an input is defined, it appears under that trigger in the Variables panel and is accessible downstream as $vars.<triggerName>.output.<inputName>.
Refer to Variables and data flow for more on expression syntax and how data moves between nodes.
Multiple triggers
A process can have more than one trigger. Each trigger acts as a separate entry point. When any trigger fires, it starts an independent execution of the process.
This is useful when the same logic needs to run in response to different events. For example, a process might have both a Scheduled Trigger for nightly batch runs and a connector-based trigger that reacts to incoming requests during the day.
Each trigger owns its own inputs. Downstream nodes reference the specific trigger that started the current execution. If your process has a Manual Trigger named manualTrigger1 and a Scheduled Trigger named scheduledTrigger1, each has its own $vars.<triggerName>.output namespace.
Related pages
- Variables and data flow — expression syntax, node output, trigger input references
- The Canvas — node palette, properties panel, bottom toolbar
- Error handling — handling failures in nodes downstream of a trigger