Put a decision between a recommendation and a change
Some savings are obvious enough to just do, and some involve resizing a production database. Approvals puts a request in between: a recommendation is sent for sign off, sits as pending until an administrator approves or rejects it, and records who decided and why.
Inputs
Where the Approvals numbers come from
Xplorr reads your accounts with read only credentials and never writes to your infrastructure. These are the sources behind this screen.
- The recommendation being acted on
- A request is raised against a specific recommendation, so the resource, the proposed change and the estimated monthly saving all travel with it. A reviewer is deciding on a concrete change rather than an abstract request.
- Who raised it and who can resolve it
- The requester and the resolving administrator are both recorded against the request, which is what makes the trail auditable afterwards.
- One open request per recommendation
- A request points at a single recommendation, and a second request for the same one is refused while the first is still pending, so two people cannot ask twice and get two different answers.
Method
How the Approvals numbers are worked out
No black box. If a figure is an estimate or an apportionment rather than a billed line, the page says so.
A request has exactly three states
Pending, approved and rejected. Keeping the state machine small is deliberate, because an approval trail with a dozen intermediate states stops being something anyone can read at a glance months later.
A decision is one way
Once a request is approved or rejected it is resolved, and a further attempt to decide it is refused rather than quietly overwriting the earlier outcome. If circumstances change, the honest move is a new request against the current state of things.
A reason is recorded with the decision
Approving and rejecting both carry a reason. A rejection without one tells the next person nothing, and six months later the reason is the only part anybody actually needs.
Requests expire rather than sitting open forever
Each request carries an expiry, set 72 hours out by default. An approval queue where requests accumulate indefinitely is one nobody trusts, because there is no way to tell a live request from an abandoned one.
Approving does not touch your infrastructure
Xplorr holds read only credentials and cannot make the change. An approval is a decision that the change should happen, and the change itself is made by your team in your own account or pipeline.
In the console
What is on the Approvals screen
- Requests with their current state of pending, approved or rejected
- The recommendation behind each request, with its resource and estimated saving
- Who raised the request and when
- Who resolved it, when, and the reason they gave
- The expiry on each pending request
- Approve and reject actions for administrators
Common questions about Approvals
Does approving a recommendation apply the change automatically?
Can an approval be reversed?
What happens to a request nobody answers?
Can approvals happen in Slack?
Background reading
How an approval step fits into a chat based cost workflow is covered in How AI is changing cloud cost management.
Related features
How this compares
See this on your own accounts
Connect a cloud account with read only credentials and the first sync pulls your last 30 days, so this screen fills with your numbers instead of the demo workspace. Free during beta.