Approvals inbox
What this page is — your personal decision queue: every document waiting on you, plus the two lists that explain an empty queue.
What it is for — so an approver clears everything waiting on them in one place, with each decision recorded against the document.
The problem it solves — approvals by email leave no reliable record of who agreed to what, and documents stall with nobody aware they are waiting.
Route: /org/papers/approvals · Permission: Act on approval steps (approve/reject/return). to decide;
the AI advisor also needs the Papers AI permission
1. What it is
The page stacks up to three sections, in this order:
| Section | Contains | Who can act |
|---|---|---|
| Waiting for a decision — not routed (n) | Documents in an approval state whose type has no workflow, so nobody was assigned | Anyone with approval rights — except the submitter, who only sees moves that send it back |
| Your approval cards | Steps a workflow assigned to you | You |
| Waiting on someone else (n) | Documents in approval where the current step is not yours. Title and submitter only | Nobody here — informational |
When there is nothing at all you see No documents waiting for you. If nothing is awaiting anyone either, the page adds: "Nothing is awaiting approval anywhere you can see, either — so there is nothing this page is failing to show you." The third section exists so that an empty inbox is never mistaken for a broken one.
2. Why you would use it
- Decisions without hunting. Everything you must decide is in one list, and each card carries enough to act without opening the document.
- Every decision is evidence. Approve, reject and return write your name, the time and your comment to the document's audit trail. Email approvals leave nothing reliable.
- Gaps in configuration become visible. The unrouted section and the owner-fallback banner show where a type's routing is incomplete — nothing else notifies anyone about these.
- A second read when stakes are high. Routing advice and a risk brief surface problems before you put your name to them.
3. Step by step — deciding a routed card
-
Read the card:
- the title (opens the document);
- submitted by … · date;
- any amber banner;
- the path pills.
-
Optionally run Routing advice or Risk brief under AI advisor.
-
Write a Comment. It is optional for Approve, but always write one for Reject or Return.
-
Click one of the actions the step allows:
Action Effect Approve Records approval and advances to the next step, or completes the workflow Reject Confirms first — "Reject this document?" / "The document is rejected and returned to its owner. Add a comment first so they know why." Return Sends it back for correction and keeps the workflow alive — prefer this for anything fixable -
The card disappears. A toast confirms, e.g. "Approve recorded".
Only the actions your step permits are drawn. If there are none: "No actions available for you on this step." While a decision is saving, every button on the page is disabled, which prevents a double approval.
Deciding an unrouted document
Unrouted cards show buttons named after the type's own lifecycle transitions, e.g. Approve or Issue certificate. Hovering shows "Moves the document to …". Deciding here follows the approval rules in submitting for approval: approval rights are needed, and nobody may approve their own submission.
4. Field reference — reading a card
| Element | Meaning |
|---|---|
| Path pills | One per step, in order, with the approver where known |
| Ringed pill | The current step |
| Green / red / amber / grey | Approved / rejected / pending / not reached or other |
| Amber banner with a warning icon | Why you got a step you were never named for, e.g. "Routed to you as the organization owner: the step's persona (reporting manager) resolved to nobody on this document." |
| Comment | Goes to the submitter and into the audit trail |
The AI advisor
| Button | Capability | Returns | Page |
|---|---|---|---|
| Routing advice | approval_route | Whether the route suits this kind of document, and which gates look missing | Approval routing |
| Risk brief | risks | The clauses and terms most worth reading before approving | Risk analysis |
Both are read-only. They never approve, reject or edit anything, and each run uses AI credits. Results appear on the card they belong to.
5. Messages you may see
| Message | Meaning |
|---|---|
| "Failed to load pending approvals" | The list could not load — refresh |
| "Approval instance id missing — refresh and retry" | The card is stale; another approver may have acted |
| "Failed to process the approval" | The decision was not recorded — try again; the card stays until it succeeds |
6. Worked example
Priya, Head of Finance, opens the inbox on Monday.
- Not routed (1): Training certificate TC-0412, sitting in pending issue. Its type has no workflow. Priya did not submit it, so she clicks Issue certificate. She also asks the admin to give that state a workflow.
- Her card: Vendor Agreement VA-2026-077, submitted by Arjun. The path shows green Manager approval, ringed amber Finance, and grey Legal. An amber banner explains that step 1 fell back to the organisation owner.
- She runs Risk brief. It flags that the limitation of liability excludes data breaches.
- She clicks Return with the comment "Clause 12.3 excludes data breach from the cap — align with our standard DPA wording and resubmit." The card disappears. Arjun receives the comment, and the document is editable again.
- Waiting on someone else (2): two contracts are with Legal. She has nothing to do on them, but now knows the queue is not stuck with her.
7. The admin contract
| What must be configured | Otherwise |
|---|---|
| Act on approval steps (approve/reject/return). on approvers' roles | No actions appear on unrouted documents |
| A workflow on every approval state | Documents accumulate under not routed and nobody is notified |
| Personas that resolve, e.g. reporting managers recorded in People | Steps fall back to the organisation owner (the amber banner) |
| Workflow steps that allow Return where correction is normal | Approvers only have Approve or Reject |
| Papers AI permission and credits | The AI advisor is hidden |
8. Downstream
- Approve on the last step completes the workflow, and the document moves to its next state.
- Return puts the document in an editable state such as returned, and the author resubmits.
- Reject ends the workflow and returns the document to its owner.
- Every decision appears in the document's Activity and in approval analytics.
9. Don't confuse this with…
| Documents list | Everything in the project. This page is only what awaits decisions |
| Lifecycle and transitions | Defines when approval is needed. This page is where it happens |
| Sending for signature | A party's signature, usually after approval |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| Empty, but colleagues say things are waiting | They are under Waiting on someone else — the current step belongs to another approver |
| A document nobody assigned to you | Unrouted section (no workflow), or the owner-fallback banner |
| An unrouted card offers you only Return or Withdraw | You submitted it — you cannot approve your own |
| A card with no buttons | Your step permits no action, or another approver on a shared step already acted |
| Approved, but the document did not move on | Later steps are still outstanding — check the path pills |
| No AI advisor | You lack the Papers AI permission |