Joining an organization
Before day one
On Monday 19 October 2026, Harbor Clinic's HR team records a new hire. Dana Okafor, a registered nurse, will join the pediatrics unit at the main site in two weeks, on Monday 2 November. Dana's first shift starts at 07:00 that day, and by then Dana will need to sign in on the ward, open the records of the children on the unit, and see the rota.
Someone arriving like this is a joiner. Later, Dana may become a mover by changing jobs inside the clinic, and one day a leaver. Joining is where Dana's access begins, and the easiest place to get it right.
At Harbor, a joiner does not begin with a phone call to IT. The HR system is the authoritative source for employees, and the hire record it publishes sets everything in motion. This is the record Harbor's identity system receives for Dana:
{
"type": "hire",
"recordedAt": "2026-10-19T09:14:00Z",
"employeeNumber": "E10482",
"legalName": { "given": "Dana", "family": "Okafor" },
"dateOfBirth": "1996-05-21",
"jobTitle": "Registered nurse",
"department": "Pediatrics",
"site": "Main site",
"manager": "E05190",
"startDate": "2026-11-02",
"employmentStatus": "pending start",
"previousHarborId": "C1874"
}All names, identifiers, and records in these examples are fictional.
Each part of the record has a job:
employeeNumberis HR's permanent key for Dana, so later changes such as a transfer or a departure reach the right person even if Dana's name changes.legalName,dateOfBirth, andpreviousHarborIdhelp the identity system work out whether it already knows Dana. HR asks every new hire whether they have worked or trained at Harbor before, and Dana gave the register ID of an earlier student placement. No application needs the birth date, so the identity system does not pass it on.jobTitle,department, andsitedecide Dana's starting access.managersays who approves Dana's requests and, later, who reviews Dana's access.startDatedecides when any of that access can be used.
Over the next two weeks, the identity system settles who Dana is, has each application create an account, and keeps every account disabled until the morning Dana starts.
Creating the identity
Before creating anything, the identity system looks for an identity it already holds for this person. For Dana, it finds a candidate. In the first half of 2024, a student nurse called Dana Okafor, with the same birth date, spent a placement on the pediatrics unit. The medical staffing office recorded that placement in the contractor register as C1874, and the identity system created identity hc-7f3k2q for it. When the placement ended, the accounts were disabled and later deleted, but the identity record and its history stayed.
Two mistakes are possible here, in opposite directions. If the identity system ignores the old record and creates a new identity, Harbor has two records for one person. Dana's history is split between them, an investigator looking into Dana's past activity finds half of it, and a later review shows two people where there is one. Merging records that only look alike is worse. Two different people can share a name and a birth date, and merging them would give one person the other's history, and possibly the other's access.
So Harbor's matching rules say how strong the evidence has to be:
- A stable identifier that ties the two records together, such as a register ID that the hire form and the staffing office's own records agree on, is enough to link the hire to the existing identity.
- A match on name and birth date alone is only a candidate. Someone on the identity team checks it, for example with the staffing office or with Dana, before anything is linked.
- No match at all means a new identity, with a new identity ID that will never change.
Dana's case meets the first rule. The register ID on the hire form is C1874, and the staffing office confirms that the placement belonged to the same person. The identity system links employee number E10482 to identity hc-7f3k2q and records who confirmed the match and on what evidence. From 2 November, the HR system rather than the contractor register is the authoritative source for Dana.
Identity hc-7f3k2q
Person Dana Okafor
Sources HR system E10482, from 2026-11-02
Contractor register C1874, student placement, ended 2024-06-28
State Pending start
Job Registered nurse, Pediatrics, Main site
Manager E05190 (pediatrics nurse manager)
Match Linked through register ID C1874, confirmed 2026-10-19Linking the identity brings back Dana's history, not Dana's old access. A student's supervised access in 2024 says nothing about what a registered nurse needs in 2026, so access is worked out from the new job.
Access on day one
Most of what Dana needs is the same as for every other registered nurse in pediatrics: a directory account, email, pediatric patient records, the unit's rota, and the ward's medication screens. Access granted automatically because of someone's job, department, or site is called birthright access. Harbor describes it in rules, such as "registered nurses in Pediatrics get EHR_PED_RW", and the identity system applies those rules to Dana's record. Access rules and birthright access looks at how such rules are written and kept accurate.
On 26 October, a week before the start date, the identity system's provisioning service sends each application the change it needs. The result looks like this:
| System | Account | State | Access from the rules |
|---|---|---|---|
| Staff directory | dana.okafor | Disabled | All staff and Pediatrics nurses groups |
| Email and files | The directory account, with the mailbox [email protected] | Disabled | Mailbox and the pediatrics team folder |
| Patient records | dana.okafor | Disabled | EHR_PED_RW: read and update pediatric patient records |
| Scheduling | [email protected] | Disabled | Unit staff: view the pediatrics rota and request shift swaps |
| Pharmacy | D. Okafor, created by hand from a ticket | Disabled | Ward nurse: view the unit's medication orders and record doses given |
| Billing | None | Not created | Not part of the job |
Some access is deliberately left out. Receiving controlled medication is sensitive enough that Dana's manager requests it, with a reason, once Dana has completed the pharmacy orientation. Billing has nothing to do with nursing. Rules give everyone in a job the same reasonable start, and anything beyond that is asked for.
A tempting shortcut is to give Dana "the same access as Sam", a nurse who has been on the unit for four years. Sam's access includes everything Sam has collected in that time, some of it for reasons that ended long ago. Copying it would hand Dana all of that on day one, with no record of why.
Applications do not all receive their changes the same way. Some accept them from the provisioning service as they happen, others import a file of changes overnight, and a few still need a person to make the change from a ticket. Getting accounts into applications compares these approaches, and SCIM requests and responses shows the messages that create and enable an account.
Creating the accounts a week early gives the slower applications time to catch up, and lets the rota show Dana's first shifts. Keeping them disabled matters just as much. An account that works before day one is access without a reason, and because Dana is not signing in to it yet, nobody would notice someone else using it. Just after midnight on 2 November, the identity system enables Dana's accounts, so that even the applications that import changes overnight have them before the 07:00 shift.
The first sign-in
An enabled account still has no way in. Dana has never signed in, so no password, passkey, or authenticator is registered yet. Whoever completes the first sign-in chooses those methods, and from then on controls the account.
That is what makes the old habit of emailing a temporary password risky. The message might go to Dana's manager, to a personal address typed into the HR form, or to a mailbox Dana cannot open yet. Anyone who sees it before Dana does, or finds it later in a forwarded thread, can sign in as Dana and register their own methods. Temporary passwords also tend to follow a pattern that is easy to guess.
Harbor uses activation instead: a one-time code that lets its holder set up sign-in methods for one specific account. Dana's code works once, only after the account is enabled, and only on 2 November. The nurse educator hands it over at orientation after checking Dana's photo identification against the HR record. Dana then enrolls a passkey and a backup method in the same way as any later enrollment, which Enrollment, replacement, and recovery describes along with what happens when a method is lost.
The photo check is doing real work. Before Dana opens a child's record, Harbor needs confidence that the person starting work is the person HR hired. HR checked Dana's identity documents during hiring, and the identity system recorded what was checked and when, without keeping copies of the documents. The handover at orientation connects that earlier check to the person who now controls the account. How much confidence a job needs depends on what its access allows: a job with access to patient records needs more than one with access to email alone. What proofing establishes explains how that confidence is built.
Someone who starts remotely needs a handover of similar strength, such as a video call in which a member of staff compares the person with the documents HR checked. Sending the code to a personal email address typed into the HR form would be much weaker.
When the start date moves
Start dates change. Suppose a check on Dana's nursing registration had taken longer than expected, and HR had moved the start to 16 November. The accounts already exist, and only the date they are enabled needs to change. Because the identity system reads the start date from HR whenever it changes, the new date simply replaces the old one. A system that scheduled "enable on 2 November" when it first saw the hire, and never looked again, would enable the accounts two weeks early.
Sometimes the start never comes. If Dana had accepted another offer and HR had cancelled the hire, the identity system would record the cancellation, and the accounts, never enabled, would be removed after a short holding period. The identity would keep both the student placement and the cancelled hire in its history.
The harder case is a no-show. The start date passes, the accounts are enabled as planned, and the new hire never arrives. Until HR records that the hire did not go ahead, the accounts stay enabled with nobody using them. Two safeguards limit the damage. The activation code expires at the end of the start date, so an unused one cannot wait for someone else to find it. And any new account that has never been signed in to by the end of the first week is reported to the manager, who either confirms a later start with HR or asks HR to cancel the hire. An enabled account that nobody uses is a dormant account from the day it is created, and Orphaned, dormant, and shared accounts looks at how to find them later.
Dana does arrive on 2 November. The access Dana starts with fits the job well, but jobs change. Continue to Changing jobs to follow Sam's transfer to oncology and see what a move does to four years of access.