Leaving an organization

The last day

Dr. Lee Moreau has spent three months as a locum physician in Harbor Clinic's emergency department. The contract ends on Friday 27 November 2026 at 18:00, at the end of Dr. Moreau's last shift. That end date and time live in the contractor register, kept by the medical staffing office, which is the authoritative source for people like Dr. Moreau who work at Harbor without being employees.

Someone whose relationship with the organization ends is a leaver. When the contract ends, every reason behind Dr. Moreau's access ends with it. In three months, that access has spread further than a list of accounts suggests:

• accounts in the staff directory, email and files, patient records, and scheduling
• a patient records session on an emergency department workstation, and a scheduling session on Dr. Moreau's phone
• the patient records mobile app on the same phone, which holds a refresh token issued by patient records so that it can stay signed in between shifts
• an API key Dr. Moreau created in scheduling, used by a weekly job that exports the department's rota to a shared spreadsheet

In Trust across systems, a provisioning service disabled a departing employee's account in a photo library. Dr. Moreau's last day shows everything that change has to reach, and how long it takes to get there.

Disable, remove, delete

Harbor can do three different things to a leaver's accounts, and the order matters.

To disable an account is to stop it being used while keeping it. Nobody can sign in with it, but the account, its history, and its data stay where they are. To remove access is to take away the entitlements the account holds, such as its group memberships and application roles. To delete an account is to remove it from the application altogether, usually with the data that belongs only to it.

Harbor disables Dr. Moreau's accounts and removes their access when the contract ends, but deletes the accounts only after a retention period, 90 days for most of them. Deleting straight away would destroy things Harbor still needs:

• Records for investigations. If a question comes up in January about who changed a patient's record in November, the answer should point to Dr. Moreau's account, not to a deleted user that some applications can only show as an unknown ID.
• Time to transfer ownership. Files, mailboxes, and anything else Dr. Moreau owned need a new owner before the account that holds them disappears.
• A possible return. Locums often come back, and a returning person should be matched to the same identity rather than treated as a stranger.

Removing access as well as disabling the account has its own reasons. If a disabled account were ever enabled again, by mistake or because the person returned, it should not come back with everything it held before. And lists of who holds an entitlement should show the people who can actually use it, not a growing tail of former staff. The identity system records what it removed, so the history still shows what Dr. Moreau could do.

The identity record itself, with that history, is kept for as long as Harbor's retention rules require, which is usually much longer than the accounts. Disabling and deleting are also separate operations in SCIM, the standard many provisioning services use: disabling is usually an update that sets the account's active attribute to false, and deleting is a request of its own. SCIM requests and responses shows both.

Ending access that is already open

Here is how Friday evening goes.

All people, records, and identifiers in these examples are fictional.

At 18:01, Dr. Moreau's identity is disabled, yet at 18:30 a scheduling session still works. Disabling stops new sign-ins. It does not, by itself, end anything that already exists. As Staying signed in described, an application recognizes a session by an identifier it issued and keeps accepting it until the session expires or the application ends it. Other kinds of access outlast a sign-in in similar ways:

• A refresh token lets an app get new access tokens without anyone signing in again. Whether the service that issued it checks the account's status before honoring it depends on that service. Revoking the token removes the doubt.
• An access token that has already been issued may keep working until it expires, which is one reason access tokens are given short lifetimes.
• An API key involves no sign-in at all. Disabling sign-in at the clinic's sign-in service does nothing to it.
• A signed-in device, such as a phone with clinic email set up, keeps its connection and any data it has already downloaded until it is signed out or the clinic's data is removed from it.

Whether an application ends these when it is told an account is deactivated depends on the application. A well-built one does, as patient records did at 18:02. For an application that does not, the leaver process needs an extra step, such as asking the application to end the user's sessions, and Harbor needs to know how long access there can outlast the account. Token revocation covers how a token is revoked.

Eight hours of access to a rota is a small risk. The same gap in patient records would not be. Harbor can shorten it for scheduling by having the provisioning service send changes to scheduling as they happen, or by ending scheduling sessions directly as part of the leaver process. Either way, the gap should be a known length that someone has accepted for that application.

Some applications never hear about a departure at all. An application that creates an account the first time someone arrives through the clinic's sign-in service, and receives nothing after that, learns about people when they join and not when they leave. Blocking Dr. Moreau at the sign-in service stops new sign-ins there, but the account, its open session, and any password or key it holds locally stay until something removes them. Getting accounts into applications looks at this approach and what it needs alongside it.

Urgent departures

Dr. Moreau's departure was planned months ahead. Some are not. Suppose a billing clerk is dismissed at 14:00 on a Tuesday after a concern about supplier payments. The clerk can create suppliers, has a mailbox full of supplier correspondence, and is sitting in a meeting room with HR and a manager. Any access left open after that conversation starts is time in which the clerk could export, delete, or change things.

Speed matters, and so does the order. Harbor works from the source outward:

1. HR records the termination with immediate effect. If IT disabled the accounts while HR still showed the clerk as employed, the next update from HR could enable them again, because HR is the source the identity system trusts for employment status. Sources of truth explains why.
2. The identity system disables the identity and the directory account, which stops new sign-ins everywhere that relies on the clinic's sign-in service.
3. Every application disables the account and ends its sessions, tokens, and keys, starting with the most sensitive: billing, then email and files. Where an application would only hear about the change overnight, Jordan Ellis, an IT administrator, makes the change there directly.
4. Each step is confirmed in the application itself and recorded with the time and the person who carried it out.

When HR cannot update its own record within minutes, the identity system can treat the person as a leaver on HR's instruction, with HR's record catching up shortly afterwards. What matters is that the source and the identity system agree, so that nothing downstream undoes the work. The timing is agreed with HR as well: access ends while the conversation is happening, not hours later, and not the day before, which would warn the person of what was coming.

What the person leaves behind

A leaver's access ends, but some of the things they set up keep running, or are supposed to. Dr. Moreau's weekly rota export ran under an API key in Dr. Moreau's name. When scheduling revoked that key at 02:00 on Saturday, the export stopped, and the emergency department only noticed on Monday when the spreadsheet had not updated.

Anything a person owns needs a new owner before, or as, they leave:

• Files that colleagues still need, such as Dr. Moreau's handover notes.
• Shared mailboxes and distribution lists the person manages.
• Scheduled jobs, scripts, and integrations that run under the person's account or keys. These belong under an account owned by the department, with a named owner, rather than under another person's account.
• Entitlements and groups the person owns. If Morgan Hale, the records manager, left without a successor named, requests for patient records access would wait for an approver who no longer exists, and nobody would be reviewing who holds that access.
• Service accounts the person is named as owner of. If Jordan Ellis owns the account that connects pharmacy to patient records, that account needs a new owner on the day Jordan leaves, not when it next breaks.

A week before Dr. Moreau's end date, Harbor's leaver process sent the sponsor, the emergency department's medical director, a list of everything the identity system knew Dr. Moreau owned. The handover notes were on it, and the director moved them to the department's shared folder. The export was not, because the API key had been created directly in scheduling and the identity system had no record of it. The list can only include what was recorded. Accounts and jobs that nobody owns are hard to review and easy to forget, and Orphaned, dormant, and shared accounts looks at how to find them.

Dr. Moreau's departure came from the contractor register rather than HR, and Dr. Moreau may well come back. Continue to Contractors, rehires, and leave to see how Harbor handles people outside the HR system, people who return, and people who step away for a while.