Onboarding
IT onboarding, from identity to access on day one
A new hire’s first day sets the tone — and nothing undermines it faster than a laptop with no login and a morning spent chasing app invites. Good IT onboarding is really two problems: create the person’s identity, then grant exactly the access their role needs, no more and no less. This is a walkthrough of how to make that repeatable, and how Useboards runs it as a single flow instead of a checklist someone has to remember.
Why IT onboarding quietly goes wrong
Most onboarding lives in a runbook doc or someone’s head. It works until the person who remembers the steps is out, a role has an unusual access need, or three people start in the same week. The failure modes are predictable: the identity isn’t ready on day one, access is granted ad hoc over the first fortnight, and nobody records who approved the admin rights a new engineer somehow got. Each gap is also an audit gap later.
Identity first, then access
The order matters. Almost everything a new hire touches keys off a corporate identity, so that has to exist before anything else can be granted. In Useboards, creating the identity is modelled as an access request to the identity system you nominate — Microsoft 365, Google Workspace, Okta, whichever you mark as your identity system. The provisioner who fulfils it enters the new corporate email, and only then does the rest of the onboarding fan out.
What a repeatable onboarding covers
Once identity is ready, the right grants fan out rather than being requested one app at a time. A dependable onboarding flow covers:
- Identity created in your identity system and the corporate email set before anything else fans out.
- Role-appropriate access to the systems in your catalog, each with its own owner and access levels.
- A buddy/IT-ready step so a named person confirms the new hire can actually log in and work.
- A record of every grant and who approved it — captured in the audit log, not reconstructed later.
Productive on day one — and provable later
Useboards drives the whole sequence off your system catalog: every SaaS app, vendor, and internal resource with its owners and access levels. The identity request unblocks the fan-out, provisioners see their tasks in one queue, and a buddy/IT-ready step confirms the new hire is genuinely set up. Because each step is an auditable event, the same onboarding that makes day one smooth also gives you the “least privilege from the start” evidence a SOC 2 or ISO 27001 auditor looks for.
Frequently asked questions
What should an IT onboarding checklist include?
At minimum: create the corporate identity, grant role-appropriate access to each in-scope system, confirm the new hire can log in (a buddy/IT-ready check), and record who approved each grant. Useboards runs these as one connected flow so nothing depends on someone remembering the checklist.
How does Useboards create the new hire’s identity?
It models identity creation as an access request to the identity system you nominate — M365, Google Workspace, Okta, or another. Useboards isn’t your identity provider; it orchestrates the request, and the provisioner enters the new corporate email. That email then unblocks the rest of the onboarding fan-out.
Can onboarding grant the right access automatically?
Once identity is ready, Useboards fans out grants for the systems a role needs, each routed to that system’s owner and access levels. Requests can run through the same configurable approval flows you use everywhere else, so higher-risk access still gets an approval and a recorded trail.
Does onboarding help with our audit?
Yes. Granting least privilege at the start and logging who approved each grant is exactly the evidence SOC 2 and ISO 27001 reviewers look for. Because every onboarding step is an append-only audit event, you can show new hires got the right access through an approved process.
Related
Make day one smooth and provable
Identity first, then the right access fans out — every step audited.