# Reviewing Requests

Source: https://docs.ops0.com/docs/developer-portal/approvals

Requests that need sign-off — because their blueprint's approval policy is `required`, or because a `conditional` blueprint saw a value outside its presets — land in the **Approvals** inbox. This page covers the approver-facing side of the [Developer Portal](https://docs.ops0.com/docs/developer-portal/overview).

**Who sees this**

The Approvals button and panel only appear for users with permission to review Developer Portal requests. The server enforces this independently of the UI — a developer without approver access who lands on the URL directly is bounced back to the catalog with a restricted-access message.

---

## The Approvals Inbox

Opening **Approvals** shows a stat strip — **Awaiting review**, **Approved**, and **Rejected** counts — followed by two sections:

| Section | Contents |
|---------|----------|
| **Awaiting review** | Every request in `pending_approval`, oldest first, each with inline **Approve** / **Reject** buttons |
| **Recent decisions** | The most recently decided requests (approved or rejected), for quick reference |

Each row shows the blueprint icon, project name, blueprint name, environment, provision type, cloud, estimated monthly cost, time since request, and current status.

---

## Reviewing a Request

Click a row to open the full request detail rather than deciding blind from the inbox row. The detail view has the same four tabs a requester sees:

### Check Overview
See the environment, who requested it, when, the estimated monthly cost, and — critically — whether it used custom values outside the blueprint's guardrails. A flagged banner reads: "This request uses custom values outside the preset guardrails, so it required approval."

### Check Configuration
Every variable value the requester submitted, exactly as they entered it.

### Check Deployment
If the request already started provisioning, see the live plan/apply status. For a still-pending request this tab shows nothing has been provisioned yet.

### Decide
With the note field, optionally add a message for the requester, then click **Approve & provision** or **Reject**.

You can also approve or reject directly from the inbox row with the quick-action buttons — this skips the note field.

---

## Approve / Reject

| Action | Effect |
|--------|--------|
| **Approve** | Status moves to `approved`, then `active`; the IaC project is created and a read-only plan runs automatically — it never applies. The decision and any note are recorded on the request |
| **Reject** | Status moves to `rejected`; the decision and any note are recorded, and the request stops there — nothing is provisioned |

Both actions record who decided and when, and are visible afterward on the request's **Overview** tab and in its **Activity** timeline.

**Approval provisions the project, not the change**

Approving a request creates the IaC project and runs a plan — the same plan-only behavior as an auto-provisioned request. Applying the plan is a separate, manual step in the project itself.

---

## Decision History

The **Recent decisions** section of the inbox surfaces the latest approved and rejected requests without needing to search My Requests. Each decided request keeps its full record — decided-by, decided-at, and any note — permanently on the request's Overview tab, so both requester and approver can review why a call was made after the fact.

---

## Related

- [Requesting Resources](https://docs.ops0.com/docs/developer-portal/requesting-resources): How developers browse the catalog and submit requests.

- [Developer Portal Overview](https://docs.ops0.com/docs/developer-portal/overview): Provision types, approval policies, and presets/guardrails.

- [Publishing Blueprints](https://docs.ops0.com/docs/developer-portal/publishing-blueprints): How approval policies get set in the first place.