Skip to content

Approvals: Sign Off on High Value Recommendations Before They Are Acted On

Approvals put a human checkpoint in front of acting on a cost recommendation. Someone asks to act on a recommendation, an admin signs off, and only then does the recommendation move forward.

This is useful when the people spotting savings are not the people authorised to change production, which is the normal arrangement in most organizations.

Approval workflows are an enterprise plan feature.

The Approvals page in the console is for reviewing and resolving requests. It does not create them.

Requests are raised from the Slack and Teams bot, where someone acting on a recommendation whose estimated savings pass the approval threshold gets a request created instead of an immediate action. They can also be raised through the API.

So the normal flow is: someone hits a large recommendation in Slack, a request appears here, an admin resolves it.

Open Approvals. Four tabs hold the requests by state, each with a count.

StateMeaning
PendingWaiting for an admin
ApprovedSigned off
RejectedDeclined, with a reason if one was given
ExpiredNobody resolved it in time

Each request shows the recommendation it points at, its type, the service and provider, who asked and when, the estimated monthly savings, and how long is left before it expires.

Admins see Approve and Reject on every pending request. Everyone else can read the page but not resolve anything.

Approving moves the recommendation to in progress. That is a status change on the recommendation, not an action against your cloud account: Xplorr stays read only and never modifies infrastructure. Somebody still has to make the change.

Rejecting leaves the recommendation exactly as it was. You can attach a reason of up to 2000 characters, which is shown to the requester, and it is worth writing one. “Rejected” with no explanation invites the same request next week.

Both outcomes are recorded in the audit log with who resolved it and when. Approvals also emit a recommendation status change webhook, so you can drive downstream automation from it.

A request expires 72 hours after it is raised. The page counts down, and highlights a request in amber when it has under 12 hours left.

An expired request cannot be approved. If the work still matters, raise it again.

This is a deliberate default: an approval queue that never expires silently becomes a backlog nobody trusts.

Two admins reaching the same request at once is handled rather than raced. If a request was already resolved, or has expired since the page loaded, you get told which, and the original outcome stands.

“Nothing waiting for approval”

No pending requests. Requests appear when someone asks to act on a recommendation whose savings pass the approval threshold, from Slack or the API.

The page says approval workflows need a different plan

Approval workflows are an enterprise feature.

I cannot approve anything

Only admins can resolve requests. Others can review them.

A request expired before anyone saw it

Requests last 72 hours. Route approval notifications to a channel an admin actually watches; see Channel Routing.

Approving did not change anything in my cloud account

Correct. Approving moves the recommendation to in progress. Xplorr never modifies cloud resources.

Can I approve from Slack? Yes. See Approval Workflows for the bot side.

Can I create a request from the console? No. The console reviews and resolves. Requests come from the bot or the API.

Does rejecting dismiss the recommendation? No. The recommendation is untouched and will still appear in your recommendations list.

Who can see the page? Anyone in the organization. Only admins can act.