Approve a workflow run

Someone in your organization built a workflow — a job Ronja runs for them — and wrote a checkpoint into it: before it does the consequential part, a person has to say yes. You are that person. This page is everything you need, and assumes you have never used Ronja for anything else.

What you’ll have received

An email, or a Slack message, with the question the workflow is asking and a single Review and decide link.

The email’s subject names the workflow and the run — “[Ronja · your organization] Approval needed: workflow name (run #abc123)” — so two requests never land in the same mail thread. Inside, the question comes first, then the workflow, the run and the date the decision is needed by, then the Review and decide button, and any details the workflow attached underneath it.

The email also says when the request was drafted and, underneath, Built from orders, support_mail — the tables the workflow read. If one of them has been deleted in the meantime it says so too, even though it can no longer name it: Built from support_mail and a table that has since been deleted. It does not say whether those tables have changed since: the email is sent once, when the request is raised, and is never sent again, so anything it said about “now” would be about the moment it was written. The run page is where that is live.

The email shows the first five of those details. If there are more, a +3 more on the run page link sits under them and takes you straight to the full list — the email is a nudge, the page is where you decide, and the page always shows everything.

You can’t decide from the message. The link opens the run in Ronja, where you sign in and decide — that way it’s really you deciding, and the record says so.

What you’ll see

The link lands you on the run’s page, with a card at the top:

Awaiting approval, and beside it a deadline — Expires in 6 days or similar — and how old the request is: Drafted 14 hours ago. The two together are the thing worth reading twice. A request drafted three days ago was answered by data that is three days old.
The question — written by whoever built the workflow, in their words.
Built from orders, support_mail — the tables the workflow read in order to put this together, and whether any of them has moved since, with how long after the draft it moved: — orders changed 41 minutes later, or — orders has been deleted since. The time is the part worth reading. A table that syncs continuously changes between any two moments, so “changed” on its own means very little — but a table that moved forty minutes after the draft was written moved while the question was sitting in somebody’s inbox. It’s a prompt to look, not a verdict: a changed table doesn’t mean the request is wrong, it means the numbers below were true earlier and may not be now.
A short list of details: whatever the workflow thought you’d need in order to answer. A count, a total, a summary of what it’s about to do.
A Comment box. Optional; the note goes to whoever started the run.
Approve and Reject.

Below the card is the run itself — everything the workflow has already done up to this point. It genuinely has stopped: nothing past this step has happened, and nothing will until you decide.

If you were asked about a workflow you otherwise have nothing to do with, you’ll see a note saying You don’t have access to the rest of this run — only the approval above. That’s normal: you were asked one question, and you’re being shown that question rather than somebody else’s work.

Decide

Click Approve or Reject. A short confirmation appears — Run approved or Run rejected — and the card keeps your decision on it for anyone who looks at the run later. It now reads as a sentence at the top of the card — You approved this on 21 Aug 2026 at 16:29, or your colleague’s name in place of “You” — with your comment underneath. The details the workflow attached move behind a Details link, still there when you want them; a request nobody answered says Nobody decided — this request expired on date rather than pretending someone turned it down.

Your choice	What happens
Approve	The workflow carries straight on from where it stopped. It does not start over, and it does not redo work it already finished
Reject	The run stops for good and is recorded as failed — unless the workflow was written to take a “no” and do something else instead
Nothing	The request expires — after 7 days by default, and never more than 14 — and the run fails. Nobody is blamed; the work simply doesn’t happen

If the workflow was republished while you were deciding, the run cannot carry on at all: it would run code you were never shown. Approve is not offered on such a request, and a line above the buttons says so and names both versions. Reject still is — it is how you close the run out. If you had already approved it when the new version landed, a notification appears under Notifications — the bell at the bottom of the sidebar — saying the decision could not be carried out; the run was stopped and nothing you approved happened.

A decision that later came to nothing says so on the card: This approval was not honoured, with the reason. The record keeps both halves — what you said, and what it turned out to be worth.

There is a second way a decision can come to nothing, and you are told about that one too: the run fails after you approved it. You get the same notification, saying the run did not finish. Unlike a republish, this one does not mean nothing happened — some of what you approved may already have gone ahead and some may not, so check the run before deciding what to do next. It arrives however often it happens: this notification is never limited to one a day. The one exception is a run someone cancelled after you approved it: it reads Failed, its summary names who cancelled it, and no notification is sent — a person stopped it; it did not break. Open the run to see what had already gone ahead.

The notification in Ronja is the part you always get. The email is not. Both of these (a cancel aside) arrive in the bell whatever anyone has configured — that is deliberate, because a decision that came to nothing is the one thing nobody should have to go looking for. Whether they are also emailed is up to your organization: Workflow approval could not be honored starts switched off, and an Admin turns it on under Notification routing — in the sidebar’s Governance group — on the Approvals section of that page. Until they do, the bell is where it appears. The email links the run that stopped — Open the run in Ronja: the paused run after a republish, or the run that failed after you approved — and if you are in a different organization when you open it, Ronja asks before switching. The notification in the bell carries the ID of the run that failed first instead of the link.

If you’re not sure

Ask. The run page shows who started it. A comment on your rejection is the fastest way to say what you’d need in order to say yes — they can fix it and run it again.
Rejecting is the safe answer. Nothing is lost that can’t be redone: whoever started the run can start another one. Approving something you don’t understand is the irreversible half.
Don’t feel rushed by the countdown. Letting a request expire has exactly the same effect as rejecting it — the run fails and nothing goes ahead.

If you’re an admin

Requests nobody has answered also appear in the Inbox at the top of the Shared features page, as a RUN APPROVAL row — “{workflow} run is waiting for a decision”, with the time left and how many people were asked. Clicking the row opens the run page; the decision is always made there. See Propose and review changes.

An admin can decide any request, whether or not they were named on it.

The full picture of a waiting run, including what happens if the workflow is republished while yours waits: A run that is awaiting approval.
Building a workflow that asks: Mid-run approvals.