Approve a workflow run

Who can do this

Anyone named as an approver on the request can decide it — no particular role required. Admins can decide any request. Others who can open the run can stop it, but not let it through.

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.

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:

1. Awaiting approval, and under it the question — written by whoever built the workflow, in their words.
2. 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.
3. A deadline — Expires in 6 days or similar.
4. A Comment box. Optional; the note goes to whoever started the run.
5. 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, with your name and the time, for anyone who looks at the run later.

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

There is no “approve everything”

Every request is decided on its own. There’s no way to pre-approve a workflow’s future runs from here, and approving one run says nothing about the next.

If you were asked in a chat instead

A few older workflows carry a legacy Pre-run approval gate — labelled Deprecated on the workflow’s page — which stops the run before it starts rather than part-way through. Those are decided in the conversation the run was started from, on the strip above the composer, and never on a run page; the mail you get has Approve and Reject buttons that open a confirmation page instead of a Review and decide link. Everything else on this page still applies. Whoever built the workflow can ask Ronja to convert it — see Approval before a run.

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.

More

• 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.