About attribute mappings

You use attribute mappings to control what attributes are exchanged during the provisioning process. These are the two types of attribute mapping:

The data that is exchanged during provisioning is determined by the attribute definitions and how the attributes are mapped between the source of the data, and the applications to which users are assigned.

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 cannot 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 applications are used as a source of truth. Attribute mappings define how attributes from these sources are imported into the Okta user profile.

In this 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.

User-added image

Okta to app attribute mapping

With this type of attribute mapping, data is pushed from Okta to other applications to provision and update user accounts.

Mapping attributes that aren’t in the Okta user profile, such as those from different sources like LDAP, is not 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 applications, 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.

User-added image

Attributes are not updated or reapplied when the user’s group membership changes.