Approval queue

The approval queue is where admins review vault shares held for sign-off. Nothing reaches the recipient until an admin approves it.

What feeds the queue#

A share lands here when your sharing policies say it needs review. There are three ways:

• Require Admin Approval is on — every new share goes through the queue.
• Approve external shares of organisation vaults is on — only a share of an organization vault to someone outside the organization is held; everything else goes straight through.
• A vault's own sharing policy requires approval for that vault.

With the policy that applies on, the share is created in a pending approval state and the recipient gets nothing until an admin acts.

How the flow works#

1. A member shares a vault or item. The server checks your sharing policy and, because approval is required, marks the invitation Pending approval instead of delivering it.
2. The invitation appears in Organization → Vault governance → Approval queue for the organization's administrators.
3. An admin approves — the invitation moves to pending and the recipient can now accept it as a normal share — or rejects it, giving a reason that is sent to the member who asked.

Only people holding the built-in Organization Administrator role can see and decide the queue. This is a check on that role, not on a permission, so a custom role — even one that can change every organization setting — is refused. The Home page's Pending approvals tile follows the same rule and is not shown to anyone else. See the organization Home.

Two rules that catch people out#

You cannot decide your own share — not even as an administrator. If you share something while the approval policy is on, your own request goes in the queue and a different admin has to release it. The entire value of the queue is the second pair of eyes; an admin approving their own share is the queue agreeing with itself, and the audit entry it would leave reads like a review that never happened.

The first decision wins. Two admins opening the queue at the same time is normal, not a fault. If somebody else has already decided a request, you are told it has already been decided rather than shown an error — you did nothing wrong, and there is nothing to retry.

Rejecting needs a reason#

A rejection will not go through without one, and the reason is delivered to the member who made the request. This is deliberate: a refusal that explains nothing teaches people to submit the same request again, which is how an approval step stops being a review and becomes an obstacle everybody routes around.

Reviewing the queue#

Find it under Organization → Vault governance → Approval queue. The page is titled Approval Queue.

The header shows which policies are feeding the queue: All vault shares · On/Off and Organization vaults leaving the organization · On/Off, and an Edit policy → link to the sharing policies.

The summary strip shows three figures: Waiting on you (how many requests are open), Oldest request (how long the longest-waiting one has waited) and Expiring within 48 h (how many will lapse in the next two days).

The list is oldest first. Each card shows:

On the card	Shows
Vault name	What is being shared, and how long ago it was requested (hover for the exact time)
Sender → recipient	Who asked and who would receive access
Access level badge	The requested access level
Can re-share	The recipient would be allowed to share it onward. Pay attention to this one
Expires …	When the invitation lapses if it is not accepted; red when under 48 hours away
Quoted message	The note the sender wrote, if any

1. Go to Organization → Vault governance → Approval queue.
2. Check the sender, recipient, and access level. Pay extra attention to external recipients and Manager-level requests.
3. Select Approve to release the invitation to the recipient, or Reject. Rejecting opens a box titled Why are you rejecting this share?; write the reason and select Reject and tell them. The reason is shown to the sender.

The Approve and Reject buttons are hidden — not greyed out — while the subscription is read-only. Requests keep arriving and stay pending until it is active again.

When there is nothing in the queue you see one of two messages:

• Sharing approval is off — both approval switches are off, so vault shares go straight to the recipient. An Open sharing policy button takes you to the policies. The queue can still fill from a vault whose own policy requires approval, which is why the message does not say it never will.
• You're all caught up — approval is on and nothing is waiting.

Audit trail#

Every decision is recorded in the tamper-evident audit log on the admin / organization stream, tied to the acting admin and the invitation: approvals as INVITATION_APPROVED and rejections as INVITATION_REJECTED.

Both are recorded at high severity. A refusal and a permission are the same decision with opposite signs, and grading refusals lower is how a queue's rejections end up below an auditor's severity filter.

Related#

• Invitations & approvals — the member's view of this flow
• Roles & permissions — who can act on the queue