Attribute mappings
You use attribute mappings to control what attributes are exchanged during the provisioning process. These are the two types of attribute mapping:
Attribute definitions, how attributes are mapped, and the apps to which users are assigned are what determines the data that's exchanged during provisioning.
Attribute mappings can be bidirectional. You can map default Okta user profile attributes to app user attributes, or from the app to Okta user profile attributes.
The app request workflow can't be used with apps that have required personal attributes.
App to Okta attribute mapping
With this type of attribute mapping, multiple or single instances of directories or human resources apps are used as a source of truth. Attribute mappings define how attributes from these sources are imported into the Okta user profile.
In the following diagram, Active Directory (AD) and Workday supply the Okta user profile with the FirstName, LastName, and Boss attributes. The AD attributes givenName and sn are mapped to the Okta attributes FirstName and LastName and the Workday attribute managerUserName is mapped to the Okta attribute Boss.
Okta to app attribute mapping
With this type of attribute mapping, data is pushed from Okta to other apps to provision and update user accounts.
Mapping attributes that aren't in the Okta user profile, such as those from different sources like LDAP, isn't supported. Mappings are applied when the Okta user profile is updated, and not when the source profile is updated. To ensure mapped data is consistently sent to target apps, the expressions used in profile mappings should only include Okta user profile attributes.
In this diagram, Okta sends four user profile attributes to four corresponding user profile attributes in Google.
Attributes aren't updated or reapplied when the user's group membership changes.