Triggers v2

A trigger defines how a published Workflow receives a new activation. The runtime classifies the trigger from a root Workflow Step whose selected Node Method has the Trigger type.

The Runtime has four published trigger kinds:

Trigger kind	Starts when	Definition
HTTP	A request matches an Environment hostname, HTTP Method, and relative route.	One supported HTTP receive Step and one matching root-level HTTP respond Step.
MCP	An MCP client calls the published tool name.	One `McpReceive` Step and one root-level `McpRespond` Step.
Schedule	A Daily, Weekly, Monthly, or Cron schedule becomes due.	One Schedule trigger Step.
Listener	A supported listener Node receives an event or batch.	One trigger Step not owned by HTTP, MCP, or Schedule.

A Workflow without a trigger remains callable through supported non-trigger paths such as designer Debug or as a Sub-Workflow.

Receive, work, respond

Put the trigger Step at the Workflow root so its Returns establish the input available to later Steps.

HTTP and MCP are request/response interfaces. They require exactly one matching respond Step at the Workflow root. A respond Step nested inside If, ForEach, TryCatch, or another container is invalid, and a Workflow cannot publish multiple matching respond Steps.

Use control flow to build response values, then map the final result into the respond Step. During designer Debug, Flowgear exposes the mapped respond values in the result so you can inspect them without an external HTTP or MCP client.

Schedules and continuous listeners do not have a corresponding respond Step. It's generally not necessary to declare Workflow Returns on these Workflows, unless you specifically want certain Returns to be recorded in the Workflow logs.

Publish and status

Triggers becomes callable only when the Workflow is Enabled. Disabling prevents new trigger starts without deleting the published revision or trigger definition. It can take a few minutes for an trigger Workflow to activate due to internal refresh process.

HTTP triggers

The current HTTP receive Methods support Stream, JSON object, and JSON array request bodies. They expose the request URI, headers, route/query Parameters, and the selected body shape.

The HTTP Method must be one of GET, HEAD, POST, PUT, DELETE, OPTIONS, PATCH, TRACE, or CONNECT, using uppercase. The URI template must:

Start with one /.
Be relative, not a complete URL.
Contain no whitespace or fragment.
Use balanced, non-empty route placeholders such as {orderId}.
Optionally include a query string.

The Environment hostname with which the Workflow was invoked causes it to be mapped to a Site and Environment. API-key authorization must agree with that Environment and allow the Workflow. If more than one enabled published Workflow claims the same Method and route, invocation fails with a route conflict.

HTTP respond Methods can return a Stream, JSON object, or JSON array with a status code and headers. Flowgear manages CORS from the Environment's AllowedOrigins; do not add platform-managed Access-Control-* headers in the Workflow.

MCP triggers

McpReceive publishes the configured ToolName and supplies a typed Arguments object to the Workflow. The tool name must be valid and unique among published tools in the same Environment.

McpRespond maps StructuredContent and IsError. Flowgear converts the result into the MCP tool-result envelope. A non-object result is wrapped in an object, and IsError: true reports a tool execution error.

Tool discovery also depends on the Workflow MCP feature, Environment hostname, Workflow status, API-key assignments, and the calling user's effective access.

Schedule triggers

The Schedule Node exposes Daily, Weekly, Monthly, and Cron trigger Methods.

Daily, Weekly, and Monthly schedules use a Site-local time window and interval. Weekly schedules add days of the week. Monthly schedules add days of the month and months. Cron schedules use a six-field expression with seconds precision.

The scheduler runs only latest published, enabled definitions. Its coordinator operates on the primary active Cluster and dispatches the Workflow to its configured runtime Cluster. Schedule polling means a due start is not a hard real-time guarantee.

Use SingleInstance when overlapping runs of the same scheduled Workflow must be prevented. Confirm schedule details and time-zone behavior against the current designer before publishing.

Listener triggers

A listener trigger is a Node Method that remains active and waits for an external event, such as a supported email, file, or database notification source. The exact Parameters and Returns are specific to the Node.

The listener service maintains enabled published listener Workflows on the primary active Cluster.

Validation

Compilation or publish can reject a trigger Workflow when it has:

No classifiable trigger or an ambiguous trigger shape.
An invalid HTTP Method or route template.
A missing, nested, or duplicate HTTP/MCP respond Step.
An invalid or conflicting MCP tool name.
An invalid schedule definition with no next occurrence.
A Node, Connection, or Cluster incompatibility.

Resolve the diagnostic path in Problems, save or promote the corrected revision, and verify status in the target Environment.