Close SaaS lifecycle gaps at the application, not the identity dashboard

The leaver ticket is closed, the identity account is disabled and the application is still open in the browser. For an identity lead, this is an unfinished access change, regardless of how many upstream steps show green.

A joiner, mover and leaver process has to carry an authorised event all the way to effective application access. The commercial consequences run in both directions: an incomplete joiner can prevent useful work, while a mover retaining old authority or a leaver retaining access creates avoidable exposure. Measure completion where the permission is used.

Four actions that need separate evidence

Account deactivation, account deletion, session revocation and transfer of business ownership solve different problems. Deactivation changes whether an account is enabled. Deletion concerns the account record and its supported lifecycle. Revocation addresses existing access. Ownership transfer keeps files, workflows or business responsibilities with an accountable person. Decide the required combination for each application, including its retention requirements.

The SCIM 2.0 core schema defines an active attribute for administrative status, but leaves its definitive meaning to the service provider. A connector reporting a successful update to that field is therefore insufficient evidence of every downstream effect you need. Check the application’s documented behaviour and observe the relevant result.

Microsoft’s guidance on revoking Entra ID access makes the session boundary explicit: an application can issue its own session cookie, which Entra ID cannot directly revoke. The application controls that session. Blocking new sign-ins and revoking identity-provider tokens must be paired with the application’s supported controls where existing access also needs to end.

Do not turn that distinction into a universal claim that SaaS sessions always survive deactivation. Some applications can terminate them as part of their supported workflow. Your completion criterion must reflect the actual application, its configuration and the access paths in scope.

Test three people through the same application

Choose an authorised test environment or controlled test identities, then follow a starter, a role change and a departure through one important SaaS service. Include the HR or contractor source, identity mappings, provisioning scope, application permissions and an owner who can verify the result.

The starter: can the person do the intended work?

Begin with the approved role and start time. Confirm that the right target account is matched or created, that the expected licence and groups apply, and that the person can perform a representative permitted action. Also attempt a relevant action outside the role using the controlled account. Successful login establishes authentication; it does not establish that permissions are correct.

Watch for duplicate identities where naming or email changes cause a second account to be created. Record the durable identifiers linking the authoritative person record to the application account. Display names are useful to humans but should not be treated as reliable evidence that two records represent the same identity.

The mover: what disappeared?

List the authority that should end as well as the authority being added. A transfer from purchasing to another department should not retain approval rights simply because the new role was provisioned successfully. Inspect direct grants, group-derived permissions and any exceptional local role separately.

If a handover genuinely requires temporary overlap, give that access an explicit end point and owner. Then verify removal when the overlap expires. Treat an indefinite exception as a separate access decision, rather than concealing it inside a completed mover event.

The leaver: which route still works?

In a hypothetical test, disabling the identity account prevents a fresh login but leaves an existing application session usable. Keep the event open, invoke the application’s documented revocation procedure and retest the existing session. Check direct application login and relevant user credentials or grants as well, where those paths exist.

Measure elapsed time from the authorised departure event to verified loss of the scoped access. A connector’s processing time is only part of that interval. If emergency revocation needs to be faster than routine provisioning can demonstrate, define and rehearse a separate supported path with the application owner.

Treat each connector as an implementation

A standards label does not remove application-specific requirements. Microsoft’s Entra-to-Slack provisioning tutorial, for example, specifies the gallery application customised for Slack’s SCIM v1 server and says a custom bring-your-own application integration is unsupported for that procedure. Its described setup creates, updates and disables assigned users, with provisioning scope and attribute matching configured explicitly.

That is a reason to verify the exact integration you operate. It is not evidence that a generic SCIM 2.0 configuration, a different Slack deployment or every session-control requirement behaves identically. Keep connector setup evidence separate from the target-side access tests.

Route failures to someone who can act. An expired connector credential, a rejected attribute or an incorrectly excluded user should become an owned unresolved change, with retries and escalation appropriate to its urgency. Inspect the target after recovery; a later healthy provisioning cycle should not automatically close every earlier failure.

Finally, reconcile the application’s account and permission inventory with the population expected to have access. Include local, guest and manually managed accounts in that comparison. Every unmatched account needs an explanation or a removal decision; no connector can validate an account it never manages merely by reporting success.

Use access reviews that produce and verify revocation decisions to address those residual permissions. Keep the lifecycle process accountable for routine changes, and use the review to find what those changes missed.