Okta Profile attributes can be overwritten by data during an application attribute import because Okta lacks attribute-level protection (guard rails) during this process.

Resolve this issue by configuring the application provisioning settings to enable or disable profile updates based on the organizational requirements. When an application imports profile updates, the application acts as the source of truth, causing the imported attributes to overwrite the existing Okta profile data.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Provisioning
• Profile Import
• Attributes
• Profiles

Okta does not have mandated attribute-level protection during an application to Okta import.

Understanding Inbound Attribute Imports and Org2Org Provisioning Behavior

In Okta, inbound profile attribute updates are controlled by the attribute flow from an application into Okta governed by Profile Sourcing, Attribute-Level Sourcing (Source Priority), and Attribute Mappings in the Profile Editor

• Application as Source of Truth (Inbound): When an application is designated as a profile source or an attribute-level source, attributes mapped from the application to Okta (App -> Okta) update the Okta user profile during imports or JIT provisioning events. 

• Okta as Source of Truth (Outbound): When outbound provisioning (Update User Attributes) is enabled under Provisioning > To App, changes made to the Okta user profile are pushed to the downstream application

How does Okta Org2Org provisioning handle attribute flow?

In the context of Okta Org2Org, Okta writes values fetched from the spoke to the application user and records the attribute source as IMPORT. The IMPORT source designates the application as the primary source for that attribute. Subsequent evaluations retain the imported value, and Okta does not re-apply the Okta to application mapping to overwrite it.

For example, the userName attribute retains the raw spoke value (<user@Domain.Okta.com>) instead of the mapped value (<user@AnotherDomain.Okta.com>).

Enabling the push profile updates setting prevents this behavior in two ways:

• The precondition (push disabled) becomes false, so Okta does not run the evaluation and never stamps the userName as IMPORT.
• Okta pushes the mapped username (<AnotherDomain.Okta.com>) to the spoke, so the Okta to application mapping governs the value.

NOTE: Enabling the push setting makes Okta authoritative and pushes all mapped attributes to the spoke. This represents a larger behavioral change for a hub-and-spoke Org2Org model and requires assessment against the intended design. 

Related References

• Provisioning Users through Org2Org - Users Are Imported with Email as Username