Okta Profile Mapping: Sync Attributes Between Systems (2026)

Okta profile mapping lets you sync attributes between Okta and your connected applications, but it works by transforming data, not just copying it.

Let’s see it in action. Imagine you have an HR system (like Workday) as your source of truth for employee data and you want to provision users to a SaaS app (like Slack).

HR System (Workday) Source Attributes:

• givenName: "Jane"
• surname: "Doe"
• displayName: "Jane Doe"
• email: "jane.doe@example.com"
• employeeNumber: "12345"

SaaS App (Slack) Target Attributes:

• real_name: Needs to be the full name.
• email: Needs to be the user’s email.
• user_id: Needs to be a unique identifier.

Okta’s Universal Directory acts as the intermediary. When you set up an application integration, you define "Profile Mappings." These mappings tell Okta how to translate attributes from the source (e.g., Workday) to the target (e.g., Slack).

Here’s how you’d configure the mappings in Okta:

1. Navigate to your Application Integration: Go to Applications -> Applications, select your Slack app, and then go to the "Provisioning" tab.
2. Edit Profile Editor: Under "API Integration," click "Edit Profile Editor." You’ll see attributes for the target application (Slack).
3. Configure Mappings: Go to the "Mappings" section. You’ll see "Okta to App" and "App to Okta" mappings. For provisioning to Slack, you’re interested in "Okta to App."

Example Mappings:

• real_name (Slack) <- displayName (Okta/Workday):

  • This is a direct mapping. Okta takes the displayName attribute from the user’s Okta profile (which is synced from Workday) and assigns it to Slack’s real_name attribute.
  • Okta UI: Under "Mappings," find the real_name attribute. In the "Source" column, select displayName.

• email (Slack) <- email (Okta/Workday):

  • Another direct mapping. The user’s primary email in Okta is sent to Slack.
  • Okta UI: Find the email attribute. In the "Source" column, select email.

• user_id (Slack) <- employeeNumber (Okta/Workday) with a transformation:

  • Slack might require a specific format for its user ID, or you might want to ensure it’s globally unique. Here, we’ll use the employeeNumber but prepend it with a string to make it more distinct.
  • Okta UI: Find the user_id attribute. In the "Source" column, select employeeNumber. Then, click the "Edit" button for that mapping.
  • Transformation: You’ll see a "Transformation" section. You can use Okta Expression Language. For example, to prepend "EMP-" to the employee number:

    "EMP-" + String.join("", ${employeeNumber})
    

    This takes the employeeNumber attribute, converts it to a string (if it isn’t already), and concatenates "EMP-" to the beginning. So, employee 12345 becomes EMP-12345.

How it works under the hood:

When Okta provisions a user to Slack, it retrieves the user’s profile data from your source (e.g., Workday, or Okta’s Universal Directory if Workday is the source). It then applies these profile mappings. For each attribute in the target application (Slack), Okta looks at the defined "Source" and any transformations. It gathers the data, performs the transformation if specified, and then sends the transformed data to Slack via the SCIM API.

The real power comes with more complex transformations. You can combine attributes, use conditional logic, or even look up values from other attributes.

For instance, let’s say you want to set the department in your HR system to be the team attribute in a different application.

• team (New App) <- department (Okta/HR):
  • Okta UI: Find the team attribute in the target app’s profile editor.
  • Source: Select department.
  • Transformation: If you only want to sync departments like "Sales" or "Marketing" and map others to a default:

    if(or(eq(${department}, "Sales"), eq(${department}, "Marketing")), ${department}, "General")
    

    This expression checks if the department is "Sales" or "Marketing." If it is, it uses that value. Otherwise, it assigns "General."

This mapping process is crucial for maintaining data consistency and ensuring that applications receive the correct user information in the format they expect, even if the source system stores it differently.

The most counterintuitive aspect of Okta profile mapping is that the "Source" attribute in the mapping configuration isn’t always a direct one-to-one copy; it’s the input to a potential transformation function that dictates the final value sent to the target system.

Once you’ve mastered attribute mapping, the next logical step is to explore Lifecycle Management (LCM) for automating user onboarding and offboarding based on these profile attributes.