Research Basis
The module's design follows the product plan in
modules/Offboarding/specs/IMPLEMENTATION_PLAN.md. It borrows established patterns from
leading identity-lifecycle, ITSM, and HR products — without copying any product's visuals or data
model — and grounds account and audit behavior in NIST guidance. This page summarizes where each idea
came from.
????
Research was limited to official product documentation and primary security guidance. The full
source list and rationale live in the implementation plan's "Research basis" section.
Patterns borrowed, and how they shaped ERPat
| Reference | Observed pattern | Adopted in ERPat as |
|---|---|---|
| Microsoft Entra Lifecycle Workflows | Separate real-time-termination, pre-offboarding, last-day, and post-offboarding workflows; time/attribute triggers; workflow run history; account/group/license actions. | Four execution phases, an authorized immediate path, and a stored run/attempt history for every automation. |
| Freshservice Journeys | One cross-functional journey with role-based tasks, due dates, region/role conditions, templates, and real-time progress. | One parent case with tenant-defined ownership, dynamic conditions, SLA tracking, and an exception queue instead of separate department checklists. |
| Jira Service Management Journeys | A parent journey spawns work items across projects; conditions, dependencies, field mapping, draft/published journey types. | Task dependencies, resolved source-field snapshots at start, and immutable published template versions. |
| BambooHR task lists | Organized offboarding task lists; attachments, comments, signatures, and the ability to require a file before a task is complete. | Grouped checklist sections and optional evidence-required completion per task and asset. |
| Okta Lifecycle Management & SCIM | Policy-driven provisioning/deprovisioning, standardized SCIM connectors, custom actions, application lifecycle handling. | Connector adapters behind a server-side interface with idempotency, bounded retries, redacted results, and a manual-verification fallback. |
| Google Workspace | Transfer a user's files/data to another owner before removing access; shared-drive content persists independently. | Data ownership transfer modeled as an explicit, configurable closure step — not a side effect of suspending or deleting an account. |
| SAP SuccessFactors Offboarding | Programs and task variants selected by separation data, location, job attributes, and responsible groups. | Ordered tenant rules resolve the applicable template, and the matching rule is shown in the start-case preview. |
| NIST SP 800-53 Rev. 5, AC-2 | Align account management with personnel termination, disable accounts no longer associated with a user, and audit account disable/removal. | Termination-aligned, time-bound account actions, least privilege, and a tamper-evident audit as non-optional architecture concerns. |
ERPat repository evidence used
The design reads existing ERPat sources of truth rather than duplicating them:
Separation signal
The
users.resigned and users.terminated flags are the departure signal that can auto-create draft cases (gated by a setting).
Reporting-manager resolution
ERPat has no per-employee manager field, so the "reporting manager" owner rule resolves from the department heads list (team.heads via FIND_IN_SET), falling back to the case owner when no head is set.
Asset assignment source
Assets endorsed to the leaver come from the Asset Registry via asset_entries.issued_to, so the case reflects the live custody record.
Principles this produced
One accountable case
Every task and external action stays traceable to a single case and departure event.
Immutable published versions
Cases keep the exact version and resolved values used at start; edits create a draft.
Gates, not checkboxes
Dependencies, evidence, and clearance are enforced states — closure requires the configured gates to pass.
Auditable by default
Starts, outcomes, sign-offs, holds, and closures are written to a tamper-evident activity log.
????
Want the full source URLs and the file-level plan? See
modules/Offboarding/specs/IMPLEMENTATION_PLAN.md in the repository.