Workflows and automations

Two building blocks turn one-off analysis into recurring, dependable work: a workflow defines what to do, and an automation defines when to do it.

Workflows: reusable jobs

A workflow is a named, parameterized, re-runnable Python job that Ronja writes for you during an exploration in Build mode. Instead of redoing an analysis by hand every month, you ask Ronja to turn it into a workflow once — then it can be re-run on demand, filling in parameters (a date range, a region, a customer) at run time. Running a shared workflow needs an Admin; private workflows are run by their owner.

Most workflows declare a kind that describes their primary output:

Function — computes and returns a value.
Pipeline — reads tables and writes tables.
Report — produces a formatted document (HTML, PDF, and more).

A workflow’s page shows what it reads (Inputs), what it writes (Writes to), its files, and its run history. Every run is recorded with a status — Running, Waiting, Continued, Success, Warnings, or Failed — plus logs and output, so “what happened last night?” always has an answer. A run paused for someone’s decision reads Awaiting approval. Edits to shared workflows go through drafts and review.

The reporting timezone

A workflow can carry a reporting timezone — the calendar it groups by when it rolls data up per day, week, or month. An order placed at 23:30 lands on the day it belongs to locally rather than on the next day in UTC, and invoices dated the 1st fall in the month your business would put them in.

A workflow that carries one uses that calendar on every run, so a run fired by an automation at 07:00 and a run someone starts by hand in the afternoon produce the same numbers. Without it, the calendar would follow whoever triggered the run — which for a workflow that writes its results into a table means the stored table quietly changes shape depending on who ran it last.

A new workflow takes your organization’s timezone (set by an admin on the Approvals page in the admin area) and keeps it from then on, so changing the organization default later doesn’t move the calendar of workflows you already have. A workflow created before your organization set one — or while it has none — doesn’t carry a calendar, and each run groups by whoever or whatever started it, exactly as before. To change one workflow’s calendar, ask Ronja in chat — “group this workflow’s months in Europe/Stockholm”. On a shared workflow that goes through the usual draft and review path, like any other change to its code.

Where a workflow’s report files land

A workflow that produces report files (a PDF, an Excel export, an HTML summary) can file them into a shared folder so the right people can find them. Just tell Ronja where they should go — “save the monthly report into a Reports folder” — and she names that folder in the workflow’s code. If you don’t name a folder, the outputs still get a tidy home: each workflow gets its own subfolder — named after the workflow — under a shared Workflow outputs folder, readable by the same people who can see the workflow — so its files stay together and reachable instead of scattered.

Once the folder exists, files land there automatically — even a test run you do while still building the workflow. If the folder doesn’t exist yet, Ronja can create it for you while you’re drafting (just ask — “create that folder”), so your next test run files its report there; otherwise the folder is created when you publish the workflow. A brand-new top-level folder can only be created by an admin. Whoever creates a folder keeps write access to it, alongside the workflow that files there — so the reports your workflow produces stay reachable by the person who set it up. Publishing finalizes the workflow’s own access, and if the workflow is shared the draft review dialog shows an Access changes section naming the folders it will write to — the reviewing admin approves that access along with the code. A workflow’s page shows its destinations under Writes to, and each folder links straight into Files.

If a run can’t reach its folder — for example the folder doesn’t exist yet, or its access was later removed — the run still succeeds and the file is saved (just not filed), and the run shows a short delivery note explaining what happened and how to fix it. You never lose an output to a folder problem.

Admins can open a folder in Files to see its Access — who can read or write it — and Written by, the workflows and automations that save files into it. Each writer may carry a small badge: no files yet means it has write access but hasn’t saved anything here so far (normal for a report that hasn’t had its first run); no write access means it saved the files that are here but no longer has write access, so its next run won’t be able to file its output — re-add its access if that’s not what you want. A writer with neither badge is healthy: it has access and its files are here. Pick the folder and audience early when you set up a recurring report, so its outputs land in the right home from the first run.

Automations: triggers that run work

An automation pairs one trigger with one action. The trigger decides when it fires:

Schedule — on a cadence you set (at most once per hour).
Email — when a matching email arrives at the automation’s private address.
Webhook — when an external system posts JSON to the automation’s receiver URL.
Table — when a watched table finishes rebuilding.
Event — when a custom event is emitted somewhere in your organization.
Mailbox — when new mail arrives in a connected mailbox.

The action decides what runs: a workflow (deterministic — the same job on its stored parameters every time) or a Saved Agent (a reusable agent that reasons about the incoming email, payload, table build, event, or mailbox message). Email, webhook and mailbox triggers always run a Saved Agent — only a Saved Agent can reason about an arbitrary inbound message or payload; schedules run either, and table and event triggers run a workflow or a Saved Agent.

Automations live on the Automations page — a list and a timeline of past and upcoming runs, with health indicators and per-automation run history. Like workflows, they’re created by asking Ronja in an exploration; the page’s own empty state suggests exactly that: “Schedule a daily revenue summary every morning at 9 AM”.

The Automations page listing automations with their schedules and next runs The Automations page: each row pairs a trigger with the workflow or Saved Agent it runs.

How they fit together

The classic pattern: Ronja builds a workflow during an exploration (“create a workflow that calculates monthly churn”), you test-run it together and commit it — then ask her to add an automation that runs it every morning. From then on the work happens on its own. Failed runs can notify admins (the “Automation run failed” notification — once when an automation starts failing, not once per failed run, so an hourly job that breaks overnight sends one email rather than a dozen), and every run produces an execution trace you can inspect step by step (traces are kept for about a year) — see Monitor runs and traces.

Stopping mid-run for a person

A Durable workflow can stop at one particular step — do the work up to it, then ask a named person to decide before going further. That run sits at Awaiting approval while it waits, the approvers get an email (or a Slack message) with a link to the run, and it carries on from where it stopped as soon as someone approves — or fails if they reject it or nobody answers in time.

This works unattended: an automation can fire such a workflow perfectly well, because the approver is asked about a concrete thing, with everything up to it already done and shown to them. See Create a workflow and Monitor runs and traces.

Which one do you need?

Repeat the same job on demand, with parameters → a workflow.
Run something without anyone asking — on a schedule or in response to an event → an automation that runs a workflow or a Saved Agent.

Step-by-step guides: Create a workflow and Schedule an automation. Trigger details live in Automation triggers; the one-paragraph comparison is in What’s the difference?.