How to build a role change access update

What matters here

• Joiners and leavers get a process. Role changes usually don't, and that is where access quietly piles up.
• Removing the old role's access matters more than adding the new one, because nobody files a ticket to lose access.
• Compare the old role with the new one instead of starting from scratch, so access both roles need is never cut off by mistake.
• Give the old access a short, fixed handover window, then remove it on a schedule rather than when someone remembers.
• Keep the access someone was granted by request separate from the access their role gives them, and review the requested access on its own.

Who this is for

You run IT operations or identity. Onboarding and offboarding are automated, but promotions and transfers still run on tickets, and every access review finds people holding permissions from a job they left a year ago.

How it works in practice

The path from a change in the HRIS to the person holding exactly what their new role needs.

1. 1

   The HRIS change starts the clock

   A new job title, department, manager, location or cost centre, each with an effective date.

2. 2

   The old role and the new role are compared

   What both roles need stays. What only the new role needs is added. What only the old role had is marked for removal.

3. 3

   New access is ready on the effective date

   Groups, apps and permission sets for the new role, granted on the morning the change takes effect.

4. 4

   Old access is removed after the handover window

   Usually two weeks, so the person can hand work over. Then it goes on schedule, without a ticket.

5. 5

   Exceptions go to the new manager

   Anything the person needs to keep from the old role is asked for, approved and given an end date.

6. 6

   Every change is recorded

   What was added, what was removed, when, and who approved any exception. The access review reads from it.

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 map roles to access

   You can't compare two roles until each one has a list.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. The systems in play are Workday, Okta, Google
   Workspace, Salesforce, NetSuite, Slack 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.
   
   Build me the role-to-access map: for each combination of department and
   job family, the Okta groups, Google groups, Salesforce profile and
   permission sets, NetSuite role and Slack channels it should hold. Start
   from what people in each role hold today and show me where they differ,
   because the differences are where the old access is hiding.

2. 2

   Trigger on the HRIS change and compare

   The difference between the two roles is the whole job.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. Trigger on a Workday job change: title, department,
   supervisory organization, location or cost centre. Read the effective
   date.
   
   Look up the old role and the new role in the access map and work out
   three lists:
   
     Keep: access both roles should have. Touch nothing.
     Add: access only the new role should have.
     Remove: access only the old role had.
   
   Anything the person holds that is in neither role was granted by
   request. Leave it alone here and list it for the access review.

   Without the keep list, a transfer between two teams that share a tool removes it on Friday and adds it back on Monday, and the person loses a day's work in between.

3. 3

   Add on the effective date

   Because the first day in a new role should not start with tickets.

   Copy

   On the effective date, grant everything on the add list: Okta groups,
   Google groups and shared drives, the Salesforce profile and permission
   sets, the NetSuite role, and the Slack channels for the new team.
   
   Confirm each grant against the system rather than trusting the response,
   then post a summary to the person and their new manager in Slack.

4. 4

   Remove after the handover window

   Because nobody raises a ticket to lose access.

   Headless skills tray-patterns

   Copy

   Schedule the remove list for the effective date plus 14 days, or the
   window we set per department.
   
   Three days before removal, message the new manager in Slack with the
   list and one choice per item: remove as planned, or keep until a date
   they choose, up to 90 days. No answer means remove.
   
   On the day, remove everything not kept. Confirm each removal against
   the system. Anything kept gets its own end date and is removed then.

   Finance and admin access is the case that matters most. Someone who leaves finance should lose the ability to post journals or approve payments on schedule, with no exceptions unless a finance lead approves them.

5. 5

   Handle the awkward changes

   Because not every change is a clean move from one role to another.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then handle these:
   
     Manager change only. Update approval routing and reporting lines, and
     leave app access alone.
   
     Temporary cover or acting role. Add the access with an end date and
     remove it when the cover ends, without touching the person's own role.
   
     A change entered after its effective date. Apply it now, and work out
     the removal window from today rather than from the date it should
     have happened.
   
     A change that is reversed. Restore from the role map, never from a
     copy of what the person held before.

6. 6

   Record it, then hand it to IT

   So the access review is a report instead of a project.

   Copy

   Write every add, remove, keep and exception to Snowflake with the
   person, the systems, the dates and who approved any exception.
   
   Then produce a standing report: everyone who holds access from a
   previous role past its removal date. It should read zero.
   
   Run the per-step checks and the whole-workflow audit before this
   touches production, then open the same workflow in Tray Build so IT
   can edit the role-to-access map in the visual canvas as teams change.

What it connects to

A role change touches every system the old role and the new role use, which is usually more than either team thinks.

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