Approvals
The central approval queue for every cost action — with savings, blast radius, rollback plan, and policy reason presented on every request.
At a glance
| Route | /approvals |
| Group | Govern |
| Page permission | approvals |
What it is
The central approval queue for every cost action in the platform. Each request presents the savings at stake, the blast radius, the rollback plan, and the policy reason for the gate — and can be decided in the dashboard, from Slack or Teams, or through Apex.
Who it is for
Engineering leads, platform owners, and FinOps approvers — anyone accountable for changes to the cloud estate.
How it works
Four facts on every request
These four facts are chosen so a decision can be made without further investigation. That is the difference between an approval queue that moves and one that becomes a bottleneck.
An enforced state machine
Approvals are a state machine with an enforced transition contract: a request that has already been resolved cannot be resolved again. This prevents both double execution and race conditions between the dashboard and ChatOps.
Every decision is recorded with actor and timestamp.
ChatOps is authorised, not just convenient
ChatOps exposes /finops pending, /finops approve, and /finops reject in Slack and Teams,
with inline approve and reject buttons on notifications.
A Slack identity alone is not authority
Incoming requests are verified by HMAC signature with timestamp replay protection, and the acting user's platform permissions are checked before the decision is honoured.
Features
- Unified queue for remediation, commitment purchase, parking, and cloud action approvals
- Savings at stake shown per request
- Blast radius assessment
- Rollback plan stated before approval
- Policy reason explaining why the gate exists
- Enforced state machine preventing double resolution
- Slack and Teams approval with inline buttons and slash commands
- HMAC signature verification and timestamp replay protection
- Actor authorisation against platform permissions
- Full audit trail of every decision
How to use it
Configure an alert channel first
In Integrations.
Approval queues that live only in the dashboard are not checked often enough to avoid becoming a bottleneck. This is the single most important configuration step for this module.
Review each request against the four facts
Savings, blast radius, rollback plan, policy reason. If you need to leave the request to decide, something upstream is under-specified.
Approve or reject — adding a note on rejection
So the requester understands the decision rather than resubmitting the same thing.
For routine low-risk classes, consider automating instead
Ask whether the execution policy in Optimization should permit automatic execution rather than consuming approver attention.
Monitor queue depth
A persistent backlog is the most common cause of optimisation programmes stalling.
Why it matters
Approval bottlenecks are the single most common reason optimisation work does not happen. The finding is correct, the fix is safe, and it sits waiting for someone to click a button.
Bringing approvals into Slack — where the approver already is — and presenting the four facts needed for a decision without requiring investigation, is what keeps optimisation velocity high while preserving human control.
Connects to
- Gates Optimization, Autopilot, Resource Parking, commitment purchases in Intelligence, and vendor decisions in Vendor Hub
- Channels configured in Integrations
- Decisions recorded in Audit Logs
Policies
The guardrail engine — required tags, blocked resource types, cost and risk thresholds, and budget limits, enforced as advisory findings or hard blocks.
Resource Parking
Scheduled shutdown — AutoStopping, off-hours parking, hibernation, and scale-to-zero in one control plane, with unsafe-schedule detection.