How to build a user access review

What matters here

• Pull accounts from each app, not only from the identity provider. The account created by hand inside the ERP is the one that matters.
• Match every account to a person in the HRIS. An account with no current employee behind it is a finding before anyone reviews it.
• Send each reviewer only their own people. Nobody reads a company-wide spreadsheet.
• Remove what nobody confirms by the date. A review where silence means keep changes nothing.
• Keep the record as you go. The evidence is the list, the decision, the reviewer and the removal, with dates.

Who this is for

You run IT, security or compliance. Access to the apps your auditors care about is reviewed every quarter, the review is a spreadsheet, and proving it happened takes longer than doing it.

How it works in practice

What happens each review cycle, from the list being built to the access nobody needs being gone.

1. 1

   The apps in scope are listed with an owner

   The ERP, the CRM, the cloud console, the code host and anything else the audit covers, each with the person accountable for it.

2. 2

   Every account is pulled from the app itself

   Users, roles and admin rights as each app holds them, plus what the identity provider says, so accounts created outside it show up.

3. 3

   Each account is matched to a person

   Against the HRIS: current employee, leaver, contractor or no match. Leavers and no matches are flagged before the review starts.

4. 4

   Each reviewer gets their own lines

   Managers review their reports' access, app owners review admin rights and service accounts, with the flagged lines first.

5. 5

   Anything not kept is removed on the date

   After one reminder, through the identity provider where it can be, and by a tracked ticket where it cannot.

6. 6

   The cycle is recorded

   The list as it stood, every decision with who made it and when, and every removal with proof it happened.

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

   Set up, then list the apps in scope

   The review covers what is on this list and nothing else.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Okta, Workday, NetSuite,
   Salesforce, GitHub, Slack, Jira 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.
   
   Then build a table of the apps in scope for the review: app, owner,
   how to read its users and roles, which roles count as admin, and
   whether access is granted through the identity provider, inside the
   app, or both.
   
   Flag every app where accounts can be created inside the app. Those are
   the ones where the identity provider's list is not enough.

2. 2

   Pull every account and match it to a person

   The account nobody knows about is the one the auditor finds.

   Headless skills build-workflow tray-gotchas

   Copy

   Use build-workflow and tray-gotchas. At the start of each cycle, for
   every app on the list, read every account with its roles and last
   login from the app itself. Read the same app's assignments from Okta.
   
   Match each account to a person in Workday by email, then by employee
   id. Mark each line as one of:
   
     Current employee, with their manager and department
     Leaver, with their end date
     Contractor, with their contract end date
     Service or shared account, with its named owner if it has one
     No match
   
   Flag before the review starts: leavers with active accounts, no-match
   accounts, admin rights, accounts with no login in 90 days, and any
   account that exists in the app but not in Okta.

3. 3

   Send each reviewer only their own lines

   A reviewer reads the first ten lines carefully and skims the rest.

   Headless skills build-workflow

   Copy

   Use build-workflow. Route each line to its reviewer:
   
     A current employee's access goes to their manager
     Admin rights and service accounts go to the app owner
     Nobody reviews their own access; send it to their manager's manager
   
   Send each reviewer one Slack message with their lines only, flagged
   lines first, and buttons to keep or remove, line by line or for all
   flagged lines. Ask for a short reason for any flagged line kept.
   
   Give a deadline two weeks out and remind once, three working days
   before. If a reviewer has left, send their lines to their manager.

4. 4

   Remove what was not kept

   Silence means remove, or the review changes nothing.

   Headless skills tray-gotchas tray-patterns

   Copy

   Use tray-gotchas and tray-patterns. On the deadline, remove every line
   marked remove and every line nobody answered:
   
     Through Okta where the app is assigned there
     Directly in the app where it supports it
     Otherwise by a Jira ticket to the app owner with a due date
   
   Read the account back after removal and record that it is gone. A
   removal nobody checked is a removal nobody can prove.
   
   Tell each person what they lost and how to ask for it back through
   the normal access request.

5. 5

   Keep the record an auditor samples

   The next audit should be a query, not a week of screenshots.

   Copy

   Write each cycle to Snowflake: the list as it stood on the start date,
   every decision with the reviewer and the time, every removal with the
   read-back result, and every line that went to a ticket with its
   closing date.
   
   Produce one report per app per cycle: accounts reviewed, removed,
   kept with a reason, and tickets still open. Attach it to the matching
   control in Drata.
   
   Report across cycles: leavers found with active accounts, reviewers
   who did not answer, and how many removed people asked for access
   back. A high number asking back means the list was wrong.

6. 6

   Check it end to end, then hand the cycle to compliance

   Because the scope and the schedule are a compliance decision.

   Copy

   Run the per-step checks and the whole-workflow audit before this
   touches production. Run one cycle against a test app, leave one line
   unanswered, and confirm it is removed on the date and the person is
   told.
   
   Then open the same workflow in Tray Build so compliance can change the
   apps in scope, the reviewer rules, the schedule and the deadline in the
   visual canvas. Access to MCP tools and AI assistants is reviewed in its
   own cycle; keep this one to people's access to company apps.

What it connects to

The list comes from the apps and the identity provider, the people from the HRIS, and decisions happen where reviewers already work.

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