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.
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.
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.
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:
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."
Every variable value the requester submitted, exactly as they entered it.
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.
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.
| 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.
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.
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.
