Automation triggers
An automation is one trigger paired with one action. Ronja sets automations up during explorations — ask her (for example “Schedule a daily revenue summary every morning at 9 AM”). See Schedule an automation for the walkthrough.
Trigger × action matrix
Section titled “Trigger × action matrix”| Trigger | Workflow action | Saved Agent action |
|---|---|---|
| Schedule | ✓ | ✓ |
| — | ✓ (required) | |
| Webhook | — | ✓ (required) |
| Table | ✓ | ✓ |
| Event | ✓ | ✓ |
| Mailbox | — | ✓ (required) |
The trigger kind is fixed after creation (“Trigger kind cannot be changed after creation.”) — to change it, delete and recreate. The action can be switched on edit, except email, webhook and mailbox triggers, which stay locked to a Saved Agent.
Schedule
Section titled “Schedule”Runs on a cron cadence you set.
| Config field | Details |
|---|---|
| Cadence | Hourly / Daily / Weekly / Monthly / Custom (5-field cron) |
| Timezone | IANA timezone for the schedule (separate from the reporting timezone) |
| Minimum interval | 1 hour — schedules firing more often are rejected |
Fires when a matching email arrives at the automation’s private Routable address (⟨org prefix⟩+⟨token⟩@⟨ingest domain⟩).
| Config field | Details |
|---|---|
| Routable address | Server-generated; Copy and Rotate (rotating immediately invalidates the old address) |
| Allowed sender domains | Mail from any address on these domains can fire the automation |
| Allowed sender addresses | Specific senders permitted in addition to the domain allowlist |
- The sender allowlist is the entire authorization — an enabled email trigger must have at least one allowlist entry. Keep it tight: the automation runs AI-generated actions on content from external senders.
- Prerequisite: an admin must first set the org-wide Email-trigger ingest prefix at Organization → Approvals. Until then the editor shows “Address pending”.
- Email attachments are saved as Ronja files for the run; the email body is handled as untrusted input.
- A zipped attachment is unpacked automatically while it’s small, and the files inside are available to the run as ordinary attachments. A large or password-protected archive is listed instead — the run can unpack it itself, in full or by naming the files it needs. See Zip archives.
Webhook
Section titled “Webhook”Fires when JSON is POSTed to the automation’s public Receiver URL.
| Config field | Details |
|---|---|
| Receiver URL | Server-generated; Copy and Rotate |
| Signing secret | Optional HMAC signing (“Signed (HMAC)” vs “Unsigned — the URL is the secret”); the secret is shown once at creation or rotation |
| Caps | 1,000 runs per rolling 24 hours per automation · 1 MB request body · signed requests must be within a 5-minute timestamp window |
- Without a signing secret, anyone with the URL can trigger the automation — treat the URL as a secret.
- The editor’s collapsible “How to call this webhook” shows the exact request, including the signature headers and an idempotency key for safe retries.
Fires when a watched table finishes (re)building.
| Config field | Details |
|---|---|
| Watched tables | At least 1, at most 25 tables, chosen from the automation’s feature |
| Caps | 50 runs per rolling 24 hours per automation (the loop-safety bound) |
- A table trigger cannot run a workflow that writes one of its own watched tables (self-watch loop guard).
- A Saved Agent action receives the triggering table’s details; a workflow action runs on its stored parameters.
- Watching a table counts as depending on it: Ronja refuses to delete a table while an automation watches it, and tells you which automations to detach first. This holds whether the automation is on or paused — a paused one would break the moment you switch it back on.
Fires when a named custom event is emitted somewhere in your organization. Events are Ronja’s internal message bus: a workflow can emit one mid-run, or an external system can post one over the API. Every automation that subscribes to that event name fires — one emit fans out to all subscribers in the organization.
| Config field | Details |
|---|---|
| Event name | The event this automation subscribes to (a lowercase token). Fixed after creation, like the trigger kind |
| Caps | Bounded by a per-organization daily event-run ceiling — a loop-safety bound across all event automations |
- Two ways to emit an event: a workflow emits one during a run (Ronja adds the emit step when you ask her to), or an external system posts one to
POST /service-api/v1/eventwith an API token. Either way, one emit reaches every subscribed automation. - The event’s payload is passed to the action as trigger input, and is treated as untrusted — exactly like an inbound email body or webhook JSON. A Saved Agent action reasons over it; a workflow action runs on its stored parameters.
- Because one automation’s action can emit an event that fires another, the per-organization daily ceiling is the guard against a runaway emit → subscribe loop.
Mailbox
Section titled “Mailbox”Fires when new mail arrives in a connected mailbox — the shared inbox Ronja reads and replies from as your own address. See Connect a mailbox. One message that matches produces one run of the Saved Agent, seeded with that message.
Binding a mailbox to an automation requires Admin, the same as connecting one.
| Config field | Details |
|---|---|
| Watched mailbox | The connected mailbox to watch — the picker offers the working ones. Chosen at creation and normally fixed afterwards; the filter stays editable. The one exception is an automation whose mailbox was disconnected — there the picker unlocks so you can point it at a currently connected mailbox |
| Filters (optional) | From these domains · From these addresses · Subject contains · Only messages with an attachment. Up to 50 entries per list |
| Caps | The same per-automation limits as the other push triggers — 1,000 runs per rolling 24 hours and 60 runs per minute by default |
The mailbox’s Watched label scopes what the trigger ever sees; the filters narrow it further. If the mailbox has a Watched label set, only mail filed under it reaches any automation on that mailbox — set the label to carve out what Ronja handles at all, and the filters below to split that between several automations. See Watched label.
⚠️ A label that no longer exists is ignored, and Ronja falls back to watching the whole mailbox. A renamed, deleted or mistyped label can’t be matched, and the fallback widens the scope rather than closing it — so an automation with no filters of its own starts firing on every message. Nothing turns red when this happens; if a scoped trigger suddenly starts running on everything, check the label name on the mailbox card first.
Filters are optional — unlike the Email trigger, whose sender allowlist is mandatory. A support inbox means unknown senders, so requiring an allowlist would make the trigger useless for the case it exists for.
- Leave every filter blank and the automation runs on every new message. That is the normal setup for a shared or support inbox.
- Filters combine as you would expect: a message must match every section you fill in, and any one entry within a section. Sender domains and sender addresses are one section between them — a message passes if it matches either.
- Domains match exactly.
acme.commatchesalice@acme.combut notalice@mail.acme.com— a subdomain is a different domain. List each one you want to admit. - Only messages with an attachment narrows what runs, but it bounds nobody — anyone can attach a file. It is not a substitute for a sender filter.
- Changing which mailbox a working automation watches isn’t offered in the product — delete it and create a new one. The API can re-point one (an Admin-only call), and doing so re-arms the automation, so mail already sitting in the new mailbox is not worked through. The exception is repair: if the mailbox was disconnected, the automation’s editor lets you point it at a currently connected mailbox, because a reconnected mailbox is a new one and the automation cannot be switched back on until it is re-pointed.
Ronja shows another warning, at the same moments, when the automation’s Saved Agent doesn’t list this mailbox among its own references. That automation still runs — each run is seeded with the message and can log it, file it to a table, or start something else — but it cannot read, reply to, or triage the mailbox, so an automation meant to answer mail answers nothing. Add the mailbox to the Saved Agent’s references; see References and pre-approved actions.
A mailbox that stops working stops its automations, silently. If the mailbox needs reconnecting — the authorization expired, or the provider check failed — the automations watching it simply stop firing. Unlike a disconnect, nothing is switched off, nothing is marked, and each automation keeps reading Active. If a mailbox automation has gone quiet, check the mailbox’s own card on the Mailboxes page first; Reconnect resumes it, with no re-enable needed.
Only mail that arrives after you enable it fires. Enabling a mailbox trigger does not replay what is already sitting in the inbox — nor does re-enabling one after a pause, which starts from the moment you switch it back on. There is no way to make it work a backlog; ask Ronja to handle a backlog in an exploration instead. Editing a mailbox automation shows the cut-off it is working from, under the Status toggle — “Armed 2026-08-07 09:14 — mail that arrived before then is never picked up” — which is what to check a test message against.
Checking is not instant. Ronja looks at a watched mailbox roughly every couple of minutes while mail is arriving, and less often as it goes quiet — down to every five minutes, then every twenty. First response is minutes, not seconds.
The pace follows the mailbox, not your filters. How busy a mailbox is decides how often Ronja looks at it — not how often any one automation’s filters happen to match. So a narrowly-filtered automation on a busy shared inbox still gets the fast couple-of-minutes pace, and several automations on one mailbox share a single check rather than each adding one.
Ronja looks back only a few hours. Mail that arrives and then ages past that window before a successful check is not picked up afterwards. A long service interruption is the obvious way that happens, but not the only one: it also applies while a mailbox is repeatedly failing to be checked and Ronja is backing off, while its authorization needs reconnecting, and while the mail provider is rate-limiting the account. If a mailbox has been unreachable for hours, treat the mail from that period as needing a person — or ask Ronja to work through it in an exploration.
Disconnecting the mailbox disables the automations that watch it. They are switched off automatically and say why (“Disabled automatically — the mailbox it watched was disconnected. Connecting a mailbox again creates a new one, so edit this automation and point it at a currently connected mailbox before enabling it.”), rather than staying green against a mailbox that no longer exists. Connecting the address again is not enough on its own: a reconnected mailbox is a new mailbox, so open each automation, pick the newly connected mailbox in its trigger, save, and switch it back on. Ronja refuses a plain re-enable while the automation still points at the mailbox you disconnected. Switching one back on re-arms it, so mail that arrived while it was off is not replayed.
Common to all triggers
Section titled “Common to all triggers”| Setting | Details |
|---|---|
| Reporting timezone | The zone the automation’s Saved Agent action groups days/weeks/months in — separate from the schedule timezone. Blank = organization default. A workflow action that carries a reporting timezone of its own ignores this setting and buckets the same way however it was started; a workflow without one follows it |
| Pause / resume | The on/off toggle on every row and in the sidebar; a paused automation ignores its trigger |
| Run now / Test | Manual fire from the row or sidebar; Ronja can also dry-run an automation before enabling it |
| Deletion | Moves to the 30-day trash and auto-pauses; an admin can restore it |
Approvals and automations
Section titled “Approvals and automations”A workflow that stops for a decision part-way through a run automates perfectly well: the run starts normally, sits at Awaiting approval only if it reaches the step that asks, and its approvers get one Review and decide link to the run page. See Mid-run approvals and Approve a workflow run.