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 | ✓ | ✓ |
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 and webhook 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.
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.
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.
Common to all triggers
Section titled “Common to all triggers”| Setting | Details |
|---|---|
| Reporting timezone | The zone reports group days/weeks/months in — separate from the schedule timezone. Blank = organization default |
| 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 |
Approval links and gated workflows
Section titled “Approval links and gated workflows”Workflows can carry an approval gate that pauses every run for a human decision:
- When a gated workflow run is requested in chat, approvers get an email — “[Ronja] A workflow run needs your approval” — with Approve and Reject buttons. The buttons open a confirmation page first: nothing is decided until you confirm there. The same links can be delivered to Slack.
- The approval page shows the workflow, the requester’s message, the run details, and an optional comment box; once decided it reads “This run has been approved. The workflow will continue automatically.” (or notifies the requester of a rejection). Expired or reused links show a friendly error — ask the sender for a fresh link.
- Gated workflows cannot run from automations. A headless fire of a gated workflow fails closed with “this workflow requires approval and cannot be run from this entry point” — don’t schedule approval-gated workflows.