Day one, and the new starter cannot log in
Their manager spends the first morning raising tickets instead of onboarding them, and the new starter forms their first impression of the company from a service desk queue.
What actually happens
Nobody forgot. The information arrived, the requests were raised, and the process worked exactly as designed. The design is the problem.
A new starter is created in the HR system with a start date. That record triggers identity creation, which usually works, and then the rest of provisioning happens through a set of separate request paths.
Each application has its own owner, its own approval, and its own lead time. Some are automated from the identity record, some require a ticket, and at least one requires an email to a named person who may be on leave.
The manager is expected to know which applications this role needs. They know the four they use daily and not the three the role also requires, so those are requested in the second week after someone notices.
On day one the starter has a laptop, an email address, and access to roughly two thirds of what they need. The manager spends the morning raising tickets, which is the least valuable possible use of a new hire first day.
None of this is anyone fault. The information required to provision correctly exists across HR, the identity system, and the entitlements held by comparable employees, and no single system is joining those three.
The role definition already exists, in the entitlements held by everyone else doing that job. Nobody was reading it.
The same start date, two ways
Measured in elapsed days rather than minutes, and measured most honestly in how much of week one was productive.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, requests raised as gaps are found
- T-5 daysHR record created with start date. Identity provisioning triggered.
- T-5 ↓ T-0WaitingManager raises requests for the applications they know about. Separate paths, separate approvals.
- Day 1Starter has laptop, email and roughly two thirds of required access.
- Day 1WaitingManager spends the morning raising tickets for the gaps.
- Day 2 ↓ Day 8WaitingRemaining access arrives as each request clears its own approval and lead time.
- Week 2WaitingA further two entitlements identified that nobody knew the role needed.
~8 days to full access · and a first impression already formed
With the role derived from evidence
- T-5 daysHR record created. Sentinel derives the required entitlement set from what comparable employees in this role actually hold and use.
- T-5 daysSet compared against what identity provisioning covers automatically, leaving an explicit gap list.
- T-5 daysEach gap raised on its own path with the correct approver resolved from current ownership, not from a stale list.
- T-4 daysApprovals collected in parallel rather than discovered in sequence. Lead times run concurrently.
- T-1 dayProvisioning verified by checking actual access rather than by checking that tickets were closed.
- Day 1Starter logs in to everything the role requires. Manager spends the morning onboarding them.
Ready on day one · with the gaps found before the start date
The measurable cost of the first column is straightforward: days of a new employee salary spent on partial productivity, multiplied by your joiner volume. Your HR team can produce both numbers.
The unmeasurable cost is the first impression, and every hiring manager will tell you it matters more than the days do.
The mechanism is deriving the role entitlement set from evidence rather than from a documented definition. Documented role definitions go stale immediately. What comparable employees actually hold and actually use is current by construction.
Verifying by checking actual access rather than by checking ticket closure is the step that catches the remaining failures. A closed ticket means somebody said they did it, and on day one that is not the same thing.
Why the number is what it is
The measurable cost of the first column is straightforward: days of a new employee salary spent on partial productivity, multiplied by your joiner volume. Your HR team can produce both numbers.
The unmeasurable cost is the first impression, and every hiring manager will tell you it matters more than the days do.
The mechanism is deriving the role entitlement set from evidence rather than from a documented definition. Documented role definitions go stale immediately. What comparable employees actually hold and actually use is current by construction.
Verifying by checking actual access rather than by checking ticket closure is the step that catches the remaining failures. A closed ticket means somebody said they did it, and on day one that is not the same thing.
The mechanism is deriving the role entitlement set from evidence rather than from a documented definition.
Who decides to press go
Granting access is a change to an entitlement, so every element of provisioning is approved rather than assumed.
Deriving the entitlement set, computing the gap list, resolving approvers and preparing the requests all run under policy. None of them grant anything.
Each entitlement is approved by its accountable owner in the normal way. What changes is that the request is complete, correctly routed and raised before the start date rather than after it.
This deliberately does not bypass the approvals. Bypassing them would trade an onboarding problem for an entitlement drift problem, which is the subject of another use case on this site.
New starter record created in HR with a role and a start date. Identity provisioning covers part of the required access automatically.
Required entitlement set derived from what comparable employees in this role hold and actually use. Compared against automatic coverage to produce an explicit gap list.
Each gap raised on its own approval path with the current accountable owner resolved. Approvals run in parallel. Access verified directly rather than by ticket closure.
Role entitlement model updated from observed usage each cycle. Entitlements nobody in the role exercises dropped from the derived set rather than propagated.
This is a platform capability, not a published customer deployment for this exact scenario. The mechanism, which is cross-system correlation followed by governed MOP execution with pre-check, post-check, rollback and approval gating, is running in production today across managed estates; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The timings shown are modelled, not measured at a named customer.
If the action carries no service impact
Deriving the entitlement set, computing the gap list, resolving approvers and preparing the requests all run under policy. None of them grant anything.
If it grants access
Each entitlement is approved by its accountable owner in the normal way. What changes is that the request is complete, correctly routed and raised before the start date rather than after it.
What Sentinel did, step by step
- ObserveNew starter record created in HR with a role and a start date. Identity provisioning covers part of the required access automatically.
- InvestigateRequired entitlement set derived from what comparable employees in this role hold and actually use. Compared against automatic coverage to produce an explicit gap list.
- ActEach gap raised on its own approval path with the current accountable owner resolved. Approvals run in parallel. Access verified directly rather than by ticket closure.
- OptimizeRole entitlement model updated from observed usage each cycle. Entitlements nobody in the role exercises dropped from the derived set rather than propagated.
Bring us your last ten joiners
We will show how many days each took to reach full access, and where the days went.