> For the complete documentation index, see [llms.txt](https://docs.emseapea.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.emseapea.ai/admin-guide/approvals.md).

# Approvals

The Approvals queue shows every request waiting for a decision, newest first. Each card shows the title, purpose, requested systems, and — the part that actually matters for what you're deciding — **which kind of access each system asked for**: only what the requester can already see, or wider access set up by IT. Off-list systems and sensitive information are badged too, but those are routing flags, not the access decision itself.

A request whose systems are entirely **"only what the person using it can already see,"** and entirely on your allow-list, never reaches this queue at all — it's approved automatically the moment it's submitted, because it can't show anyone more than they could already see by signing in directly. What you see here is everything else: any use of a prepared account ("wider access, set up by IT"), or any system not yet on your list.

Whenever a request asks for a prepared account, you'll see the exact same sentence the requester saw, naming which account and what it's limited to — read live from the current catalogue, so if an admin edits that limit later, what you see here always reflects the current truth, not what was true when the request was submitted.

Three decisions:

* **Approve** — creates the app, provisions a repository from your approved template, and issues a short-lived scoped credential through your gateway.
* **Request changes** — sends the request back to the builder with your note.
* **Reject** — closes it with your note.

The requester is notified by email either way, and the decision (with the decider's identity) becomes part of the app's permanent record. An automatic approval is logged too — distinguishable in the audit trail from a human's decision — so "why did this go live with no one deciding" is always answerable.

Requests flagged **requires admin review** (off-list systems) can only be decided by an org admin, regardless of which kind of access they asked for.

## What "kind of information is involved" does and doesn't do

A request also records what kind of information is involved — public, everyday work information, or something sensitive. **This doesn't restrict what the app can see; it never has.** The systems and the access kind above are what actually determine that. Ticking a sensitive class only decides whether a colleague has to sign off before each future deploy, and it's recorded in the audit trail regardless of which way it goes. Describing it as a control on what the app can reach has misled people before — it isn't one.

## Sensitive deploys

Apps whose intent declares commercially sensitive, personal, financial, or health information pause before every deploy for an approver's sign-off — see [Dashboard and risk flags](/admin-guide/dashboard-and-risk.md) for where these surface.