About profile mastering

A profile master is an application that acts as the source of truth for user identities. Once enabled from the app or directory's Provisioning tab, it appears in the list of profile masters on the Profile Masters page. If an external profile master is not identified, all profiles are mastered by Okta.

If more than one profile master exists on the Profile Masters page, you can prioritize them so that users can be mastered by different systems, based on their assignments. At any given time, there can only be one profile master that masters a user's entire profile.

Profile masters are powerful tools that can help you manage a user's entire life cycle (creation, updates, and deactivation). For example, use Workday as a profile master to send user creation, updates, and termination events from Workday to Okta.

Here are some of the apps and directories that allow profile mastering:

  • Active Directory
  • BambooHR
  • G Suite
  • LDAP
  • NetSuite
  • Namely (build by ISV)
  • Salesforce
  • SuccessFactors
  • UltiPro
  • Workday

Enable Profile Master and Update User Attributes

Enabling Profile Master and Update User Attributes for the same application lets you push Okta to App profile mappings to the highest priority profile master. This is beneficial when you want to sync attributes such as an email address and phone number from downstream applications back to the profile master. However, you may lose data if an app that designated as a profile master can also receive profile updates from Okta.

Before you enable Profile Master and Update User Attributes for the same app, consider the following:

  • Unwanted profile pushes - Okta updates can overwrite the values of unmapped attributes in an app, even if that app is the highest priority profile master. For example, if the cn attribute is not mapped from Active Directory to Okta, and you've configured Active Directory for Profile Master and Update User Attributes, - Okta applies default mapping to cn.
  • Overwritten IdP-mastered attributes - - Okta to app updates can overwrite attributes that are mastered by another identity source. There's no partial push option.
  • Race conditions - Okta can overwrite an updated attribute in an identity source before other updates are pushed back to - Okta. For example, consider a scenario in which a user's first name and last name are imported into Okta from a directory, but the user's email address is imported into Okta from an app. If the user's last name changes in the directory before the applicable email address update is made in the app, - Okta could push the new name and the old email address.

Rules for incoming imports

Using a profile master necessitates a clear distinction between new imported users and updates to current Okta users. Okta uses matching rules to maintain a link between the profile master source and Okta to prevent conflicts. See User Creation & Matching in Provisioning and Deprovisioning.

Profile mastering and the user life cycle

The flow of a user's identity throughout the different cycles of access (creation, update, and removal of access to resources) is known as a user’s life cycle. A profile master can determine the beginning of this cycle, and is enabled within the provisioning and import space. See Provisioning and Deprovisioning.