In a shared driver-hours system whose records are a legal archive, what does deleting a departed driver's account cost that deactivating it does not?

middlemust knowfreq 55%

answer

employment ends, the record does not
who authored this entry
identifiers are retired, never reissued
cascade, null, or dangle
erasure is an exception path

basics

~20 s

Deleting destroys attribution: the hours entries, corrections and approvals the driver authored can no longer be resolved to a person, and the identifier could later be handed to someone else. Deactivation keeps the identity resolvable while ending sign-in.

solid answer

~50 s

A departure ends employment, not the record. In a cooperative's shared hours system the entries a driver authored are a legal record that must stay attributable for years, and every one of them points at an account row. Deleting that row forces a bad choice: cascade and destroy the record, null the reference and lose attribution, or leave a dangling identifier nothing can resolve. Deactivation — a local disabled state, usually driven by a provisioning write setting active to false — keeps the row resolvable, keeps the identifier permanently reserved so it is never reissued to a later hire, and makes a re-hire a decision rather than an archaeology exercise. Deletion stays as an exception path for a genuine erasure request, and even then pseudonymising the identity record usually beats a cascade. Note that disabling stops the next sign-in only; sessions and tokens already issued keep working until the deactivation policy fires their revocation.

A departure ends employment, not the record. In a cooperative's shared hours system the entries a driver authored are a legal record that must stay attributable for years, and every one of them points at an account row. Deleting that row forces a bad choice: cascade and destroy the record, null the reference and lose attribution, or leave a dangling identifier nothing can resolve. Deactivation — a local disabled state, usually driven by a provisioning write setting `active` to false — keeps the row resolvable, keeps the identifier permanently reserved so it is never reissued to a later hire, and makes a re-hire a decision rather than an archaeology exercise. Deletion stays as an exception path for a genuine erasure request, and even then pseudonymising the identity record usually beats a cascade. Note that disabling stops the next sign-in only; sessions and tokens already issued keep working until the deactivation policy fires their revocation.

code

json · 18 lines

json

{
  "accountId": "acct-4471",
  "state": "disabled",
  "identifierRetired": true,
  "sourceFirm": "firm-12",
  "lastTransition": {
    "from": "active",
    "to": "disabled",
    "at": "2026-09-19T06:04:11Z",
    "by": "provisioning-channel",
    "reason": "upstream active=false",
    "discovered": false
  },
  "revocationFired": {
    "sessions": "2026-09-19T06:04:12Z",
    "tokens": "2026-09-19T06:04:12Z"
  }
}

go deeper

for a junior

Recall that ending someone's employment and deleting their data are different decisions, and that records a person created still have to say who created them after they leave.

for a middle

Explain the three outcomes a hard delete forces on referencing records — cascade, null, dangle — and why an identifier that has ever been attributed to a person is retired rather than reissued.

for a senior

Show the account state machine with actor, time and reason on every transition, and own the residual window: state change stops the next sign-in, and the policy must fire session and token revocation to close the rest.

for a principal

Argue the retention-versus-erasure position for the cooperative as a whole, decide where the approval for a genuine deletion sits, and make sure the routine leaver path cannot reach it.

First, say which "removed" you mean

"The driver was removed" names at least six different operations with different blast radii and different reversibility. Insist on the distinction before designing anything.

what actually happened	what it changes	reversible
a provisioning write sets `active` to false	your account row's state, on the firm's authority	yes
a local disabled flag set by a cooperative administrator	the same state, on your own authority	yes
a hard delete of the account row	the row and everything referencing it	no
revoking the driver's live sessions	current access only; the account still exists	n/a — they would simply sign in again
revoking issued tokens	current machine access; the account still exists	n/a
releasing a paid seat	billing, not access	yes

Only the first three are identity-state changes. The next two are enforcement that a lifecycle policy fires; releasing a seat is commercial. A design that collapses them cannot answer "is this person still able to book hours?"

What deletion actually costs

Attribution. Every hours entry, correction and supervisor approval references the account that produced it. Delete the row and you get three unappealing outcomes:

cascade — the referencing records go too, and the legal archive you were obliged to keep is gone;
null the reference — the records survive but say nobody made them, which for a driver-hours record is the same as not having them;
leave the reference dangling — the records point at an identifier that resolves to nothing, and every report has to special-case it.

Reissue. A deleted identifier is free to be handed out again. If a later hire is given the same local account identifier — or the same human-readable driver code — the archive silently re-attributes one person's hours to another. The rule that follows is simple and worth stating in an interview: an identifier that has ever been attributed to a person is retired permanently, whatever happens to the account.

Re-hire. Drivers in a cooperative move between member firms and come back. A deactivated identity can be reactivated as an explicit decision with its history intact; a deleted one is re-created as a stranger, and the years of hours belonging to the same human are now split across two identities that nothing joins.

What deactivation does not do

Disabling the account stops the next sign-in. It does not by itself end a browser session the system already issued, nor invalidate a token already minted. Access therefore continues for a residual window after the leaver decision, and that window is a number the design owns — the lifecycle policy must fire session and token revocation as well as flipping state, and the time from the departure to the last possible successful request is the figure a security reviewer will ask for. Saying "we deactivate the account" without owning that window is the answer that fails.

When deletion is genuinely forced

A lawful erasure request is a different event from a leaver event, arriving on a different channel with a different authority, and it can outrank the ordinary rule. Even then the identity-side answer is usually pseudonymisation: strip the personal attributes from the identity record but keep the row and its identifier so the retained hours remain internally attributable to a distinct person. Where a retention obligation covers the records, it commonly outranks the erasure request for exactly those fields, which is a decision for the cooperative's counsel, not for the provisioning pipeline. What must not happen is an erasure path that the ordinary leaver flow can wander into.

What good looks like

One account state machine — active, disabled, pseudonymised — with a recorded actor, timestamp and reason on every transition; identifiers retired for good; deletion behind an approval that the routine leaver path cannot reach; and a stated residual-access window that the revocation the policy fires must meet.

A haulage cooperative runs one driver-hours system that every member firm books against. The drivers are employed by the member firms, not by the cooperative, so a departure is an event that happens inside an organisation you do not control — and the hours those drivers recorded are a legal record the cooperative must retain and be able to attribute long after the person has gone. Those two facts pull against each other, and the deactivate-or-delete decision is where the pull gets resolved. ## First, say which "removed" you mean "The driver was removed" names at least six different operations with different blast radii and different reversibility. Insist on the distinction before designing anything. | what actually happened | what it changes | reversible | |---|---|---| | a provisioning write sets `active` to false | your account row's state, on the firm's authority | yes | | a local disabled flag set by a cooperative administrator | the same state, on your own authority | yes | | a hard delete of the account row | the row and everything referencing it | no | | revoking the driver's live sessions | current access only; the account still exists | n/a — they would simply sign in again | | revoking issued tokens | current machine access; the account still exists | n/a | | releasing a paid seat | billing, not access | yes | Only the first three are identity-state changes. The next two are enforcement that a lifecycle policy *fires*; releasing a seat is commercial. A design that collapses them cannot answer "is this person still able to book hours?" ## What deletion actually costs **Attribution.** Every hours entry, correction and supervisor approval references the account that produced it. Delete the row and you get three unappealing outcomes: - **cascade** — the referencing records go too, and the legal archive you were obliged to keep is gone; - **null the reference** — the records survive but say nobody made them, which for a driver-hours record is the same as not having them; - **leave the reference dangling** — the records point at an identifier that resolves to nothing, and every report has to special-case it. **Reissue.** A deleted identifier is free to be handed out again. If a later hire is given the same local account identifier — or the same human-readable driver code — the archive silently re-attributes one person's hours to another. The rule that follows is simple and worth stating in an interview: **an identifier that has ever been attributed to a person is retired permanently, whatever happens to the account**. **Re-hire.** Drivers in a cooperative move between member firms and come back. A deactivated identity can be reactivated as an explicit decision with its history intact; a deleted one is re-created as a stranger, and the years of hours belonging to the same human are now split across two identities that nothing joins. ## What deactivation does not do Disabling the account stops the **next** sign-in. It does not by itself end a browser session the system already issued, nor invalidate a token already minted. Access therefore continues for a residual window after the leaver decision, and that window is a number the design owns — the lifecycle policy must fire session and token revocation as well as flipping state, and the time from the departure to the last possible successful request is the figure a security reviewer will ask for. Saying "we deactivate the account" without owning that window is the answer that fails. ## When deletion is genuinely forced A lawful erasure request is a different event from a leaver event, arriving on a different channel with a different authority, and it can outrank the ordinary rule. Even then the identity-side answer is usually **pseudonymisation**: strip the personal attributes from the identity record but keep the row and its identifier so the retained hours remain internally attributable to a distinct person. Where a retention obligation covers the records, it commonly outranks the erasure request for exactly those fields, which is a decision for the cooperative's counsel, not for the provisioning pipeline. What must not happen is an erasure path that the ordinary leaver flow can wander into. ## What good looks like One account state machine — active, disabled, pseudonymised — with a recorded actor, timestamp and reason on every transition; identifiers retired for good; deletion behind an approval that the routine leaver path cannot reach; and a stated residual-access window that the revocation the policy fires must meet.

A departed driver is hired by a different member firm eight months later. Do you reactivate the old account or create a new one?
Reactivate the identity, re-grant the authority. The same human should keep one identity so the archive stays joined, but reactivation must not silently restore the grants the account held at departure — those were tied to the old firm and role and have to be recomputed from the new employment before access is restored.
Why is 'we set the account inactive, so access has ended' an incomplete answer?
Setting state stops the next sign-in. A browser session already issued and a token already minted carry on until they are revoked or expire, so there is a residual window after the leaver decision in which the departed driver can still act. The policy must fire session and token revocation, and the width of that window is a number the design owns and states.
The cooperative receives a lawful erasure request from a former driver. What changes?
It is a separate channel with its own authority and approval, not the leaver path. The usual answer is to pseudonymise the identity record — remove personal attributes, keep the row and its identifier — so retained hours stay attributable to a distinct person. Where a retention obligation covers those records it may outrank the request for exactly those fields.

saying these in an interview costs you the question

Deleting the account row is the clean way to remove a leaver
Attribution can be preserved by nulling the reference on old records
An identifier is free to reuse once its account is gone
Setting the account inactive ends access immediately
Every erasure request means a hard delete of the person's records
A re-hire should just get a brand new account

In a shared driver-hours system whose records are a legal archive, what does deleting a departed driver's account cost that deactivating it does not?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

First, say which "removed" you mean

What deletion actually costs

What deactivation does not do

When deletion is genuinely forced

What good looks like

▾common follow-ups3 questions

▾red flags6 flags

First, say which "removed" you mean

What deletion actually costs

What deactivation does not do

When deletion is genuinely forced

What good looks like

answer

go deeper