Triggering Workflows: Scheduled, Webhook, and Event

AI workflows can be started in three distinct ways: on a cron schedule, via an inbound signed webhook from an external system, or by reacting to an internal platform event. Each trigger mode suits a different operational pattern, and choosing the right one keeps your automation reliable, predictable, and easy to audit. For the workflow design layer that sits upstream of triggers, see Designing AI Workflows on a Visual Canvas and Executing and Monitoring Workflow Runs.

Why Trigger Design Matters

A workflow that runs on the wrong cadence, in response to the wrong signal, or without proper verification is not just inefficient — it creates noise in your audit trail, unpredictable costs, and potential security exposure. Before wiring up a trigger, the key question is: what exactly should cause this workflow to start, and how reliably can that signal be trusted?

The three trigger modes each address a different answer to that question. Scheduled triggers handle "run this periodically regardless of external input." Webhook triggers handle "start when an external system tells me to, but only if I can verify the message." Event triggers handle "start when something meaningful happens inside the platform itself." Manual triggers remain available for development and ad-hoc runs, but for production automation, one of the three automatic modes is the right foundation.

Scheduled Triggers: Running on a Cron

The simplest and most predictable trigger is a cron schedule. You set a cron expression on the workflow — standard five-field syntax covering minute, hour, day, month, and weekday — and the platform fires a run at each scheduled time.

Scheduled triggers are appropriate when the work is time-driven rather than event-driven: generating reports, reconciling data across systems, running maintenance sweeps on a nightly basis, or polling an external API on a fixed cadence. Because each run is initiated by the clock rather than an external signal, the workflow does not need to correlate what it does to anything that happened outside, which makes reasoning about its behavior straightforward.

A well-implemented scheduled trigger guarantees that exactly one run fires per interval in a multi-replica deployment, and that a workflow active before a restart resumes automatically without manual intervention. Cron expressions should be validated at save time, so a malformed expression is caught before it can produce an unexpected firing cadence.

One practical consideration: if a scheduled workflow run takes longer than the interval between fires, concurrent runs can accumulate. Designing scheduled workflows to complete well within their interval — and monitoring run duration in the run history — avoids this.

Webhook Triggers: External Systems Push Work In

A webhook trigger reverses the flow: instead of the platform polling or waiting for a schedule, an external system pushes a request to a unique URL that starts a workflow run. This is the right model when the timing of work is determined externally — a CI pipeline finishes deploying, a monitoring tool fires an alert, a payment completes, or a third-party integration signals that something changed.

The core security concern with any webhook is authenticity. A public URL can receive requests from anyone, so verifying that a request actually came from the expected sender is non-negotiable. For a full treatment of webhook signing and verification, see Webhook Security: Signing and Verifying Events. A webhook receiver should require HMAC-SHA256 signatures on every inbound request. When you configure a webhook trigger, the platform generates a unique, unguessable URL path and a signing secret. The external system computes a signature over the raw request body and a timestamp, and includes it in a request header. The receiver verifies the signature and rejects requests that do not match — invalid signatures produce a rejection before any workflow logic runs.

Replay protection is built into the verification step. The timestamp is validated against an allowed window; a request with a valid signature but a stale timestamp is rejected. This means an attacker who captures a legitimate signed request cannot replay it hours or days later to trigger unauthorized runs.

Delivery history should be recorded for every inbound call: the timestamp, signature validity, HTTP response, and whether a run was started. If an integration misbehaves or a delivery fails, you can inspect the delivery history to understand what arrived and when. You can also redeliver any past delivery — useful when recovering from a transient failure or debugging a new integration without needing the upstream system to re-fire.

The webhook secret is shown exactly once — at configure time or at rotation time. If you do not record it immediately, you rotate and get a new one. Rotation is a single action in the webhook management panel, and the delivery history makes the transition visible so you can confirm the external system has been updated.

The inbound receiver should apply per-IP rate limiting, so a misconfigured upstream system in a retry loop, or a probing attacker, cannot flood the endpoint and create a cascade of workflow runs.

Event Triggers: Reacting to Platform Activity

The third trigger mode lets a workflow respond to events that originate inside the platform. As things happen — a task completes, an agent encounters an error, a guardrail fires on a content policy violation — those events are available as triggers for other workflows.

A workflow configured as an event trigger specifies which event types it listens for, and optionally which agents those events must be associated with. When a matching event fires, the platform starts a workflow run and passes the event context into it, so subsequent nodes can inspect what happened and act accordingly.

Event triggers are well suited for response and remediation patterns. A guardrail violation on a specific agent could automatically start a review or escalation workflow. A task completion could trigger a downstream processing workflow without requiring any human to notice and click start. Because the trigger fires precisely when the matching event occurs — not on a clock, not on an external push — these automations are tightly coupled to the actual activity they respond to.

Comparing the Three Modes

The right trigger follows the shape of the work:

In practice, different workflows in the same organization typically use different trigger modes. A nightly cost summary is scheduled. An integration with an external ticketing system uses a webhook. An incident escalation workflow is event-driven. The trigger type is configured per workflow and does not affect how the workflow graph itself is designed.

Audit and Governance Across All Three

Each trigger mode is fully recorded. The trigger type, trigger source, and trigger time are written into every run record, so you always have a clear line from "this run happened" back to "this is what caused it." This attribution is available in the run history view and feeds into the audit log. For a broader view of the audit and compliance record that workflow runs contribute to, see audit trails that hold up.

The same spend controls and content guardrails that apply to manually started runs apply to automatically triggered runs. Automating the start of a workflow does not bypass the governance controls configured on it — budget caps, guardrail rules, and per-connection limits all remain in effect regardless of how a run is initiated. For how template-derived workflows participate in the same trigger system, see reusable workflow templates.

Common questions

Can a single workflow use more than one trigger type simultaneously? No. Each workflow has one active trigger type at a time. If you need the same workflow logic to start from both a schedule and an external webhook, the typical approach is to extract the core logic into a workflow that accepts a manual trigger, and create separate thin wrapper workflows for each trigger mode that call into it.

What happens to in-flight runs if a webhook secret is rotated? Runs that are already in progress are not affected by rotation — they complete normally. The rotation only affects new inbound requests. Deliveries that arrive after rotation using the old secret will fail signature verification and will not start new runs. The delivery history records these failures so you can confirm the external system has picked up the new secret.

How do I confirm a scheduled trigger is firing as expected? Each scheduled fire creates a run record with its trigger type, start time, and status. The run history in the workflow detail view shows whether runs are occurring at the expected intervals. If a scheduled run does not appear when expected, the run history makes it straightforward to distinguish between a missed fire and a run that started but failed early. See executing and monitoring workflow runs for more detail on reading run history and diagnosing trigger issues.

Do governance controls apply differently depending on the trigger type? No — governance is trigger-agnostic. Budget caps, content guardrails, per-connection limits, and approval gates all evaluate the same way whether a run was started manually, on a schedule, from a webhook push, or by a platform event. The trigger determines when and why a run starts; the governance layer determines what it is permitted to do once running. This is by design: automated triggers should not be a mechanism to bypass controls that would apply to a human-initiated run. For how spend controls work across all run types, see Budgets and Quotas: Preventing Runaway Agent Costs.

Connecting a workflow to a trigger is a configuration step, not an engineering project. Whether the signal comes from a clock, an external system, or a platform event, the trigger is verified, audited, and governed by the same controls as every other part of the workflow.