Triggers

A trigger is what starts a Helix run — the product calls this the automation’s stimulus. Every automation has one, and you can change it at any time. On a live automation, a new schedule, interval, or Autopilot setting takes effect as soon as you save. There are four ways to start a run today: on demand, on a schedule, from a webhook, or on Autopilot.

On demand

Run the automation by hand whenever you need it — from its page in the app, or as part of testing. On-demand is the default while you’re building, and stays useful for automations you run occasionally or want to kick off yourself.

On a schedule

Run the automation on a recurring timetable using standard cron syntax. Nightly, hourly, “weekdays at 9 AM” (0 9 * * 1-5), the first of the month — whatever cadence the job needs. A built-in helper offers common presets so you don’t have to memorize cron. This is how you drive recurring processes like monthly reporting or first-of-the-month billing runs.

For simple time-based agent runs outside of Helix, see Schedules.

From a webhook

Start a run when an external system calls in. Helix gives the automation a secure webhook URL; when a request arrives, the run begins and the incoming payload is available to your steps. Use this to react to events from other tools — a GitHub push or pull request, a form backend, a payment processor, or any service that can send an HTTP request.

Filtering which requests start a run

Not every request to the webhook URL should necessarily start a run — a GitHub webhook fires for every push and PR event, but you might only want to react to pushes to your main branch, or PRs being opened. A filter lets you say which requests actually trigger a run; everything else is received and discarded.

A filter is a simple condition checked against the payload:


<path> <operator> <value>

path is a field in the incoming payload — action, ref, repository.full_name, and so on.
operator is one of a small set of comparisons: exists, contains, ==, and similar.
value must be a literal — a fixed string, number, or boolean you write into the filter. It can’t be a reference to another field in the payload; you’re comparing the field against a fixed value, not two fields against each other.

Two things trip people up when writing a filter:

Paths are not prefixed with payload.. The filter evaluates directly against the payload’s own top-level fields, so write action == "opened" — not payload.action == "opened". A path with a payload. prefix simply won’t match anything.

The right-hand side is always a literal. ref == "refs/heads/main" is a valid filter; you can’t write something like ref == repository.default_branch to compare two fields against each other.

A GitHub PR-opened filter, for example, is just action == "opened"; a push-to-main filter is ref == "refs/heads/main".

On Autopilot

Autopilot keeps an automation running in the background so you don’t have to start it. It used to be called Continuous; it’s the same trigger under a new name, and every automation that used Continuous keeps working exactly as before.

Pick Autopilot as the trigger, then choose how it runs:

Mode	What it does
Fixed interval	Runs the automation’s steps on a timer — every N seconds, minutes, or hours, from once a minute up to once a day. Every tick is a full run. This is exactly how Continuous behaved.
Let it decide	Checks in on its own schedule, looks at what has changed, and only gets your attention when something matters. Most checks end quietly.

Rolling out: Let it decide is being enabled workspace by workspace. Until it’s enabled for your workspace, the Autopilot trigger shows a single Poll interval field and runs on a fixed interval, exactly as Continuous did.

Let it decide

Each time it checks, Autopilot looks before it acts. It reads from your connected apps (only through tools Cendriix has verified as read-only, so a check can never change anything) and compares what it finds with what you asked it to watch for. (Read-only tools are being verified app by app, so a check may not yet be able to read every app you’ve connected.) Then it does one of three things:

Stays quiet. Nothing is worth telling you. The check is recorded, but it doesn’t count as a run in your success rates and doesn’t notify anyone.
Acts. Something matters, so it runs the automation’s steps, with what it found passed in as input. From here it’s a normal run: your approvals, guardrails, and budget all apply.
Asks. It wants your decision before it acts, and shows you a question with Yes and No. Yes carries on as if it had decided to act. No ends the check quietly. A question you never answer lapses, and the check is recorded as quiet.

After every check it picks its own next check time, within the range you allow.

The settings, in plain words

Setting	What it means
Tell me when (required)	What is worth your attention, in your own words — “a pull request has waited more than a day for review”. Anything else, it keeps quiet about.
Ask me before	What needs your yes or no before it acts — “posting in a public channel”, “closing anything”.
Done when	When this is true, it stops itself. Leave it empty to keep watching indefinitely.
How often to look	As needed (between every 15 minutes and once a day, its choice), Often (every 15 minutes to every hour), or Daily (once a day).
Daily check limit	The most checks it may make in a day, from 1 to 96 (24 by default). The count resets at 00:00 UTC; once it’s reached, the next check waits for the new day.
Listen for messages in chat	Lets you message it from Cendra chat. On by default.
Keep notes	Lets it write short notes to itself between checks. On by default.

Quiet checks

Quiet checks are hidden from the automation’s run history by default, so the history shows only checks where something happened. Turn on Show quiet checks to see them; a run of quiet checks in a row collapses into one line, such as “12 quiet checks · 9:00–14:00”. The runs count for the last seven days shows quiet checks separately, and they’re never counted toward the success rate. Quiet checks are kept for seven days.

Notes

With Keep notes on, Autopilot writes down what it wants to remember between checks — “PR #412 was already flagged on Monday” — and reads its notes before every check, so it doesn’t repeat itself. You’ll find them on the automation’s page and in the editor’s Memory tab. It keeps up to 50 notes, dropping the oldest first, and you can delete any note you don’t want it to rely on.

Messaging it

When Listen for messages in chat is on, you can talk to an Autopilot automation:

In Cendra chat, mention it with @helix and pick it by name, then write your message — “anything new on the release branch?” It looks, and its reply comes back in the chat. There’s nothing to approve first.
On the automation’s page, use Message it.

A message gets an answer straight away, without waiting for the next scheduled check, and doesn’t use up the daily check limit. If what you asked for needs the steps to run, it runs them. If it’s in the middle of a check, or waiting for your answer to one of its questions, it tells you so, and you can message it again in a moment. You need permission to manage the automation to message it.

When it’s done

When Done when comes true, the automation pauses itself and its page shows Stopped: goal met. Nothing is deleted. Resume starts it watching again.

Example: keep an eye on PRs waiting for review

Say you want to hear about pull requests that are stuck, without a message every hour:

Tell me when: a pull request in the web repository has had no review for more than one working day.
Ask me before: posting a reminder in the team channel.
Done when: leave empty, so it keeps watching.
How often to look: As needed.
Steps: one agent step that writes a short summary of the stuck pull requests and who they’re waiting on, followed by a Slack step that posts it.

Most checks find nothing new and end quietly. When a pull request crosses the one-day line, Autopilot asks whether it should post a reminder; say Yes and the steps run with the stuck pull requests as their input. Its notes stop it raising the same pull request twice, and you can ask in chat at any time: “@helix PR Watch, what’s waiting right now?”

Using the API? Autopilot is still the continuous stimulus type, so existing automations and integrations need no changes. Let it decide is configured under the stimulus’s autopilot settings.

Passing data into a run

However a run starts, its stimulus — the incoming payload, the values you provide on demand, or what an Autopilot check found — is available to your steps. A step can read fields straight from the stimulus, so a webhook body or a form submission flows directly into the pipeline.

Note: a wait step can also pause for an “event” mid-run — that’s a different thing from the stimulus that starts a run in the first place. See Wait steps for that distinction.

Coming soon: connector-event triggers, which start a run automatically when something happens in one of your connected tools — a new record, an inbound message, a completed signature. Until then, use a webhook to bridge external events into an automation.