Triggers

Start a run on a schedule, message, file, chain or sensor.

A Trigger is the inbound half of a transport: an external or temporal event that starts a transport run. It is the opposite of an Alert, which is outbound — a finished run notifying a channel. The two are never the same thing.

Triggers are managed on the Triggers page and attached to a transport. A transport can carry several triggers at once (for example a nightly schedule and a file-arrival watcher), and it can still be run manually with Run now. A transport with no trigger is manual-only.

Every trigger funnels through one shared launch path, so the same concurrency, deduplication, and run-topology rules apply no matter what fired it.

Trigger kinds

Schedule

Runs the transport on a time cadence. This replaces the old Schedules page.

• Interval — every fixed interval (e.g. every 15 minutes), either on a fixed clock or measured from the end of the previous run.
• Cron — a cron expression in a chosen timezone (recognised; calendar cron firing is being rolled out).
• A concurrency policy decides what happens when a run is still going when the next one is due: skip, queue, or cancel the previous.

Web request

Starts a run from an HTTP call. Two independent flavours:

• Signed URL — an anonymous, unguessable URL you can paste into another system. Generate it once (it is shown only once), copy it, and any GET/POST to it starts a run. The URL can be revoked or expired; a bad or revoked token returns 404 and reveals nothing.
• API gate — when enabled, an authenticated API caller (Bearer token) is authorised to POST /run and GET /status for that transport.

Messaging

Starts a run when a matching message arrives on a broker. The trigger references a Trigger-capable Connection (see Connections) for the broker credentials, and a match rule decides which messages fire it (every message, a subject pattern, a JSON field equals, or a header equals).

• Apache Kafka, Azure Event Hubs, and RabbitMQ are pull consumers — the server subscribes while the trigger is enabled.
• Azure Event Grid is push — instead of a broker connection you generate a webhook URL and register it as an Event Grid subscription. The CloudEvents validation handshake is handled for you.

File arrival

Starts a run when a file lands.

• Cloud — an Azure Blob BlobCreated event via Event Grid. You give the container and an optional blob-path pattern, generate the webhook URL, and register it as an Event Grid subscription.
• On-prem — the owning client watches a folder on its machine (optionally recursing, filtered by a wildcard). Once a file has been stable for a short settle window, the client asks the server to start the run. No public endpoint is involved; the watch config is pulled down over the client's heartbeat, so it stays strictly client-initiated.

Chaining

Starts this transport when another transport's run finishes. You pick the source transport and the outcome to chain on (on success, on failure, or any outcome). Chains are validated at save time so they cannot form a loop.

Data sensor

Polls a query and starts a run when a condition is met — for example "fire when this inbox table has unprocessed rows".

• You give a probe query, a condition (the query returns rows, or returns no rows), and a poll interval (minimum 30 seconds).
• Cloud-direct sources are polled by the server; on-prem (client-placed) sources are polled by the owning client. Relational sources only.

Validity window

Every trigger can carry an optional start and end time. Outside that window the trigger does not fire, which is handy for one-off campaigns or for staging a trigger before it goes live.

How a fired run reaches the client

When a trigger fires, the server resolves the run's topology from the transport's source and sink placements and queues the work. A client-placed run is picked up by the owning client on its next long poll — within a second or two — with the server never opening a connection to the client. See Architecture.

Roles

Creating and editing triggers requires the Admin role. Read-only users can see them but not change them. See Authentication & Roles.