Schedules & Triggers

An automation can start in three ways: you run it by hand, it runs on a schedule, or an external system calls its webhook. Schedules and webhooks only fire while the automation is Active. This page covers each trigger, the Draft, Active, and Archived lifecycle, and how to follow a run once it starts.

Draft, Active, and Archived

Every automation has a status, shown as a badge next to its name in the editor. Click the badge to change it.

The status menu offers the moves the automation can make:

• Draft: Activate or Archive
• Active: Deactivate (back to Draft) or Archive
• Archived: Restore to Draft

Deactivating stops new scheduled executions; runs already in progress complete. Deactivating and archiving ask for confirmation.

Saving never changes the status. Activating is a separate step, so a draft you are still editing is never picked up by a schedule or a webhook.

Run on demand

There are two ways to start a run by hand:

• Run in the editor toolbar. It starts the last saved version of the automation, so save first. The button is disabled while the canvas has validation errors, and it does not require the Active status, so you can test a draft. Stop replaces it while a run is in progress.
• Run now in the row menu on the Automations page. It is enabled only for Active automations, and a toast confirms Automation started.

Starting a run by hand is itself a governed action: a rule can block it before the run is created. The automation also needs at least one source node to run. See Automations.

Schedules

Open the row menu for an automation on the Automations page and choose Edit schedule. Pick one of three types:

For Scheduled and Recurring, pick a Timezone (the dialog offers UTC, Europe/Stockholm, Europe/London, America/New_York, America/Los_Angeles, Asia/Tokyo, plus your browser's timezone, which is the default). Then switch on Enable schedule and choose Save schedule.

• Enable schedule can only be switched on while the automation is Active. Saving a disabled schedule keeps the settings but nothing runs.
• A scheduler checks once a minute for runs that are due.
• A scheduled run starts with no input data, so it relies on its source nodes. A Webhook source emits no records on a scheduled run.
• If the previous run is still pending or running when the next one is due, that scheduled run is skipped and the schedule moves on to the following time. Runs do not pile up.

On the Automations list, a badge on each row shows the schedule (Manual, a description such as Daily at 9 AM or Every 30 min, or Disabled). Hover over it to see the Next run time.

Webhook trigger

A webhook lets an external system start an automation by sending an HTTP request.

Turn it on

1. Choose Configure webhook in the row menu for the automation.
2. Switch on Enable webhook. The first time, the dialog shows the Webhook URL and a Signing secret.
3. Copy the secret straight away: it is shown once ("Save this secret now"). Regenerate secret creates a new one and immediately invalidates the previous one.
4. Set the automation to Active. The dialog warns that webhook triggers only run for Active automations.

Switching the webhook off makes the URL stop responding. The ID and secret are kept, so switching it back on does not show the secret again; regenerate it if you have lost it. Rows with a webhook enabled show a Webhook badge in the Automations list.

Send a request

Send a POST request to the webhook URL with a JSON body of up to 1 MB. Every request must be signed:

TS=$(date +%s)
BODY='{"data":[{"email":"lead@example.com","score":82}]}'
SIG=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" -hex | sed 's/^.* //')

curl -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "x-webhook-timestamp: $TS" \
  -H "x-webhook-signature: $SIG" \
  -d "$BODY"

A successful call returns status 200 with success: true and the executionId and workflowId of the new run. A repeat delivery with the same idempotency key returns the original run with deduplicated: true.

Responses include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers.

Map the payload to records

Add a Webhook source node to the automation and choose how the JSON body becomes records: the whole payload as one record, an array extracted from a path, or renamed fields. The node has a Test mapping control so you can check a sample payload before going live. Without a Webhook node, the whole payload is passed on as a single record.

Follow a run

• History in the editor (bottom right of the canvas) lists recent runs, up to 50, and can be filtered by Pending, Running, Completed, Failed, or Cancelled.
• View logs in the row menu on the Automations page opens an Execution history dialog with the 20 most recent runs. Expand a run to see its status, items processed, usage, any error, and its ID.
• The Logs tab of the data preview at the bottom of the editor shows the logs for the run, and the View logs button in the editor header opens it. A red badge on the button counts errors.
• Stop in the editor toolbar asks a running automation to cancel. The current node finishes first, so cancellation is not instant.

When a run fails

A failed run is recorded as a Workflow failure item in the Queue, with high urgency and the error message as its title. Open it to see the details, then Acknowledge it to show someone has seen it, or Abandon it to close it. A run you cancel yourself is not recorded as a failure.