Enterprise Joiner-Mover-Leaver (JML) Reference Architecture

The problem

Most organizations automate the joiner path reasonably well: HR creates a record, the IGA platform provisions birthright access, done. Mover and leaver events are where things break down in practice.

A mover — a transfer, promotion, or department change — should trigger both a grant (new access for the new role) and a revoke (old access that’s no longer justified). In systems built primarily around provisioning, the revoke half is often missing or treated as a manual follow-up that depends on someone remembering to submit a request. Leaver events fare better when tied directly to an HR termination feed, but grace periods, contractor status changes, and disconnected applications that can’t be automatically deprovisioned are common gaps.

The result is access that accumulates over an employee’s tenure rather than reflecting their current role — which is exactly what access certifications and SoD reviews are supposed to catch, and exactly what audit findings tend to flag first.

Architecture overview

flowchart TD
HR[HR System of Record] -->|Identity events| Engine[IGA Lifecycle Engine]
Engine -->|Joiner| Provision[Birthright Provisioning]
Engine -->|Mover| Reconcile[Grant New Access + Revoke Stale Access]
Engine -->|Leaver| Deprovision[Full Deprovisioning]
Provision --> Connectors[Connector Layer]
Reconcile --> Connectors
Deprovision --> Connectors
Connectors --> AD[Active Directory]
Connectors --> JDBC[Database-Connected Apps]
Connectors --> Manual[Disconnected Apps — Manual Task + SLA]
Connectors --> Audit[Audit & Reconciliation Log]

The authoritative source (HR) publishes identity events. A lifecycle engine classifies each event as a joiner, mover, or leaver and applies the corresponding policy — not just “what access to add,” but for movers specifically, “what access to remove.” The connector layer executes the actual provisioning/deprovisioning against target systems, with disconnected applications routed to a manual fulfillment queue rather than silently skipped.

Major components

• Authoritative source integration — HR feed (new hires, transfers, terminations, status changes) as the single trigger for lifecycle events; anything provisioned outside this path becomes governance debt.
• Lifecycle rules engine — classifies events and determines the applicable policy: birthright role assignment for joiners, delta calculation (add/remove) for movers, immediate vs. grace-period deprovisioning for leavers.
• Role/entitlement model — birthright roles tied to job attributes (department, title, location), with exceptions handled through governed access requests rather than growing the role model indefinitely.
• Connector layer — direct connectors (AD, JDBC, web services) plus a manual fulfillment path with SLA tracking for applications that can’t be integrated.
• Reconciliation & audit log — a record of what changed, when, and why (which lifecycle event triggered it) — not just a snapshot of current access.

Design decisions

• Movers get explicit revoke logic, not just additive grants. The lifecycle engine computes the difference between the old role’s birthright entitlements and the new role’s, and revokes what’s no longer justified. Treating a mover as “just another joiner” is the single most common design gap.
• Grace periods for leavers are a business decision, not a technical default. Immediate deprovisioning is the safer default; any grace period (e.g., for final payroll access) needs an explicit, time-boxed exception with its own audit trail.
• Disconnected applications are routed, not skipped. Applications without a native connector go into a manual fulfillment queue with an SLA, rather than being silently excluded from lifecycle automation — a common source of orphaned access.
• Birthright roles stay coarse; exceptions stay governed. A modest set of department/title-based roles covers routine cases; anything else goes through an access request with an approval chain, which keeps the role model from becoming unmaintainable.

Implementation considerations

• HR data quality is the actual bottleneck. Before any automation is trustworthy, the HR feed needs consistent, accurate attributes (department, manager, employment type, effective dates). Data cleanup is usually a longer effort than the platform configuration itself.
• Non-employee identities need their own path. Contractors, vendors, and service accounts typically don’t originate from the same HR feed and need a separate sponsorship and lifecycle model with explicit expiration.
• Effective-dating matters. A transfer that’s “effective next Monday” in HR needs the access change to land on that date, not the date the record was updated — timing mismatches are a frequent source of premature or delayed access changes.

Lessons learned

Joiner automation gets the attention because it’s visible and business-impacting (new hires need to work on day one). Mover and leaver logic get comparatively little design effort, but they’re what access certifications and SoD reviews actually surface as findings. Any JML implementation should be evaluated on how it handles movers first — that’s where the governance gap usually is.