Approvals

Approvals let your organisation require a real decision from real people before something happens: a draft project going active, a step inside a workflow automation, or anything else a manager wants signed off.

Every approval carries the full detail of what is being decided: a summary of the item, links to the related records, who asked, and when it is due. Approvers never have to hunt for context.

Your approvals inbox

Open Approvals in the sidebar. The page has up to four views:

• Waiting on you shows approvals where your decision is still needed.
• Your assignments shows everything you have ever been asked to approve.
• Requested by you shows approvals you raised.
• All shows every approval in the organisation. This view needs the Manage approvals permission.

Open an approval to see the request in full: the summary rows, links to related records, every approver and their decision, and a timeline of everything that has happened. If it is waiting on you, choose Approve, Request changes, or Reject. A comment is optional when approving or rejecting and required when requesting changes, so the requester always knows what to fix.

Approvals that are waiting on you also appear on your Today widget.

Delegating while you are away

If you are going to be unavailable, set a delegate at the bottom of the Approvals page: choose a person and, optionally, an end date. Approvals created while the delegation is active go to your delegate instead of you, and their card shows they are covering for you. Approvals already sitting with you stay with you. If your delegate is already named on the same approval, the substitution is skipped so one person never holds two votes. Choose Stop delegating to end it early.

Deciding from an email

When you are named as an approver, Runnit sends you an in-app notification and an email. The email shows the request details and two buttons: Review and approve and Review and reject. Either button opens the approval in Runnit. Sign in if you are not already signed in, review the detail, and confirm your decision.

Email links are single use and expire. If the approval was already decided, the page shows the outcome and the timeline instead of decision buttons.

Who has to approve

Each approval names its approvers: specific people, user groups, or both. A group counts as its current active members at the moment the approval is created. The decision rule is one of:

• First response decides. The first approver to respond settles it, whether they approve or reject.
• All must approve. Everyone named has to approve. A single rejection rejects the request.
• Quorum. A set number of approvals is enough. If enough people reject that the quorum can no longer be reached, the request is rejected.

Under every rule, a single Request changes decision closes the request immediately with the approver’s comment, so blocking feedback is never outvoted.

An approval can also run in stages: sequential steps, each with its own approvers and decision rule. Only the current stage can decide. When a stage approves, the next stage’s approvers are notified; if any stage rejects or requests changes, the whole request closes.

Once a request is decided, the remaining approvers are stood down and see the outcome instead of a pending decision. The first decision each approver makes is final.

When an approver is removed from the organisation, their seat on each gate and any approval still waiting on them pass to the person chosen during the removal (or to the admin who removed them), so no request is left waiting on someone who has gone. See Managing Users.

An approvals manager can reassign a pending approval from one person to another, and the requester (or a manager) can cancel a request that is no longer needed.

Budget change orders use the same engine with one difference: their policies carry rules (for example an amount threshold), every rule in a policy must match, and each matching policy adds a stage of its own. See Finance Setup.

Three more finance requests arrive in the same inbox, grouped under Time approvals, WIP adjustments and Period reopens: a person’s submitted week (one request per budget, decided by the approvers that budget names, with per-entry outcomes and edits), a proposed write-off of unbilled work, and a request to reopen a closed month. A decision made here lands on the time, budget or period exactly as one made on the Finance pages. See Time Tracking, Uninvoiced Work and Month End.

Requiring approval to activate a project

An administrator can require approval before any draft project moves to an active stage. Open Settings → Approval gates, enable Project activation, choose the decision rule, and pick the approvers (people or groups). An optional due time sends approvers a reminder at the halfway point; what happens when it passes is up to you: expire the request (the default), auto approve, or auto reject.

When the approval is granted, Runnit activates the project on the requester’s behalf straight away; nobody has to come back and press the button. If activation is still blocked by something else (a missing budget, for example), the requester is told exactly why; the approval stays valid, so fixing the issue and activating manually still works. The same applies to every other gate: an approval always carries out the change it was asked for.

If the person activating is one of the gate’s approvers, they are never asked to approve their own project. With first response decides, pressing Activate project activates it straight away and records their approval; with everyone or a quorum, their vote is recorded and the other approvers are still asked. You are not emailed about your own activation. This does not apply when segregation of duties is on in Finance settings.

On the Approvals page, a request waiting on you shows Approve and Reject on the row itself, so you can decide without opening it. Reject opens the request so you can say why.

One more option on the gate:

• Per-client overrides. Below the default gate you can add a different rule for a specific client organisation: different approvers, a different decision rule, or no approval at all for that client. The most specific rule wins.

With the gate enabled, activating a draft project from anywhere (the project page, a Kanban board, brief activation, an automation, or the API) is blocked until an approval is granted:

1. Try to activate the project. Runnit tells you approval is required and offers Request approval.
2. The configured approvers are notified and decide.
3. Once approved, you are notified. Activate the project and it goes through.

Each approval covers one activation. If the project is moved back to draft later, activating it again needs a fresh approval. A rejected request also needs a fresh request once the concerns are addressed.

Approvals inside automations

Workflow automations can pause and wait for a decision with the Request approval step. The run waits as long as it takes (hours or days) and then continues along the approved, rejected, or timeout path. The step also works inside a loop, so a run can seek sign-off per item. See Workflow Automations for how to build one.

Deciding from outside Runnit

Organisations that run their approvals through another system (Microsoft Power Automate, for example) can send decisions into Runnit. An administrator opens Settings → Approval gates, enables the External decisions webhook, and copies the signing secret (it is shown once; you can rotate it at any time). The external flow then posts the decision, signed with that secret, naming the approval and the approver’s email address. The decision is recorded exactly as if that person had decided in Runnit: the same rules, stages, and audit trail apply, and the approver must be an active member of the organisation.

Permissions

• Anyone can be named as an approver and can always see and decide their own assignments.
• An approval is visible to its requester, its approvers, and holders of the Manage approvals permission. Other members cannot see it.
• Manage approvals (administrators by default) also covers creating standalone approvals, cancelling or reassigning any request, and configuring approval gates.