Automated provisioning can create a SaaS account and assign its groups when an employee joins. The reverse process is more complex than removing a name from a directory. The application may hold its own sessions, API credentials, shared objects, and scheduled tasks.
Offboarding review therefore follows the change into the destination application. A successful provisioning event confirms that a message was processed; it does not necessarily describe every remaining way the user can act.
SCIM manages identity resources
SCIM defines an HTTP protocol for creating, retrieving, modifying, and deleting identity resources such as users and groups. Its protocol operations do not automatically specify the full business lifecycle of every SaaS feature. RFC 7644 defines the protocol, while the core schema describes attributes such as a user's administrative status.
An illustrative design platform may disable a user through provisioning while retaining projects for the rest of the company. Keeping those projects can be intentional. Whether the former user can still access them through an existing session is a separate behavior to verify.
Establish the application's deactivation semantics
Document what deactivation does to sign-in, active sessions, personal API tokens, group membership, ownership, and external sharing. Some items may require a separate administration action. The application's integration documentation and actual configuration determine the expected result.
Also review how reactivation behaves. If a person returns or a provisioning mistake is corrected, the application may restore previous roles. The business needs to know whether that restoration matches the current access decision or silently reintroduces permissions from an earlier job.
Test the full transition with a synthetic user
Create a test user through the normal provisioning path, assign representative roles, and establish an active session. If the product supports them, create a harmless API token and scheduled job. Remove the user's access through the identity provider and record the resulting events at both ends.
Attempt ordinary reads and permitted test actions afterward. Measure the delay until denial and inspect whether scheduled work still runs. Reconcile differences between the directory state and application state rather than treating either administrative screen as the complete record.
Make failures visible to an owner
A provisioning connector can fail because of a revoked credential, changed mapping, or unavailable destination. Determine where such failures appear and who acts on them. A departure process that completes in the HR system while deactivation fails downstream requires an exception route.
The assessment can produce a per-application offboarding record with expected actions, observed timing, remaining manual steps, and responsible owners. This supports an accurate completion decision for each employee departure. It also provides a repeatable check when a new SaaS product, provisioning mapping, or identity provider configuration is introduced.
Sources
IETF: SCIM Core Schema, RFC 7643. The design platform is illustrative, and deactivation effects depend on the application.
