Approve remediations without leaving Slack

An owner or admin connects Slack from Settings → Notifications, using Slack’s standard app install. The install request is signed and tied to the browser that started it, so a copied install link cannot be completed by someone else.

The bot token Slack returns is stored encrypted with AES-256-GCM and is never included in what the settings page reads back. Disconnecting removes the install and every linked Slack account, and is recorded in the audit trail.

• The app asks Slack for permission to post messages, including in public channels it has not joined.
• It can list public and private channels.
• It can read user profiles, including email addresses.

Each workspace sets one approvals channel by its Slack channel ID, and the settings page asks you to invite the GetFinOps bot to it. You can also set a channel per cloud account under Settings → Automation Safety, so approvals for a production account go to a production channel. An account without its own channel uses the workspace channel.

Each card shows:

• the action and the resource it targets;
• the finding’s description, estimated monthly saving and severity;
• the cloud account, by label and account ID;
• Approve & execute, Dismiss, and a link to the remediation page in GetFinOps.

A click from Slack arrives without a GetFinOps login, so every check runs again on the server before anything changes.

• The request must carry a valid Slack signature and be less than five minutes old.
• The Slack workspace must be the one connected to this GetFinOps workspace.
• The Slack user must be linked to an active GetFinOps user in that workspace. People are never matched by their Slack email address.
• That user’s role is read from GetFinOps and must be owner or admin.
• The approval must belong to the same workspace and still be pending. Only the first decision is recorded.
• Approving needs a paid plan or an active trial. Dismissing works on any plan.

The decision is recorded in the audit trail against the approver, marked as made in Slack. An approved change then runs through the same execution path as an approval made in the dashboard. If the account is labelled production or has no label, the default production block stops it unless the account’s safety policy allows production or the block is overridden. The guardrails, the post-check and, for reversible actions, automatic rollback also apply.

The same card is then updated. Its buttons are removed, and it shows the outcome: executed, rolled back after a failed post-check, blocked by the safety policy, or failed with the reason. A dismissed request updates the card to say no changes were made.

If the safety policy stops a run, for example on an account marked as production, GetFinOps can post a notice to the app’s notifications. This is off by default. You turn it on for the workspace or for a single account in Settings → Automation Safety.

Where Slack is connected, a Slack card also names the account and shows the action, resource, environment and reason, and a linked owner or admin can press “Override & run once”. Admins can also override a block in the app.

• An override lifts only the production block, for one run of that approval.
• Permanently blocked actions, such as terminating instances or deleting databases, stay blocked, and every other guardrail still runs.
• Each block can be overridden once, and the override is recorded in the audit trail.
• If that action type was allowed to run on its own, it drops back to “approve each”.

• It does not let members or viewers approve or dismiss.
• It does not take commands or answer questions in Slack. The app posts cards and handles their buttons.
• It has no channel picker; channels are set by Slack channel ID.
• It does not send safety-block notifications until you turn them on.
• It is not switched on for self-hosted installs.
• It does not widen what can be changed: remediation runs in AWS only.