Skip to content

Triggers

Every workflow needs exactly one active trigger, the node that decides when a run starts. Flero has six built-in triggers, plus a trigger for each enterprise connector. This page is a quick reference; for in-depth per-trigger guides, see Section 05: Triggers.

All triggers have no input port and one output port.

Built-in triggers

Start (manual)

What: The default trigger added to every new workflow. Fires when you click Run in the editor or start the workflow through the API.

The Start node's panel in the editor: the header with the node's icon and name, and its Settings tab.The Start node's panel in the editor: the header with the node's icon and name, and its Settings tab.

When to use: Testing, ad-hoc runs, workflows called by other systems through the API.

Configuration:

Field Notes
mode simple (default), generator, validator or setup
initialData An object the node emits as its output
includeMetadata Add run metadata to the output. Default on.
timestamp, generateId Add a timestamp and a generated id. Both default on.

See Manual & test runs.

API/Webhook Trigger

What: Gives the workflow an HTTPS URL. A request to that URL starts a run while the workflow is active.

The API/Webhook Trigger node's panel: the header, and the Settings tab with HTTP Method and Webhook Path.The API/Webhook Trigger node's panel: the header, and the Settings tab with HTTP Method and Webhook Path.

When to use: External services pushing events to you: Stripe, GitHub, Shopify, your own systems.

Configuration (all inside the webhook object):

Field Notes
path The path after the /trigger/ prefix. Copy the full URL from the inspector.
method GET, POST, PUT, PATCH or DELETE
secret Optional. When set, each request must carry an HMAC-SHA256 signature of the body in the X-Hub-Signature-256 or X-Webhook-Secret header.
responseMode immediate (default): reply at once. wait: reply when the run finishes.
payloadType auto (default), json or graphql

What downstream nodes read: the request body as {{ $trigger.payload.<field> }}, plus $trigger.headers (lower-case names), $trigger.query, $trigger.method and $trigger.path. The body is under payload, not body.

The signing secret is never copied into the node's output.

See Webhook trigger.

Scheduler

What: Starts a run on a timetable.

The Scheduler node's panel in the editor: the header with the node's icon and name, and its Settings tab.The Scheduler node's panel in the editor: the header with the node's icon and name, and its Settings tab.

When to use: Hourly syncs, daily reports, polling external systems on a cadence.

Configuration:

Field Notes
schedule.type interval, cron or once
schedule.interval Milliseconds between runs, for interval
schedule.cron Standard 5-field cron, for example 0 9 * * * for 9am daily
schedule.datetime ISO 8601 date and time, for once
schedule.timezone Time zone for the schedule
enabled Default on
maxExecutions Optional cap on the number of runs
payload An object whose keys appear on $trigger in every run

What downstream nodes read: $trigger.triggerTime, plus each key of payload, for example {{ $trigger.region }}.

See Schedule trigger.

Form Trigger

What: Publishes a public form with fields you define. Each submission starts a run.

The Form Trigger node's panel: the header, and the Settings tab with Form Title, Description and Form Fields with Add Field.The Form Trigger node's panel: the header, and the Settings tab with Form Title, Description and Form Fields with Add Field.

When to use: Request intake, feedback collection, lead capture.

Configuration: title, description, fields (required), submitButtonText (default Submit), successMessage, allowMultipleSubmissions (default off).

What downstream nodes read: each field as {{ $trigger.payload.<field> }}, plus $trigger.formTitle. File fields arrive as file references.

See Form trigger.

Chat

What: A chat box on the canvas. Each message starts a run.

The Chat node's panel in the editor: the header with the node's icon and name, and its Settings tab.The Chat node's panel in the editor: the header with the node's icon and name, and its Settings tab.

When to use: Multi-turn AI conversations, internal chatbots, support workflows.

Configuration: placeholder, multiline (default on), maxLength (default 1000), clearOnSend (default off), memoryKey (default default).

Output: message, timestamp, length, and conversationHistory once the conversation has earlier turns. An AI Agent placed after it uses that history automatically.

See Chat trigger.

MCP Trigger

What: Exposes the workflow as a named tool that Model Context Protocol (MCP) clients, such as AI assistants, can call.

The MCP Trigger node's panel in the editor: the header with the node's icon and name, and its Settings tab.The MCP Trigger node's panel in the editor: the header with the node's icon and name, and its Settings tab.

When to use: Workflows that external AI agents should be able to run.

Configuration:

Field Notes
toolName Required. The tool name clients see.
description Required. Tells the client's model what the tool does.
inputSchema JSON Schema for the tool's arguments
responseMode wait (default): return the run's result. immediate: acknowledge at once.

Output: The tool-call arguments.

Connector event triggers

Most enterprise connectors also have a trigger that fires on an event in the external service, such as a new Slack message or a new Granola note. Find each connector's triggers on its page in the Connector catalog.

A connector trigger is configured with the event to listen for and a credential, plus any options that event has. Triggers are delivered in one of two ways:

  • Push: the service sends each event to Flero as it happens. Lowest latency.
  • Polling: Flero checks the service on a schedule. Every enterprise connector supports polling.

Read a connector trigger's data from its node output, for example {{ $node["Slack Trigger"].output.<field> }}. Open the trigger's output after a test event to see its fields.

See Connector event triggers.

Platform triggers (admins)

Flero Event starts a run when a run in your Flero instance fails or completes. Flero Monitor watches a metric, such as failure rate or AI spend, and starts a run when it crosses a threshold. Both are admin-only. See Flero platform nodes.

Common patterns

  • One trigger per workflow. Need to react to two different events? Build two workflows, and share the common steps through a Sub-Workflow.
  • Manual, then scheduled. Keep the Start node while you build; replace it with a Scheduler when you set the workflow to active.
  • Webhook and duplicates. External services occasionally re-send events. Check the event id with Cache Storage before doing the real work.

Found something out of date? This page lives in the Flero docs content set.