> ## Documentation Index
> Fetch the complete documentation index at: https://docs.porcia.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Requests

> A structured workflow for employees to request app access — at /requests in the top-level sidebar.

**Requests** is a top-level item in the sidebar at `/requests`. It gives employees a structured path to request access to software, and gives admins a central queue to review and act on those requests — with every decision logged.

## The Requests page

The page shows a queue of all access requests submitted in your workspace, split into:

* **Pending** — requests waiting for a decision
* **Approved** — requests that have been approved
* **Denied** — requests that have been denied

Each request row shows the requester, the app they asked for, submission date, and current status.

## How an employee submits a request

Employees navigate to **Requests** in the sidebar and click **New Request**. The form collects:

* App name or URL
* Business justification — why they need it
* Urgency — standard or urgent
* Any additional context

<Info>
  Any workspace member can submit a request. Admin access is not required to request an app.
</Info>

After submitting, the requester gets an in-app notification confirming the request was received. Admins are notified immediately.

## Reviewing requests (admins)

### Opening a request

Click any pending request to open the detail view. You see:

* Requester name and submission date
* App requested — if it's already in the catalog, a link to its detail page appears alongside its current approval status and risk level
* Business justification the employee provided
* Similar apps already approved in your catalog — useful for suggesting alternatives

Pia can assist here: ask "What's the risk level of \[App]?" or "Do we already have an approved alternative?" directly in the Pia chat to get context without leaving the page.

### Approving

1. Click **Approve**
2. Add an optional note (shown to the requester)
3. The requester is notified immediately
4. Optionally add the app to the catalog if it isn't already there

### Denying

1. Click **Deny**
2. Add a note — **this is shown to the requester**, so be specific. "We already use Notion for this" is more useful than "Denied."
3. Optionally suggest an approved alternative
4. The requester is notified with your note

### Asking for more information

If you need more context before deciding:

1. Click **Request More Info**
2. Type your question
3. The requester gets a notification and can respond
4. The conversation is threaded inside the request detail

## Notifications

**Admins** are notified when:

* A new request is submitted
* A requester responds to a follow-up question

**Requesters** are notified when:

* Their request is approved or denied
* An admin asks for more information

Configure notification channels (in-app, email, Slack, Teams) in **Settings → Notifications**.

## Audit trail

Every action on every request is logged:

* Submission timestamp and requester
* Every status change with actor and timestamp
* All notes and messages between requester and approver
* Any catalog actions taken after approval

## Routing with rules

Set up a [Rule](/governance/rules) to auto-route or auto-notify on specific request types — for example, automatically notify a specific team member when a security tool is requested, or create a finding when a high-risk app is requested.

## Next steps

<CardGroup cols={2}>
  <Card title="Rules" icon="bolt" href="/governance/rules">
    Auto-route or alert on specific request types
  </Card>

  <Card title="Apps catalog" icon="building" href="/features/vendor-management">
    Add approved apps to your catalog
  </Card>

  <Card title="Shadow IT" icon="eye-slash" href="/governance/shadow-it">
    See apps employees use without going through requests
  </Card>

  <Card title="Roles & permissions" icon="shield" href="/workspace/roles-permissions">
    Set up who can approve requests
  </Card>
</CardGroup>