How to build access request and approval

What matters here

• Default every grant to an expiry. Permanent should be a deliberate exception with a reason, not the shape everything takes.
• Route to the person who owns the system, not a shared IT queue. Only the owner knows whether the access is reasonable.
• Provision and revoke through the integration. A ticket saying access was removed is not evidence that it was.
• Ask for the business reason, and keep it. It is the only thing that makes a review decision possible a year later.
• The best report is people who left and still hold access. It should be zero and it never is on the first run.

Who this is for

You run IT operations or security. Access is requested in tickets, approved by whoever picks it up, granted by hand, and reviewed once a year in a spreadsheet nobody enjoys.

How it works in practice

The sequence, from somebody needing access to the access review being answerable.

1. 1

   The request is raised where people already are

   Chat or a short form. A portal nobody has bookmarked produces requests by direct message instead.

2. 2

   The system owner approves, not a shared queue

   Resolved from a register, with a deputy for anybody away, because a request waiting three days becomes a workaround.

3. 3

   An expiry is set by default

   Thirty, sixty or ninety days depending on sensitivity. Permanent requires a reason and a second approver.

4. 4

   Provisioning happens through the integration

   Not a ticket asking somebody to do it. The grant and the record are the same event.

5. 5

   The holder is warned before expiry

   With one click to extend and a reason required, so renewal is a decision rather than a lapse.

6. 6

   Revocation happens on the date, and is verified

   Then the whole thing is already the evidence an access review needs.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Begin by building the system owner register

   Routing is only as good as knowing who owns what.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Slack, Okta, Jira,
   Workday, Vanta and Snowflake, or whatever we run in those seats.
   Before you plan anything, tell me which of them are already
   authenticated in the workspace, because I do not want a connector
   stubbed that I have not authenticated.
   
   The detail that matters most is Okta. I need groups, applications, how
   assignment works, and which of our systems federate versus having
   local accounts.
   
   Then build a system owner register as a table: system, owner, deputy,
   sensitivity tier, default grant duration, and whether provisioning is
   automated or manual. This table is the whole workflow. Without it,
   requests route to a shared queue and get approved by somebody who cannot
   judge them.

2. 2

   Take requests where people already are

   A portal nobody bookmarked produces direct messages instead.

   Headless skills build-workflow

   Copy

   Use build-workflow. Accept requests from chat with a short form, and from
   the service desk for people who prefer it.
   
   Ask for: the system, the access level, how long, and the business reason.
   
   The reason field is not bureaucracy. It is the only thing that makes an
   access review decision possible a year later, when nobody remembers the
   project. Require it, and reject one-word answers.
   
   Pre-fill everything else from the directory: requester, manager, team,
   location. Never ask somebody for information the system already holds.

3. 3

   Route to the owner, and expire by default

   Two rules that between them prevent most access sprawl.

   Copy

   Route to the system owner from the register, with the deputy taking over
   if the owner is away. Chase after a day, escalate after two, because a
   request sitting for three days is a person finding a workaround.
   
   Set an expiry on every grant by default, from the sensitivity tier:
   
     low        90 days
     medium     60 days
     high       30 days
     privileged 7 days, and a second approver
   
   Permanent access requires an explicit reason and two approvers. It should
   be possible and it should be rare, and the difference between those two
   is entirely down to whether it is the default.

4. 4

   Provision for real, and revoke on the date

   A ticket saying access was removed is not evidence that it was.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then provision through the integration instead of by
   raising a task for somebody.
   
   Where a system cannot be automated, raise a tracked task with a deadline
   and verify completion by querying the system, not by somebody ticking a
   box.
   
   Warn the holder five days before expiry with one click to extend, and
   require a reason for the extension.
   
   On the expiry date, revoke and verify. Query the access back and confirm
   it is gone. A revoke call returning success and the access actually being
   gone are different facts, and the gap between them is what an audit
   finds.

5. 5

   Produce the review as you go

   So the access review is a query rather than a quarter of somebody life.

   Copy

   Record for every grant: who, what system, what level, approved by whom,
   the business reason, when it was granted, when it expires, and when it
   was revoked.
   
   Then produce these continuously, not before an audit:
   
     Everybody with a termination date who still holds access. This should
     be zero.
     Grants past their expiry that were not revoked.
     Permanent grants, with their reasons, ranked by sensitivity.
     Systems with no owner in the register, which is how requests end up
     in a shared queue.
     Approval turnaround by owner, because a slow owner produces
     workarounds, not patience.

6. 6

   Prove it works, then hand the register to IT

   Because owners and durations change constantly.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so IT operations can maintain
   the owner register, the sensitivity tiers and the default durations in
   the visual canvas. Ownership changes with every reorganisation, and a
   stale register routes approvals to people who left.

What it connects to

Requests arrive in chat, approvals need an owner, and provisioning has to be real.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides