Provision and deprovision

Once you've activated or deactivated a user in Okta, you can take a variety of actions using third-party apps in Workflows.

Summary

Problem: Deeply and flexibly activate, provision, or deactivate users across systems or identity domains. Enterprises often have granular and/or app-specific needs around flexible and customizable provisioning, beyond what is supported by out-of-the-box lifecycle management solutions.

Solution: Build custom provisioning flows with Workflows. When a user's status changes, such as when a user is added, deactivated, or assigned an app in Okta, provisioning or deprovisioning events are triggered in multiple systems.

Example Applications: Salesforce, Office 365 Admin, Slack Admin, and Box. For the full list of Workflows connectors, see Connectors.

Tutorial

For a detailed tutorial to implement this flow, see Tutorial: User provisioning to Salesforce.

Sample Flow 1

Sample Flow 2

Guidelines and limitations

• If out-of-the-box lifecycle provisioning and Workflows provisioning are combined in the same Flow, conflicting actions may occur. For example, if you want to manage the onboarding of Slack users using Workflows, you should not use the standard lifecycle management connector at the same time.
• The rate limits of downstream apps can prevent the successful execution of Flows.
• Okta event hooks have a daily limit of 100,000 events per org per day.
• Flows can only be paused for a maximum of 30 days.
• Storing data in a Flow is not recommended. Because data can become stale, it is recommended to store a state token or time stamp in a table, spreadsheet, or the Okta user/appUser itself, and rerun a query for the relevant user and resource on a schedule using that criterion.
• Workflows system-wide limits also apply. See Learn about Workflows best practices and limits.