End the erased person’s active sessions
Erasing account information must also address the person’s continuing access. Wildo connects the scrubbed record to its declared sign-in principal and schedules session revocation after the local change commits.
A contact without a login and an account holder are different cases. The declaration makes that distinction explicit.
Example — Erase an account, not its author
Erasing a user ends that user’s sessions. Erasing a business record that mentions an employee as its author must not sign that employee out.
For engineers
dataSubjectPolicy answers whose sessions should end. It does not answer whether the record contains personal data. The actual user configuration names the row itself as the principal:
Source: users.shared.resources-config.schemas.ts (selected declarations; intervening comments omitted).
retentionPolicy: {
mode: ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE,
},
dataSubjectPolicy: { kind: ResourceDataSubjectKind.SELF_PRINCIPAL },
Use SELF_PRINCIPAL when the row ID is the user ID; LINKED_PRINCIPAL when a declared sessionPrincipalField identifies the account; and NO_PRINCIPAL when no login belongs to this subject. A contact or lead can be a person while correctly having NO_PRINCIPAL. A creator or owner foreign key alone is not a session declaration.
The common scrub path resolves principals before values are changed and schedules revocation after commit. This covers orchestrated erasure, direct impersonalization and an impersonalizing parent cascade. Startup supplies the token issuer’s invalidation function through SubjectSessionRevocationBackendService; custom bootstrap code must preserve that registration.
Revocation is post-commit work. A failure cannot restore already-scrubbed data and is logged as an access problem requiring operational follow-up. Treat a local erasure receipt and confirmed session termination as related outcomes, not interchangeable evidence. Monitor the revocation errors and verify an old session is refused in the application’s end-to-end erasure checks.
Choose an account linkage explicitly
Alternative resource-policy fragments, not three simultaneous declarations:
// A subject row that represents a separate account:
dataSubjectPolicy: {
kind: ResourceDataSubjectKind.LINKED_PRINCIPAL,
sessionPrincipalField: 'accountId',
},
// A contact with no sign-in account instead uses:
// dataSubjectPolicy: { kind: ResourceDataSubjectKind.NO_PRINCIPAL },
For the linked variant, accountId must be the declared field identifying the USERS row, with the resource configuration satisfying its linkage checks. sessionPrincipalField is forbidden for SELF_PRINCIPAL and NO_PRINCIPAL. Never substitute the creator’s ID just because it is available.
The current erasure report includes sessionRevocation.principalUserIds and lookupFailed. An empty principal list with a successful lookup can legitimately mean no account; a failed lookup is a different outcome requiring attention. Keep that receipt alongside operational revocation errors and an end-to-end check that an old session is refused.