Create a workflow

Who can do this

Creating workflows requires Build mode access (enabled per account by an administrator). Running a workflow in your own private feature requires the User role; running or changing shared workflows requires Admin.

A workflow is a named, reusable job Ronja writes for you: it reads tables, computes, and produces tables, files, or reports. You never author one by hand — you describe it in a Build-mode conversation and Ronja builds it as a draft you can test before committing.

Build it

1. Click New Exploration and select Build on the start screen.
2. Describe the job — the product’s own example: “Create a workflow that calculates monthly churn from our events table”.
3. Watch the chat cards as Ronja works: Workflow created (a draft only you see), then File saved / File edited as it writes the code.
4. Ask Ronja to test-run it — the run card shows the result, plain-language timing, and a View trace button.
5. Ask Ronja to commit when you’re happy: Draft promoted to live publishes it.

Ronja creating, coding, and test-running a workflow in one conversation.

Tip

Be specific up front, and read the Plan Ronja writes before she starts coding. Correcting the scope in the plan builds the right workflow the first time and spends fewer credits than reworking a finished one.

Ask for a durable workflow up front

For a long job with many steps — a loop over hundreds of records, or one that sends mail and writes rows as it goes — say so when you describe it: “make this one durable, so a failure can pick up where it left off”. Ronja then builds it to remember what each step produced and what it already sent, it carries a Durable badge, and re-running it after a failure skips the work that already succeeded — without re-sending the mail it already sent. The same memory lets it pause mid-run — waiting for a Saved Agent it handed work to, or until a set time — and pick up where it left off when the moment comes; see Monitor runs and traces. Best asked for up front, but not a dead end if you didn’t: a workflow you later wish were durable can be made durable — ask Ronja, and she adapts the code as part of the change. It is a one-way switch; a durable workflow never goes back.

Caution

In a shared feature the outcome depends on your role: a non-admin’s edit is Submitted for review and an Admin approves it, while a non-admin’s new workflow becomes a proposal (“Proposal submitted · awaiting admin approval”). See Propose and review changes.

Tables the workflow reads appear on its page under Inputs; the tables and shared folders it writes to appear under Writes to. Ronja binds these automatically as it writes the code.

Send report files to a shared folder

For a report workflow, tell Ronja where the files should land — “save these into a Reports folder”. If that folder already exists, files land there right away — even a test run while you’re drafting. If it doesn’t, ask Ronja to create it (“create that folder”) so your next test run files there, or it’s created when you publish; a shared workflow’s review dialog shows the folder access under Access changes. See Workflows and automations.

Send the result as your own address

A workflow can email its result out. By default that mail comes from Ronja’s own address — but if an Admin has connected a mailbox, it can be sent as that address instead (support@yourcompany.com), so the recipient sees your organization, not Ronja. Ask for it when you describe the job: “…and email the summary to the sales team from support@”. Sending is all a workflow can do with a mailbox — reading, replying, and triage stay with the agent — and binding a mailbox to a workflow requires Admin. See Sending mail from a workflow.

Parameters

Workflows can declare typed run-time parameters — text, number, date, and select (a select’s options can even load live from a table). Required parameters are marked with a red *.

1. Open the workflow from its feature hub row or a link in chat.
2. Fill in the parameter inputs below the run button.
3. Click the run button — labeled Run, Run pipeline, or Generate report depending on the workflow’s kind.
4. Watch the run appear at the top of the Activity list — see Monitor runs and traces.

If the most recent run failed, an Investigate with Ronja button appears under the status line at the top of the page. It opens a new chat in Build mode with the workflow’s code, its recent runs and the failing error already loaded, and Ronja already working out the cause — she proposes a fix and confirms it with you before changing anything. Admins with Build mode only; see Monitor runs and traces.

Approval before a run

To put a person in the loop before Ronja does something consequential, ask for a mid-run approval — the next section. The run starts, does the work up to the step you’re nervous about, and stops there to ask. It works wherever the workflow is run from: its own page, an app, or an automation on a schedule.

The approver’s side of it — the email they get, what the card asks, and what Approve and Reject do — is Approve a workflow run.

Legacy: the Pre-run approval gate

Some older workflows carry a Pre-run approval gate instead, shown on the workflow’s page under that name with a Deprecated label. It holds every run before anything executes, and it can only be satisfied in a chat: the run button on the workflow’s page — and any automation that fires it — is refused with “this workflow requires approval and cannot be run from this entry point”. Every run re-prompts; there is no “always approve”.

It keeps working where it is already switched on, but it can no longer be switched on — no new workflow can have one. Ask Ronja to convert the workflow to a mid-run approval; the approvers and where the request is delivered carry over unchanged.

Mid-run approvals

Some jobs shouldn’t stop at the door — they should stop at the one risky step in the middle. A Durable workflow can do the first half of its work, pause to ask a person to decide, and carry on from exactly where it stopped once they do.

Ask for it when you describe the job: “require approval before it posts the invoices”, “ask me before it emails the customers”. Ronja writes the question the approver reads, the details they need to decide on, and who to ask.

1. Ask Ronja to require approval before the step you’re nervous about — and, in the same sentence, say who should be asked (“…and ask the finance team”). Everyone you name has to be a member of your organization — an email address with no Ronja account behind it is refused when the run reaches the step, rather than mailed and never answered. If you name nobody, the workflow falls back on any approvers already set on the workflow itself; with neither, the run fails at that step rather than deciding for itself.
2. Ask her to make the workflow Durable if it isn’t already — a mid-run approval needs that memory to resume without redoing work. She can switch an existing workflow over; see the durable-workflow tip above.
3. Set the deadline if the default doesn’t fit: 7 days by default, 14 days at most.

When a run reaches that step it sits at Awaiting approval, the approvers get an email (or Slack) with a Review and decide link, and the decision is made on the run page — see A run that is awaiting approval. Approve and the run carries on; Reject and it fails; nobody decides in time and it fails too.

Those workflow-level fallbacks are shown on the workflow’s page as an Approval defaults card — the Approvers and Delivery a mid-run approval uses whenever the workflow’s own code names nobody.

This one does run unattended

A mid-run approval doesn’t stop the workflow from being run from its page, opened in an app, or fired by an automation. The run starts normally and only stops if it reaches that step — which is the point: the approver is asked about a specific thing, with the work up to it already done, rather than about the run as a whole before it has anything to show. That is the difference from the legacy Pre-run approval gate above, which refuses every entry point except a chat.

Caution

Don’t republish a workflow while one of its runs is waiting on a decision. If the decision is Approve, the run does not continue on the new version — it fails and has to be re-run, because the approver said yes to code that no longer exists.