Lifecycle of a provisioned user
As part of Okta Lifecycle Management (LCM), provisioning helps orgs automate the IT processes that are associated with an individual joining, moving within, or leaving an org. This flow of a user's identity through different stages is known as a user's lifecycle state change.
Events that trigger a lifecycle state change—such as an employee position change, termination, or the expiration of an external app license—initiate processes to ensure that access to resources remains compliant with business and security policies.
The following diagram outlines how the different events during a typical employee's tenure at an organization trigger user lifecycle changes:
The employee is hired
When an employee is hired, human resources (HR) must create an account for them. In most organizations, a combination of HR, information technology (IT), and supervisors grant access to the apps and accounts that the employee needs to perform their job. These groups also introduce and enforce the organization's security requirements. With the growing usage of cloud-based apps, IT organizations may need to manage user accounts through a different administrator console for each app.
In a provisioned environment, a new user account is created in your organization's user store and, based on roles and profile needs, the profile information flows down through your Okta app integrations out to all the external apps to create the accounts that the new user requires. Users can be imported from an external app or directory service, or they can be manually created in Okta.
The employee is promoted, changes roles, or requires different software tools
In these scenarios, user access requirements change. Organizations may restructure or acquire new businesses, bringing along new employees. They can also require temporary or permanent access to app integrations for contractors and partners.
In your provisioned environment, the existing user account is updated in the source of truth to reflect the new changes. The updates are sent through Okta out to the external apps, changing access levels, adding or removing group membership, or even synchronizing passwords. This keeps the user profile in the external app in sync with the Okta user profile.
An app is removed from an employee
This scenario arises if a user no longer needs an external app or the app is no longer available to the user (for example, the software license expired). The user account is updated and the access to that app is removed. Deprovisioning access to the external app is important for compliance reasons and to help you maintain an accurate usage count for your apps.
Employee changes groups
When a user is removed from a group that provided them with access to certain app integrations, the user is automatically deprovisioned from those app integrations. When added as a member of a group, the user inherits access to the app integrations that have been granted to the group.
Employee leaves an organization
When an employee leaves an organization, the responsible department (usually HR) initiates the automatic process to fully deprovision the user. Deprovisioning ensures that persons who are no longer in your organization don't have access to sensitive apps and data.
You can deprovision users directly in Okta or from an external user store, such as Active Directory or Salesforce.
During the deprovisioning process, the user account is deactivated in the Okta Universal Directory, access to Okta app integrations is removed, and their accounts are automatically deactivated in external apps. If manual deprovisioning of the user account for any app is required, admins receive a notice in their dashboard.
Employee returns to an organization
If the employee returns to the organization (for example, after a return from leave), reactivating the user in Okta Universal Directory also reactivates the user's accounts in the external apps.