Approvals

Approvals let your organisation require a real decision from real people before something happens: a form request progressing, a draft project going active, a finance decision, or a step inside a workflow automation.

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.

Requests are grouped by type, including Form requests, Projects and Automations, alongside the finance groups. A failed load shows Retry approvals instead of reporting that nothing is waiting.

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. On a phone, decision dates appear below the reviewer and feedback so long comments remain readable. 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.

Only pending assignments at the current stage appear in Waiting on you. If you are also assigned to a later stage of the same finance approval, that later assignment does not hide your current decision. Each stage still needs its own decision when it becomes current.

If Ru chat offers a decision list, it shows up to ten newest requests, request age, due dates and links to the full reviews. It tells you when more requests are waiting. Request age starts when the request was created; it does not show time in the current stage or the effect of a delay. Viewing the list records no decisions or reminders.

If Ru chat offers Approve or Reject on a saved review, the choice sends one visible reply for your assigned stage and that version. If the version, stage or assignment has changed, refresh the review before choosing again. Open the approval to request changes with a reason. A saved-decision receipt confirms your decision; it does not by itself verify the underlying action.

For an expense, use View receipt to open the current attachment in a new tab without losing your comment. You need permission to read the expense and its file. If the receipt check fails, Try again reloads it without recording a decision. A completed approval still provides receipt review when you retain access. See Expenses.

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

Purchase amounts and access

Purchase-order and supplier-bill approval totals need View costs for the project or client recorded on the approval. Selling-price access alone does not show these amounts. You can review costs without selling-price access. The waiting count, hours and money cover pending requests only, including on All. Completed requests keep their own details. Approve all appears only when you can currently decide every pending request in the group. Otherwise, use the decision buttons on the requests assigned to you at the active stage. The inbox shows a waiting total only when you can see every pending amount and those amounts use the same currency. Otherwise, available amounts appear on individual rows. Without cost access, you see a general purchase approval title and the remaining nonfinancial details. Your permission to record a decision is checked separately.

Purchase approval notifications and Today reminders use a general heading. Email detail rows follow your access when the email is sent. Open the approval to review the details you can currently see. See Purchasing.

Reviewing time entry decisions

A completed time approval includes Time entry decisions with each entry’s note at decision, hours, outcome and feedback. A correction or resubmission does not replace that history. You can read this section when you still have access to the request, including requests you submitted yourself.

For older decisions, feedback is retained even when the original entry details are unavailable. If a decision is still being applied or the read fails, choose Refresh entry decisions. On a phone, scroll the table sideways to read all columns. For rates, billable minutes and corrections, use Time approvals.

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.

If you are assigned to more than one stage, decide each stage when it becomes current. Your earlier decision does not automatically decide a later stage.

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.

To reassign an existing request, open its details and choose Reassign beside a pending approver at the current stage. Select another active member and choose Save reassignment. You need approvals management permission. The updated assignment and timeline appear after saving. If another decision arrived first, the form explains the refusal; review the current request before trying again. If the member list cannot load, choose Try again.

The requester or an approvals manager can cancel a request that is no longer needed. A failed request read shows a retry option instead of an empty record.

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.

New change-order requests show Change and New total in the budget’s currency, for example +350.00 AUD and 2100.00 AUD. The sign tells you whether the proposal increases or reduces the budget. Amounts follow your financial access. Older requests keep the summary recorded when they were created.

A rejected, changes-requested or expired change-order approval closes the proposal as Rejected on its budget. Cancelling the request closes it as Withdrawn. Approved budget amounts remain unchanged. The exact decision and comments stay here in Approvals; after processing, refresh the budget’s Versions tab and open a new proposal if needed. See change orders.

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 other project activation gates. Form requests have a separate workflow completion step, described below.

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.

An already-used approval cannot activate the project again when a delayed completion arrives. If you move the project to another planning stage while an approval is pending, automatic activation checks the stage it was requested from. Review the current project before trying activation again.

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.

Form request approvals

Form requests that need an internal review appear here, including forms using Any reviewer. Open a request to read its original submitted answers and current request status. You can review the form without opening Studio.

1. Review the answers and choose Approve, Request changes or Reject.
2. Once the approval policy is satisfied, use Request workflow to complete the configured transition. Add a Request comment when one is required.
3. Choose Complete approval and create project when the transition creates a project, or Complete approval for other approval actions.
4. After successful creation, choose Open project. If creation fails, correct the cause and use Retry project creation. The recorded vote is retained.

Votes and request status are separate. Approved alone does not confirm that a project was created. Submitting a request yourself does not cast your approval vote. Your submitted requests also appear in Requested by you. Choosing Approve on a form row opens its detail page so you can complete the remaining workflow.

A delegate or reassigned approver can review their assigned request without receiving access to every submission or the form editor. Read-only viewers see the answers without workflow controls. Use Back to approvals to return to the listing, including on a phone. You can also review requests through Work > Forms > Review submissions. See the request workflow.