Contractors, rehires, and leave

People outside the HR system

On any given day, a good number of the people working at Harbor Clinic are not its employees. Locum physicians like Dr. Moreau fill gaps in the rota. Nursing and medical students spend weeks on placement in the units. Engineers from the company that supplies the pharmacy's dispensing cabinets come in to maintain them. All of them need accounts, and some need patient records.

The HR system does not know them. It records employees, and none of these people are employees. Without another source, their accounts tend to start with a ticket: a manager asks IT for an account "for the new locum", someone creates it, and nothing records when it should end. When the locum leaves, nobody tells IT, because nobody thought of the locum as someone who could leave. The account stays until someone happens to notice it.

Harbor's answer is the contractor register, kept by the medical staffing office. It is the authoritative source for everyone who works at Harbor without being employed by it, in the same way that the HR system is for employees. Each entry records the person, the organization they come from, the work they are doing, a register ID such as C2291, a sponsor, and contract start and end dates. The identity system reads the register just as it reads HR: a new entry is a joiner, a changed entry can make a mover, and an end date that passes makes a leaver.

Sponsors and end dates

Two fields in each entry do most of the governing.

The first is the sponsor: a Harbor employee who vouches that the person's work needs doing and answers for their access while they are here. Dr. Moreau's sponsor is the emergency department's medical director. A student's sponsor is the practice educator on their unit, and a supplier engineer's is the manager of the service they maintain. The sponsor requests any access beyond the basics, confirms it in access reviews, and is the person Harbor contacts as the end date approaches. A sponsor is always an employee and never the person being sponsored. When a sponsor leaves or moves, everyone they sponsor needs a new one.

The second is the end date. Every non-employee has one, and the identity system will not create accounts for an entry without it: no end date, no account. An employee's job usually continues until someone decides it should end. A contractor's ends on a known date unless someone decides it should continue, and the end date is what makes ending the default.

That makes an extension a decision rather than a formality. Two weeks before Dr. Moreau's contract ended, the medical director received a reminder. Had the department wanted Dr. Moreau for another month, the director would have confirmed it, and only then would the staffing office have moved the end date. If nobody confirms, the end date stands. Harbor also limits each entry to six months, so even a long engagement comes back to its sponsor twice a year. Without rules like these, extensions become automatic, and three months can quietly become three years.

Students show why the end date has to hold. When a placement ends, a sponsor may ask IT to leave the account enabled in case the student comes back next year. That would be months of access with no reason behind it. The account is disabled at the end date like any other. If the student does return, the new placement goes through a sponsor again, and the identity system recognizes the person when it does, as it recognized Dana's earlier placement in Joining an organization.

Coming back

Recognizing a returning person is where most of the difficulty lies. Dr. Moreau's locum contract ended on 27 November 2026. In May 2027, HR hires Dr. Moreau as an emergency department physician, with employee number E11057 and a start date of Monday 7 June 2027.

As with any hire, the identity system first looks for an identity it already holds, and it compares stable identifiers to do it. The hire form records that Dr. Moreau previously worked at Harbor as locum C2291, and the hire record carries Dr. Moreau's professional registration number, which the contractor register also holds. Both lead to the same identity. The name and birth date agree too, but they support the match rather than make it.

Identity     hc-4n8v6t
Person       Dr. Lee Moreau
Sources      HR system E11057, from 2027-06-07
             Contractor register C2291, locum, 2026-09-01 to 2026-11-27
State        Pending start
Matched by   Previous register ID C2291 and professional registration number
Access       Birthright access for an emergency department physician
             Nothing restored from the locum contract

All names and identifiers in these examples are fictional.

Reusing the identity keeps Dr. Moreau's history in one place. Anyone looking at what Dr. Moreau did as a locum in 2026 and as an employee in 2027 sees one person. Dr. Moreau also gets the same email address back, [email protected], rather than a new one with a number on the end.

What the identity system does not do is restore old access. The locum accounts were deleted in February, when their retention period ended. Even if they still existed, the access they held belonged to a contract that is over. Dr. Moreau starts with the birthright access of an emergency department physician, and anything more is requested and approved again. Access granted for a past job is not evidence that the new one needs it.

Matching by email address is the failure case. Suppose the identity system looked for an existing identity by email. The hire record carries Dr. Moreau's personal email, because Harbor assigns clinic addresses itself, so the search finds nothing. The identity system creates a second identity, and the new account is given [email protected], because the original address is still reserved. Harbor now has two identities for one person, with the split history and the double entries in reviews that the check on Dana's placement avoided. Email matching can fail the other way too: if Harbor ever reused addresses, a different Lee Moreau hired years later could be matched to this identity and its history.

A contractor who becomes an employee with no break is a variation on the same case. Had Dr. Moreau been offered a permanent post before the locum contract ended, the register entry would have ended on the day before the employment began. The identity system should not treat that as a leaver followed by a joiner. Processing a leaver would end sessions, start the deletion clock, and transfer ownership, only for a joiner to undo it all a day later. Instead, the identity's authoritative source changes from the register to HR on the start date, and access is recalculated for the new job as it would be for a mover. The identity, its accounts, and everything Dr. Moreau owns carry on without a gap and without a duplicate.

Stepping away for a while

Priya Nair, the billing supervisor, starts six months of parental leave in March 2027 and is expected back in September. HR records the leave with its start date and expected return date.

Priya is not a leaver, and treating the leave as a departure would do real harm. Removing Priya's access, handing Priya's files and responsibilities to someone else, and starting a deletion clock would all have to be undone in September, and some of it could not be: an account deleted during the leave takes its history with it.

Leaving everything as it is causes a different problem. For six months, an account that can approve supplier payments would sit unused, with its owner not signing in and so not noticing anything wrong. An account like that is exactly what an attacker hopes to find.

A leave of absence, a planned period away with an expected return, is handled between the two. On the first day of the leave, the identity system suspends sign-in to all of Priya's accounts and ends any sessions and tokens that are open, as it would for a leaver. Everything else stays: the identity, the accounts and their entitlements, Priya's data, and what Priya owns. Some organizations deliberately leave a little access on during a leave, such as HR self-service for pay information. That is a decision recorded with the leave, not access someone forgot.

Priya's work still needs doing. A colleague covers supplier payment approvals, someone who does not also create suppliers, with a grant that ends on Priya's return date, in the same way as the temporary cover in Changing jobs. Requests for billing access, which Priya normally approves as the owner of the billing entitlements, go to a delegate named for the same period.

When Priya returns, HR records the return and the identity system restores sign-in. If Priya's job changed during the leave, for example in a reorganization of billing, the return is handled like a move, with access recalculated for the new job. If HR forgets to record the return, Priya cannot sign in on the first morning back, and the fix belongs in HR rather than in a manual change by the help desk that the next update from HR would undo. If Priya decides not to come back, HR records a departure, and the leave becomes an ordinary leaver.

Every case in this group depends on changes reaching each application on time, from the accounts created for Dana to the deactivation that ended Dr. Moreau's sessions. Continue to Getting accounts into applications to see the different ways applications receive those changes, and which of them ever hear that someone has left.