Why the External ID is Necessary for Okta Provisioning to Downstream Applications
Last Updated:
Overview
When provisioning users to downstream applications, an external ID is required for System for Cross-domain Identity Management (SCIM) capable applications. Without an external ID, Okta cannot push updates or deactivate users in the downstream application. Review the service provider documentation and ensure provisioning is enabled before assigning users to generate the required external ID.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Provisioning
- External ID
Solution
Why is the external ID necessary for Okta provisioning?
Users lacking an external ID experience disrupted provisioning functionality, as Okta is unable to push updates or deactivations. Review the service provider documentation regarding Create, Read, Update, and Deactivation (CRUD) operations for the specific API. Review the following image for a sample external ID from a Salesforce integration.
Ensure successful downstream provisioning by reviewing the following external ID requirements and behaviors.
- Provisioning must be enabled before users are assigned to the Okta application to receive an external ID.
- If provisioning options are modified without an external ID in the user profile, such as in a Microsoft Office 365 application instance, Okta cannot provision the user downstream.
- Users must have an external ID in the user profile for the application instance for downstream provisioning to function. Every application with provisioning enabled generates a unique external ID once the user is added to the application instance.
Why might the external ID change for the same user?
The external ID might differ if the provisioning flow occurs multiple times for the same user, to the same application, with the same username. Identify why an external ID differs for the same user by reviewing the following common causes.
- The previous user account was completely deleted on the application side.
- The application provisioning API always uses a new external ID during provisioning and cannot use the previous external ID by design.
