Joiner-Mover-Leaver (JML)
Who this is for
Admins and HR/IT operators managing identity lifecycle changes.
Goal
Handle joiners, movers, and leavers with predictable access outcomes.
Prereqs
- A connected identity source
- /implement/setup/first-connector
Success criteria
New hires receive baseline access, movers receive updated access, and leavers are disabled and de‑provisioned per policy.
Steps
- Confirm identities are ingesting correctly from your source system.
- Define baseline access using resources and approval steps.
- Use access requests to grant additional access on role changes.
- Disable identities when users leave to trigger revocation workflows.
Default configuration
- Use access requests for joiners and movers until automated policies are available.
When to change it
- When automated lifecycle policies become available, convert frequent requests into policy‑driven assignments.
Impact and risks
- If correlation is incorrect, joiner access can be granted to the wrong identity.
- If leavers are not disabled promptly, access can persist longer than policy.
Example
A new engineer is ingested from Okta, then a manager submits an access request for GitHub write access.
Troubleshooting
- If a leaver still has access, confirm the identity is disabled and check fulfillment status.
Assumptions & Questions
- What are the exact UI labels for disabling identities and verifying revocation status?
Next steps
- /implement/requests/access-requests
- /troubleshooting/ingestion-correlation