Skip to content
Customer Identity · available nowBuild your first Test integration.Create a Test project
NamoID
All posts
NamoID Blog

Joiner, Mover and Leaver Access for SaaS Teams

Plan SaaS lifecycle access across memberships, roles, provisioning, sessions, tokens, and automation ownership. Test changes with a practical worksheet.

A joiner, mover and leaver process keeps access aligned with a person's current responsibilities. It must cover memberships, roles, application sessions and credentials. A successful SSO login does not prove that these lifecycle changes are complete.

Start with an authoritative change event. Record who approved it, when it becomes effective and which systems must acknowledge it. Then verify the resulting access.

Separate the three lifecycle changes

ChangeRequired decisionCommon missed boundary
JoinerWhich organization and minimum role may this person enter?Automatic membership from an email suffix
MoverWhich old permissions must be removed?New access added while old privileges remain
LeaverWhich access must end at the effective time?A disabled directory account with active application sessions

Use a stable person or membership reference. A display name or email address can change. Confirm the authority of an incoming change before applying it to a tenant.

Map the systems that hold access

For a synthetic SaaS example, an employee moves from support to finance. Their identity account remains active. Their support export permission must end, while an approved finance role begins.

List the organization membership, application role, session, refresh token, API key and shared automation they could use. Assign an owner to each item. Role removal in one database does not prove removal in another service.

Authoritative change
       |
       v
Approved tenant-scoped lifecycle operation
       |
       +--> membership and role update
       +--> session and token policy
       +--> application authorization check
       +--> evidence and reconciliation

Use provisioning protocols for their actual job

SCIM defines identity-management operations, including updates through PATCH. Your service still determines how a supported attribute change affects account status and application access. The provisioning response is one part of the lifecycle evidence. SCIM protocol.

This illustrative PATCH sets an account's SCIM active attribute to false at a service that supports that operation.

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {"op": "replace", "path": "active", "value": false}
  ]
}

It does not demonstrate a NamoID SCIM endpoint. It also does not prove that every existing application session or access token has stopped working.

Define what happens to active access

A service that validates a signed token locally may continue accepting it until expiry unless it applies another revocation or policy check. Application sessions can have different lifetimes. Document the enforcement point and maximum delay for each path.

When supported, back-channel logout can notify relying parties about logout. Those parties must validate the notification and end the applicable sessions. Treat provisioning, logout and token revocation as distinct mechanisms. OpenID Connect back-channel logout.

The SSO logout guide helps test those boundaries.

Reconcile the lifecycle operation

Use the lifecycle acceptance worksheet to record each system's result.

  1. Verify the source and authority of the change.
  2. Record the target tenant and effective time.
  3. Remove obsolete memberships and role assignments.
  4. Apply the approved new state.
  5. Enforce the session and credential policy.
  6. Test a previously permitted sensitive operation.
  7. Confirm the expected allow or deny result.
  8. Reconcile failed updates through an owned queue.

Record duplicate and out-of-order events. A late joiner message must not silently reactivate a leaver. Choose sequencing and version rules that fit the authoritative source.

Transfer automation ownership deliberately

A departing employee may own an integration or scheduled job. Determine whether it uses delegated user access or an independent service identity. Reassigning a display owner does not transfer credential authority.

Approve the new owner, rotate or replace credentials where necessary, and verify the job under its intended access. For the machine boundary, read service accounts and client credentials.

Review lifecycle access with NamoID

NamoID engineers can help map user, organization and session boundaries. Confirm the supported management operations and provisioning integrations for your deployment. This runbook does not claim an automatic HR-to-SCIM lifecycle service.

Share your organization model, current identity provider and one synthetic role-change case in Slack for an early response. Contact the NamoID team