Can You Provision and Deprovision Users Reliably? A Checklist for Self-Hosted Applications
A practical checklist for testing account creation, permission changes, deactivation and edge cases before adopting or operating a self-hosted application.
Treat account lifecycle as an operational process
User provisioning is not just the moment someone gets a login. A lifecycle can include creating an account, updating its attributes or permissions, and eventually disabling or deleting it. OneLogin describes provisioning and deprovisioning in these terms; Microsoft Entra's planning guidance likewise treats automatic provisioning as a deployment that needs preparation.
For a self-hosted application, the important question is whether every step works for your chosen account-management method. Do not assume that an application supports directory synchronization, a particular identity provider, or a specific deactivation behavior. Confirm those details in the current official documentation for both the application and identity provider.
- Invitation or account creation
- First sign-in and activation
- Role or group assignment and later changes
- Suspension, departure and possible reactivation
- Ownership of content, records, integrations and credentials after departure
Map how accounts enter the application
Start by documenting the actual account-creation path. It may involve an administrator entering accounts manually, users accepting invitations, a documented directory integration, or another method. These are alternatives to investigate, not capabilities to presume.
For each path, identify who initiates the action, what information is required, and what evidence confirms that the account is ready to use. Check whether an invited but inactive person occupies a seat, receives access to any content, or can be invited again; verify each behavior in the target application's documentation or a controlled test.
- Record the source of truth for identity attributes such as name and email address.
- Establish how an administrator knows an account was created successfully.
- Test an invitation that is accepted, one that is not accepted, and one sent to an incorrect address.
- Confirm whether the application offers a documented automated provisioning integration before designing around one.
Test roles, groups and mapping changes
A successful sign-in does not prove that permissions are being managed correctly. If access is assigned through application roles, identity-provider groups, or a mapping between them, test the complete path from the source assignment to the permissions visible in the application.
Then change the assignment. Verify what happens when a person moves to a different group, loses a group, or is assigned a role that has no mapping. The expected result is a policy decision for your organization; the application’s behavior must be established from its official documentation and testing.
- Test a new user with the least access they need.
- Change a group or role and check the resulting application permissions.
- Remove an assignment and confirm whether access is reduced as intended.
- Change a mapping and identify whether existing users are updated, left unchanged, or require administrator action.
- Document what happens when an assignment is missing or ambiguous; do not rely on an assumed default.
Verify what deactivation actually revokes
Disabling or deleting an account may not answer every access question. Test the application’s documented behavior for active browser sessions, API credentials, personal access tokens, connected accounts and other access paths your team uses. Do not infer that deactivating a user automatically revokes every credential or session.
Separate the account status from related assets. A departing user may own records, scheduled work, integrations or content that other people still need. Define whether those items are transferred, retained, removed or reviewed, and who approves that action.
- After deactivation, try a fresh sign-in and check any existing session in a controlled test.
- Inventory tokens, API credentials and connected accounts, then verify the documented revocation process for each.
- Check whether account deletion is reversible and whether it affects content or audit history.
- Record the owner and approval path for transferring or removing a departing user's assets.
Handle exceptions without creating unmanaged accounts
Most teams have users who do not fit the standard employee workflow: contractors, temporary collaborators, administrators, service accounts and emergency-access accounts. Decide how each category is created, reviewed and removed before exceptions accumulate.
Local accounts may be necessary in some environments, but they can create a separate lifecycle if they are not covered by the normal identity process. Define an owner, purpose, allowed access, review date and removal trigger for every exception. For emergency access, document how the account is protected and how its use is reviewed, using guidance appropriate to the application and your organization.
- List account categories and identify which are managed by the primary identity source.
- Give every non-person account a named human owner and a documented purpose.
- Set a review or expiry point for temporary and contractor access.
- Keep emergency access documented and test the approved recovery procedure.
- Check that exceptions are included in access reviews and departure procedures.
Test failure cases and identity changes
A lifecycle that works only under ideal conditions is not a reliable process. Build controlled tests for delays, interrupted connectivity and identity changes. The exact outcome depends on the integration and application, so use official documentation to determine what should happen and compare it with what you observe.
Pay particular attention to identity matching. A renamed user, changed email address, duplicate identity or recreated account could be matched, rejected or treated as a new person depending on the system. Do not assume which identifier is authoritative; confirm the rules before applying them to real accounts.
- Delay or pause a synchronization process, if your setup supports a safe test, and measure how the gap is detected and resolved.
- Test identity-provider unavailability against documented sign-in and account-management behavior.
- Use a test account to examine a renamed user and a changed email address.
- Check how duplicates, a deleted-and-recreated identity, and a failed provisioning attempt are reported.
- Record who investigates failures and how the team confirms that the final state is correct.
Build a repeatable test matrix
Turn the questions above into a small, repeatable acceptance test. Microsoft provides guidance for planning an automatic user-provisioning deployment; use the official documentation for your specific application and identity provider to add product-specific steps. The matrix below is a testing plan, not a claim about what any particular application supports.
Run it before adoption, after material changes to mappings or integrations, and as part of periodic access reviews where appropriate. Keep test identities separate from production users, and record the expected result, observed result, evidence and person responsible for follow-up.
- Create: Can the intended person be added through the documented route, and is the outcome visible to an administrator?
- Activate: What must the user do before access works, and what happens to an unaccepted invitation?
- Change access: Do additions and removals of roles or groups produce the intended permissions?
- Suspend or depart: Which login paths, sessions and credentials are affected, and which require separate action?
- Reactivate: Is the existing account restored, or is another process required? Confirm how identity matching and retained access are handled.
- Edge cases: What happens with delay, unavailable services, renamed users, duplicates and failed updates?
- Ownership: Who handles accounts, exceptions, assets and unresolved failures?
Assign ownership and assess the hosting model
A reliable process has a named owner for each step. Identity administrators may control source identities and group assignments, while application administrators may manage local roles, content and integrations. Write down where responsibilities meet, how exceptions are approved, and how a failed or delayed change is escalated.
Managed hosting can reduce infrastructure work, but it does not by itself establish how an application provisions users or how your organization governs access. Airbip offers managed deployment of catalog applications as Docker workloads on Airbip cloud servers, with routing and TLS automation, DNS checks, service lifecycle management and configurable backups. Those infrastructure capabilities should not be mistaken for a user-provisioning integration. Confirm application-specific account behavior separately and choose a deployment model that fits your identity, security and operational requirements.
- Name an owner for identity-source changes, application permissions and account exceptions.
- Document who reviews access and who is responsible for resolving provisioning mismatches.
- Define how user-owned data and integrations are handled when someone leaves.
- Use the application's and identity provider's current official documentation as the authority for supported behavior.
- Compare managed and self-managed deployment options against your operational requirements; hosting does not remove responsibility for access and data governance.
Frequently asked questions
What does user provisioning include?
It can include creating accounts, updating attributes or access, and disabling or deleting accounts across applications and systems. The exact steps depend on the application and the account-management method.
Does an identity-provider integration automatically handle every account lifecycle task?
Do not assume so. Verify documented support for account creation, updates, role or group changes, deactivation, sessions and credentials in both the identity provider and the application.
What should we test before adopting a self-hosted application?
Test account creation and activation, permission changes, deactivation, reactivation, identity changes, failure handling, exceptions and ownership of user-related content or integrations. Record expected and observed results.
Does managed hosting take responsibility for user access?
Not necessarily. Hosting may manage infrastructure tasks, but you should verify which account lifecycle capabilities the application provides and define who in your organization governs identities, permissions and user data.
Sources and further reading
- Plan an automatic user provisioning deployment for Microsoft Entra ID — Microsoft Learn
- What is User Provisioning & Deprovisioning? — OneLogin