Skip to main content
A connector event trigger starts a workflow when one of your connectors reports an event: a message posted in Slack, a payment succeeding in Stripe, an issue opened on GitHub. You choose the events, optionally filter them, and decide which parts of the event become the workflow’s input.

Example requests

  • “When someone posts a top-level message in #support, run the triage workflow with the message text and author.”
  • “When a Stripe payment of $100 or more succeeds, start the thank-you workflow.”
  • “When an issue is opened in our main repo, have the triage agent label it.”
  • “Whenever the Major app is mentioned in Slack, run the Q&A workflow.”

Supported connectors

Events are available for Slack, Stripe, GitHub, Gmail, Outlook, Google Calendar, Google Drive, and Attio, as well as many other connectors from the connector catalog. For example: The connector must already be connected and configured in your organization. Ask the Platform Agent which events a connector supports and what their payloads contain; it looks them up rather than guessing.

How a connector event trigger is defined

In the workflow editor, add a trigger, choose Connector event, pick the connected connector, and select events from the list. Some catalog connectors take one event per trigger and show extra Event options for it.

The event object

The filter and the input projection both see a single event object: The filter and projection can’t see workflow nodes or trigger, because they run before the workflow starts.

Filtering events

Put every deterministic condition, such as channel, amount, repository, or subtype, in options.filter instead of starting a run for every event and having an agent ignore the ones you don’t want. Events that don’t match never start a run. The filter is a boolean CEL expression. Guard optional fields with in or has() before reading them.
If you turn on Include bot messages for Slack, a workflow that posts to the same channel can trigger itself. Use a narrow filter that excludes the messages your workflow posts.

Shaping the input

By default, the whole event.json object becomes trigger.input, so a Slack message’s fields are available as trigger.input.text, trigger.input.channel, and so on. Set input to pass only what the workflow needs, or to rename fields. Each value is either a JSON literal or { "$expr": "..." }:
One input applies to every event the trigger subscribes to; there are no per-event overrides. {{ }} string interpolation isn’t supported here, so use $expr. If the workflow has an input_schema, the projected input is validated against it. When a filter or projection fails to evaluate, or the input fails validation, the run is recorded as failed with the reason, and no nodes run.

Publishing

Connector event subscriptions are created when you publish the workflow, and removed when a publish drops the trigger. Until then the trigger is inert. Use Run now with sample input to test the workflow first.

Next steps

Webhooks

Start a workflow from your own systems with an authenticated call.

State and input

Use trigger.input in your nodes.