Slack access requests

The /governax command turns an access request that would otherwise happen in a direct message into a decision with a permanent record.

What this is, and is not#

Access requests normally happen in direct messages and disappear. Someone asks for production access, someone else says yes, and six months later nobody can reconstruct who approved it or on what basis. This flow keeps the conversation in Slack while putting the outcome somewhere permanent.

Raising a request#

1. 1

   Type the command

   /governax

   Type it anywhere in the workspace. It takes no arguments: anything typed after the command is ignored, and there are no subcommands.

2. 2

   Fill in the two fields

   A dialog asks what you need, in free text, and who should approve it. Describe the access the way you would to a colleague. There is no required format.

3. 3

   Submit

   The approver receives a direct message with your request and two buttons. The request is recorded as pending at this point, before anyone has decided anything.

Approving or denying#

The approver sees the request and chooses Approve or Deny. The message updates in place to show the outcome, so the record in Slack matches the record in the ledger and there is no stale pair of buttons left behind.

Any Slack user who receives the message can press the buttons. Governax does not check that the tagged approver holds a particular role, in Slack or in Governax. The record shows who actually decided, which is the auditable fact, but it is not a control.

What lands in the ledger#

Request and decision share a correlation identifier, so the pair can be matched. Both are ordinary ledger events: append-only, hash-chained, and covered by verification like everything else. Filter the ledger by event type decision.* to see the decision history on its own.

The request is also tracked as a live record with a status of pending, approved or denied, which is what lets the Slack message be updated. The ledger entries are the permanent part; that status is the working state.

Current limits#

• One approver. No multi-stage approval, no quorum, no separation of duties.
• No expiry. A request that is never actioned stays pending indefinitely. Nothing reminds, escalates or times out.
• No delegation. If the tagged approver is away, the request waits. Raise a new one naming someone else.
• No approver validation. Whoever can press the button can decide.
• Slack only. There is no equivalent flow in the web interface, and no email path.

Setup for the Slack connector itself, including the scopes this flow needs, is on the Slack page.