Use case: 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 of Use Case

Problem: Deeply and flexibly activate, provision, or deactivate users across systems or identity domains. Enterprises often have granular and/or appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in.-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 AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page., Slack Admin, and Box. See Workflows' full list of available connectors.


For a detailed tutorial to implement this flow, see User Provisioning to Salesforce.

Sample Flow 1

Use case 1 sample workflow

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 orgThe Okta container that represents a real-world organization. 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 Limits.