How to build employee onboarding provisioning

What matters here

• Never clone access from an existing employee. It propagates every over-permission that person accumulated, and nobody ever audits the copy.
• Derive access from a role profile held as data. When the role changes, the profile changes, not a script.
• Sequence around the start date. An account created three weeks early is an unused credential sitting in the open.
• Record evidence per grant, not per person. Audit asks which system, when, and on whose authority.
• Handle the amendments, because start dates move. A plan that cannot absorb a date change becomes a manual process again.

Who this is for

You run IT operations or people operations. Onboarding runs on a checklist somebody maintains, provisioning happens the morning somebody starts, and access requests trickle in for a fortnight afterwards.

How it works in practice

The sequence, from a signed contract to a productive first day.

1. 1

   The HRIS is the trigger, not a form

   A new hire record with a start date begins the process. Nothing depends on somebody remembering to raise a ticket.

2. 2

   A role profile resolves what access is needed

   Department, level and location map to a set of systems and entitlements, held as data rather than in code.

3. 3

   Grants are sequenced against the start date

   Identity and email a few days ahead, everything else on day one, elevated access only after the training it depends on.

4. 4

   Hardware and licences are reserved, not just requested

   A laptop ordered on day one arrives in week three, so it is ordered when the contract is signed.

5. 5

   Each grant records evidence

   System, entitlement, timestamp and the role profile that authorised it, ready for the access review that will ask.

6. 6

   Date changes replan instead of break

   A start date moving by a week moves the whole sequence, and nothing has to be undone by hand.

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

   First, read the two sources of truth

   The HRIS knows who, the directory knows what. Both, before anything.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Workday, Okta, Google
   Workspace, Jira, Slack, Jamf 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. I expect Workday and
   Okta at minimum.
   
   The two that carry the build are Workday and Okta. From Workday I need
   the worker record with start date, department, job profile, manager
   and location. From Okta I need groups, applications and how group
   assignment actually works.
   
   Do not assume a mapping between a Workday job profile and an Okta
   group. Show me both lists and I will map them.

2. 2

   Build the role profile as data, never as a copy

   The single decision that keeps the access model clean.

   Headless skills build-workflow

   Copy

   Use build-workflow. Trigger on a Workday worker record with a future
   start date.
   
   Resolve access from a role profile table keyed on department, job profile
   and location. Each profile lists the systems, the group memberships and
   the licence types.
   
   Do not offer a copy-from-colleague path, and refuse if I ask for one
   later. Cloning access propagates every exception the colleague
   accumulated, and nobody ever reviews a copy.
   
   If no profile matches the combination, stop and ask. An unmatched role is
   a profile that needs writing, not a reason to guess.

   This is the difference between an access model you can audit and one that drifts. Everything downstream depends on the profile being data somebody owns.

3. 3

   Sequence it against the start date

   Because an account created three weeks early is an open credential.

   Copy

   Schedule grants relative to the start date rather than firing everything
   at once:
   
     start minus 5 days   hardware ordered, laptop build requested
     start minus 2 days   identity created but disabled, email provisioned
     start minus 1 day    welcome message with first day logistics
     day one 09:00        identity enabled, core application access granted
     day one              manager notified that provisioning completed
     week two             elevated or regulated access, only where the
                          required training is recorded as complete
   
   An identity created three weeks early and left enabled is a credential
   sitting in the open with nobody watching it.

4. 4

   Handle the amendments, because they always happen

   A plan that cannot absorb a date change becomes a manual process again.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then handle these explicitly:
   
   Start date moves. Replan the whole sequence rather than firing missed
   steps immediately. A date moving forward should not dump five days of
   grants at once.
   
   Offer withdrawn before the start date. Reverse everything already
   granted, and confirm the reversal rather than assuming it.
   
   Role changes between signing and starting. Re-resolve the profile and
   show the difference before applying it.
   
   Contractor instead of employee. A different profile with an expiry date
   attached from the start.
   
   Rehire. The old identity may still exist. Never silently reactivate an
   account with its historical access intact.

5. 5

   Record evidence, and reconcile against reality

   Because the access review asks per system, not per person.

   Copy

   Record for every grant: the system, the entitlement, the timestamp, the
   role profile that authorised it and the run that performed it.
   
   Then reconcile weekly. Compare what the profile says a person should have
   against what each system reports they actually have, and report both
   directions: missing grants, and access nobody granted through this
   process.
   
   That second list is the interesting one. It is how manually granted
   access, which is the access nobody reviews, becomes visible.

6. 6

   Test it, then hand the profiles to IT

   So a new role is a data change, not an engineering ticket.

   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 role profiles and the sequence timings in the visual canvas. New
   roles appear monthly, and none of them should need a coding assistant.

What it connects to

Provisioning reads the people system and writes to everything a person needs.

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

Further reading

Background on the same subject, for the case rather than the build.

• Scale onboarding and security with automated provisioning

Related guides