Inbox
Review pending requests that require an approval decision. Use Assigned to me to list only requests where you can decide and have not already approved at the current level.
Approvals
Open Operations → Approvals for your decision inbox. Axio routes pending items here when a workflow gate pauses a stack deployment, when a Platform as Code synchronization plan requires sign-off, or when a policy-driven approval is raised.
Why approvals?
They enforce change control, meet compliance requirements, and reduce the risk of unintended production changes — whether from a deployment workflow or a Git-driven platform sync.
Request types
Pending items are grouped into three categories in the inbox:
| Type | When it appears | Typical scope |
|---|---|---|
| Platform as Code | A Git synchronization plan needs manual sign-off because the repository policy requires manual approval, and/or the plan includes updates or pending removals on resources marked sensitive (metadata.sensitive: true or label/annotation platform.axio.io/sensitive) | Repository or resource name (often shown as Git synchronization) |
| Workflow | A stack deployment reaches an approval stage in its workflow | Environment or project (e.g. Production) |
| Policy | Other governance or policy-driven approval requests | Varies by policy |
Platform as Code note
Staged removals (pending_removal) alone do not always require approval — only when manual approval is configured for the repository or the removal affects a sensitive resource. New creates of sensitive resources follow the repository execution mode unless manual approval applies to the whole plan.
The Approvals page brings together requests from Platform as Code sync plans and workflow gates. Policy-class items also appear with the request type Policy.
History
View completed requests. This tab is visible only to users with approval:manage. Authorized users can remove entries from history.
Search and filters
Search by title, environment, requester, policy, status, and related fields. Category chips at the top show pending counts for Platform as Code, Workflow gate, and Other.
Understanding the request table
Each row provides the following information:
Request typePlatform as Code, Workflow, or Policy.
NameThe request or associated resource name.
ScopeThe applicable environment, project, or resource.
StatusThe current request state.
Requested byThe person who initiated the request.
Approved byThe approver or approvers recorded for the request.
WaitingRequest age, optional expiry, and a Your decision chip when applicable.
ActionsUse Review to open a pending request.
Reviewing a request
Click a row or select Review to open the detail dialog. Add an optional comment, then select Approve or Reject. The table supports pagination.
| Type | When it appears | Typical scope |
|---|---|---|
| Platform as Code | A Git synchronization plan needs manual sign-off because repository policy requires manual approval, and/or the plan includes updates or pending removals on sensitive resources marked with metadata.sensitive: true or the label/annotation platform.axio.io/sensitive. | Repository or resource name, often shown as Git synchronization. |
| Workflow | A stack deployment reaches an approval stage in its workflow. | Environment or project, such as Production. |
| Policy | Other governance or policy-driven approval requests. | Varies by policy. |
01 Workflow reaches an approval stage Deployment pauses
02 Request created and notified Approvers are notified
03 Approver reviews the request Review details and comment
04 Approved or rejected Decision is recorded
05 Workflow continues or stops Outcome is applied
✓ Approved
The workflow resumes.
✕ Rejected
The deployment run does not proceed.
You can also approve or reject a request from the stack deployment / workflow run detail view when the run is paused at an approval stage. The same request appears under Operations → Approvals.
Break Glass can bypass the gate
If Break Glass is active for the target environment, the workflow may bypass the approval gate and no inbox item is created.
Environment approval settings
Environment-level approval can be disabled when the environment policy is off or set to none. Otherwise, if an environment-specific policy is missing, workflow gates default to manual approval behavior.
When a synchronization plan requires approval, the sync run stays in awaiting approval (plan pending) until a decision is made.
✓ Approve
Applies the Git reconciliation plan.
✕ Reject
Leaves platform resources unchanged.
You can approve or reject requests from Platform as Code → Synchronizations in the Recent runs section. This uses the same approval requests as Operations → Approvals.
Request details
The Platform as Code request detail dialog summarizes the plan and provides a link to Open synchronizations.
Go to Synchronizations →Requests can be in one of the following states.
| State | Description |
|---|---|
| Pending | Waiting for an approver decision. May show time remaining until expiry. |
| Approved | Approved manually; the workflow or sync plan can proceed. |
| Rejected | Rejected by an approver; the workflow stops or the sync plan is not applied. |
| Auto approved | Approved automatically by policy; no manual action is required. |
| Emergency approved | Approved through emergency break-glass on the approval policy when enabled (API); this is not a separate button in the Operations Approvals dialog today. |
| Expired | The approval window elapsed; the outcome depends on the policy expiry action. |
| Canceled | The underlying run or request was canceled before a decision. |
Multi-level approval policies
When more than one level is configured, the request detail dialog displays a stepper. Each level may require one or more approvers before the request advances.
Organization permissions
Organization Owner and Admin roles include these capabilities by default and can see organization-wide requests when scope rules allow.
Approval policies can define notification channels, including in-app notifications, email, Slack, and Microsoft Teams. When configured and integrated, the platform sends notifications for relevant request lifecycle events.
In-app
Governance notifications and approval updates.
Email
Policy-configured email notifications.
Slack and Teams
External channels when configured and integrated.
Workflow gate requests also raise governance in-app notifications to organization administrators when a deployment approval is requested.
Decision history and delivery tracking
The Operations request detail dialog shows previous decisions and optional comments. Notification delivery history is stored for the request but is not displayed in that dialog today.