Microsoft Entra ID Provisioning: SelectUniqueValue and the "Apply this mapping" limitation

In Microsoft Entra ID's provisioning service, the SelectUniqueValue() expression has a specific restriction:

When an attribute mapping uses SelectUniqueValue(), the "Apply this mapping" setting must be configured as "Only during object creation." It cannot be configured as "Always."

This restriction is related to how the provisioning engine generates unique attribute values and how those values are maintained throughout an object's lifecycle.

1. How SelectUniqueValue() works

The SelectUniqueValue() function evaluates a list of candidate values in priority order and selects the first value that does not conflict with an existing value in the target directory.

For example, consider generating a user's userPrincipalName:

SelectUniqueValue( Join("", [FirstName], [LastName], "@company.com"), Join("", [FirstName], ".", [LastName], "@company.com"), Join("", [FirstName], [LastName], [EmployeeID], "@company.com") )

The provisioning engine evaluates candidates in sequence:

1. JohnSmith _AT_ company.com
2. John.Smith _AT_ company.com
3. JohnSmith12345 _AT_ company.com

It selects the first available candidate.

The important distinction is that this is a uniqueness-selection operation, not simply a string transformation.

2. Why the "Always" setting is incompatible

Consider the following scenario.

Initial provisioning

Two employees exist:

The second employee receives the alternate UPN because the preferred value is already taken.

Subsequent provisioning cycles

Suppose Employee 100 leaves the organization and email address removed for privacy reasons eventually becomes available.

If SelectUniqueValue() were evaluated continuously as an ordinary update mapping, Employee 200 could potentially receive a different result:

That could result in an unwanted identity change, even though Employee 200's name and other source attributes have not changed.

Restricting the mapping to object creation avoids this class of problem.

There is also an important implementation distinction: selecting a unique value during creation is different from evaluating whether an existing object's current value should be retained during an update. The latter requires preserving identity stability, not merely finding an available candidate.

The example illustrates the design rationale; it does not establish that Microsoft's engine would actually perform that reassignment if the restriction were removed.

3. What Microsoft officially documents

Microsoft explicitly states that:

• SelectUniqueValue() is intended only for object creation.
• The mapping must use Only during object creation.
• The function must be top-level and cannot be nested inside another function.
• The target attribute cannot have a matching precedence configured.

These are documented product restrictions, not merely recommended practices.

Microsoft Learn+1

Microsoft does not explain the internal implementation reason for the creation-only restriction in that documentation. The identity-stability explanation above is a plausible rationale, rather than a confirmed statement from Microsoft engineering.

Official reference: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/functions-for-customizing-application-data?utm_source=chatgpt.com#selectuniquevalue

4. Implications for Workday-to-Active Directory (or any external directory) provisioning

This limitation becomes particularly relevant when provisioning sAMAccountName or userPrincipalName from Workday.

Suppose an employee's last name changes:

With SelectUniqueValue() configured for object creation, the provisioning service will not reevaluate the UPN mapping for the existing AD user.

Consequently, you cannot use that same mapping to both:

1. Generate a collision-free UPN when creating a user.
2. Automatically update the UPN when Workday reports a name change.

5. Feature Request / Future Development: Removing the SelectUniqueValue() Restriction

Microsoft could significantly improve the Entra ID provisioning service by extending SelectUniqueValue() to support the "Always" attribute mapping setting, allowing uniqueness validation during both object creation and subsequent updates.

The current restriction creates a functional gap in identity lifecycle management, particularly for organizations integrating authoritative HR systems such as Workday with Active Directory.

5.1 Proposed enhancement

Microsoft should introduce an update-aware implementation of SelectUniqueValue() that supports the following behaviors:

1. Preserve existing values: If the target attribute already contains a valid value and the source attributes have not changed, retain that value rather than selecting a different candidate.
2. Detect source attribute changes: When an authoritative source attribute changes, such as FirstName, LastName, or PreferredName, reevaluate the expression and determine whether an identity update is appropriate.
3. Perform uniqueness validation: Evaluate candidate values against existing objects in the target directory, excluding the object currently being updated.
4. Support collision-free updates: If the preferred candidate is already assigned to another object, evaluate subsequent candidates in the expression, just as the function does during initial provisioning.
5. Maintain identity stability: Prevent unintended renaming simply because a previously unavailable candidate becomes available.

5.2 Proposed configuration options

Rather than simply removing the restriction, Microsoft could introduce an additional configuration setting governing how uniqueness expressions behave during updates.

The "Always — Reevaluate on Source Change" option would be particularly valuable for HR-driven identity provisioning.

5.3 Technical considerations for Microsoft

To implement this functionality reliably, Microsoft would need to address several technical challenges.

Self-exclusion during uniqueness checks

When evaluating a candidate against Active Directory, the provisioning engine must exclude the current object's identity from the uniqueness search. Otherwise, the existing user could incorrectly be identified as a collision with themselves.

Concurrency and race conditions

Two provisioning operations could generate the same candidate simultaneously. Microsoft should ensure that uniqueness is revalidated immediately before committing an attribute change, with appropriate conflict handling.

Distinguishing source changes from directory changes

A newly available username should not automatically trigger a rename. The engine should distinguish between changes in authoritative source attributes and changes in the availability of candidate values.

Safe updates to identity attributes

Updates to userPrincipalName, sAMAccountName, and other identity-related attributes can affect authentication, email addressing, and downstream applications. The feature should provide optional controls for preserving existing values, auditing changes, and restricting automatic renaming.

5.4 Business justification

This enhancement would deliver several benefits:

• Complete identity lifecycle automation: Support initial provisioning and subsequent identity changes using the same expression framework.
• Reduced administrative overhead: Eliminate the need for custom PowerShell scripts, scheduled tasks, or external automation solely to manage uniqueness during updates.
• Consistent naming policies: Apply the same collision-handling rules throughout an employee's lifecycle.
• Improved reliability: Reduce the risk of duplicate identities and inconsistent naming conventions.
• Better HR integration: Allow Workday and other authoritative HR systems to drive name changes without requiring separate provisioning mechanisms.

5.5 Recommended feature request to Microsoft

Feature Request: Support SelectUniqueValue() with "Always" Attribute Mapping in Microsoft Entra ID Provisioning

Product: Microsoft Entra ID — Inbound HR Provisioning / Workday to Active Directory

Current Limitation:

The SelectUniqueValue() expression is restricted to attribute mappings configured with "Apply this mapping" set to "Only during object creation."

This prevents organizations from using the provisioning service's built-in uniqueness validation when updating existing Active Directory objects.

Requested Enhancement:

Extend SelectUniqueValue() to support the "Always" mapping option, enabling uniqueness validation during both object creation and updates.

The enhanced functionality should:

1. Exclude the current target object from uniqueness checks.
2. Support reevaluation when relevant source attributes change.
3. Preserve existing values when no relevant changes have occurred.
4. Evaluate alternate candidates when a proposed value conflicts with another directory object.
5. Provide configurable controls to prevent unintended identity changes.

Business Impact:

Organizations using Workday or other HR systems as authoritative identity sources cannot fully automate changes to identity attributes such as userPrincipalName and sAMAccountName while maintaining uniqueness through the native provisioning expression engine.

This limitation requires additional automation outside Microsoft Entra ID, increasing operational complexity, maintenance requirements, and potential points of failure.

Expected Outcome:

Enable Microsoft Entra ID provisioning to provide consistent, collision-aware identity attribute management throughout the complete employee lifecycle, including initial hiring, name changes, rehiring, and other HR-driven identity updates.

This enhancement would reduce dependence on external scripts and improve the completeness of Microsoft's native HR-driven identity provisioning capabilities.

5.6 Current Microsoft position

Microsoft's documentation continues to explicitly restrict SelectUniqueValue() to object creation. I found no documented commitment or announced release date for update support.

Microsoft Learn+1

The feature request above is therefore a proposed product enhancement, not an existing capability or announced roadmap item.