IT onboarding process: access before day one

A new hire starts on Monday and spends Tuesday asking for access to the tools nobody thought to grant. Her manager files three tickets. IT works through them on Wednesday. On Thursday she finds out the analytics tool needs a separate approval from its owner, who is on leave.

Getting access ready before day one is stage two of the employee lifecycle, and handling access requests after that is stage four of the IT service desk. Both depend on the same thing: knowing what access each role should have, and granting it without a person typing it in.

What is the IT onboarding process?

The IT onboarding process creates a new hire’s identity, email and application accounts before their start date, based on their role, and records each grant. After day one, the same process handles requests for additional access: routing each request to the owner of the system, granting it through the integration, and giving it an expiry date.

Why day one waits on IT

1. Access is copied from a colleague. “Give her the same as Sam” passes on everything Sam picked up over five years, and nobody reviews the copy.
2. Provisioning starts too late. IT hears about the hire from a ticket a few days before the start date, and some apps take longer than that.
3. It starts too early. An account created three weeks ahead is a credential nobody is using.
4. Start dates move. The plan was built for the old date, and nobody updates it.
5. Requests go to a shared queue. IT can’t judge whether access to a finance system is reasonable, so requests wait for someone who can.
6. Grants never expire. Access granted for a project stays after the project ends.

What it costs

A new hire who spends the first week waiting for logins costs a week of their salary and a bad first impression. Multiply it by every hire.

Over-granted access costs more later. Access copied from colleagues and never removed shows up in every access review, and every exception needs someone to explain it.

What to fix first

1. Trigger from the HRIS. Start provisioning when the worker record is created, with the start date as the deadline.
2. Define access by role. Keep a role profile as data, and stop copying colleagues.
3. Sequence around the start date. Create accounts a few days before day one, and handle a moved start date automatically.
4. Route requests to the system’s owner. Only they know whether the access is reasonable.
5. Grant and revoke through the integration. A ticket that says access was granted isn’t evidence that it was.
6. Give every request an expiry. Make permanent access a deliberate exception, with a reason recorded.

The guides to building employee onboarding provisioning and access request and approval have the prompts for each step.

How we handle access requests at Tray.ai

Our IT team built a Slack command for access requests. Someone types /access-request, picks the app from a list of the company’s approved vendors, and submits. The workflow checks whether that app needs approval from IT and security. If it doesn’t, the person gets a confirmation and instructions straight away. If it does, a Jira ticket is created for the IT team to approve.

“We've been able to automate away 30% of manual IT tasks, which has helped us build out our IT practice and scale our capabilities without being required to scale our headcount.”

Where it fits

Access before day one depends on a clean worker record with the right role and start date. The same role profiles drive role changes and offboarding. On the IT side, routine requests can go to an AI support agent that grants what the role already allows.

For all eight stages, see the hire-to-retire process.