Okta Provisioning & SCIM — OIN, Lifecycle & Group Push

① SCIM 2.0 and the Okta Integration Network

SCIM 2.0 (System for Cross-domain Identity Management) is the open REST standard that defines how identity providers push and receive user and group objects. Okta implements SCIM 2.0 as its core provisioning protocol: when Okta provisions a user to an app, it makes a SCIM POST /Users call; when it updates a user it sends a PATCH; when it deactivates it sends a PATCH setting active=false. No proprietary format, no custom scripts.

The Okta Integration Network (OIN) is the catalog of pre-built integrations. For provisioning, an OIN-listed connector already implements the required SCIM endpoints on the app side and has been tested by Okta. Enabling provisioning for an OIN app is a matter of entering the SCIM base URL, an auth token, and toggling the capabilities you need — Create Users, Update User Attributes, Deactivate Users, Group Push. The OIN removes weeks of custom connector work for the most common SaaS targets.

② Outbound provisioning — pushing from Okta to apps

Outbound provisioning flows from Okta (the IdP/authoritative source) into a target application. The Admin Console surfaces this as the To App tab under the app's Provisioning settings. Four capabilities can be toggled independently: Create Users (create the account in the app when a user is assigned), Update User Attributes (sync profile changes), Deactivate Users (disable the account when unassigned or deactivated in Okta), and Sync Password (for apps that support it).

Assignment is the trigger: a user or group is assigned to the app (directly or via a group rule), and provisioning fires. The Okta profile fields that flow to the app are controlled by the attribute mappings — each mapping names the Okta field, the app field and the direction/priority. You can use expressions (Okta Expression Language) to transform values, e.g. concatenating first and last name for a displayName field.

Common outbound pitfalls

Watch for conflicting mappings (two rules writing the same app field), deactivation not enabled (ghost accounts pile up), and sync delays on large directories — Okta queues provisioning tasks, so a bulk import can take time to flush.

③ Inbound provisioning and attribute mappings

Inbound provisioning is the reverse: an external system (another IdP, an HR platform, or a custom app) pushes user records into Okta. Okta exposes its own SCIM 2.0 API so authoritative sources like Workday, BambooHR or a custom HRMS can create, update and deactivate Okta user accounts directly — making the HR system the master record and Okta the downstream consumer.

The From App tab in the Provisioning settings controls inbound capabilities: Import New Users and Profile Updates (pull records on a schedule or on demand), Import Groups (mirror app-side groups into Okta groups), and the Okta Profile Editor decides whether imported attributes can overwrite the Okta master profile or only fill in gaps (priority-based mapping). Inbound sync typically runs on a schedule — every few hours — or can be triggered manually from the Import tab.

Attribute mapping mechanics

Every provisioning integration has an attribute mapping table in the Okta Profile Editor. Each row maps an Okta Universal Directory attribute to the app attribute, specifies direction (To App / From App / Both / None), and can apply an Okta Expression Language transform. The mapping priority for multi-source environments determines which source wins when two systems try to write the same Okta attribute.

④ Full lifecycle & Group Push

The Okta provisioning lifecycle follows the CRUD model with a twist on Delete: Create (user assigned to app → account created), Read/Import (import or sync pulls current state), Update (profile or group change triggers a SCIM PATCH), and Deactivate (unassign or deactivate in Okta → active=false in the app — Okta deliberately deactivates rather than deletes to preserve audit records in the target). A hard delete only happens if the app integration is configured to support it and the admin explicitly enables it.

Group Push is a dedicated outbound capability that syncs Okta groups — and their membership — to groups in the target app. Each pushed group maps to an app-side group (the mapping can be by name or by explicit rule). When a user joins or leaves the Okta group, the push syncs the membership change within minutes. Group Push does not support custom group attributes in Okta — only standard group name and description flow.

Lifecycle in an exam scenario

The key interview line: Okta deactivates, not deletes. A leaver whose Okta account is deactivated has their app accounts set to active=false via SCIM — access is cut but the account and audit trail remain. Deletion requires an explicit extra step and is usually governed by a retention policy, not the provisioning engine.