Question Regarding Entra SCIM Provisioning Exporting Old userName Value

Question

Question Regarding Entra SCIM Provisioning Exporting Old userName Value

Shree Varshan G 40

Hi Microsoft Team,

We are observing an issue with SCIM provisioning from to our application where the exported userName value during provisioning does not match the current User Principal Name (UPN) shown in Entra ID for a specific user.

Current observation:

Current UPN in Entra ID: <pii removed>@gmail.com

Exported userName in Provisioning Logs: <pii removed>@gmail.com

The <pii removed>@gmail.com value is an older/incorrect email and is no longer visible in the user's current Entra profile attributes.

Additional details:

The SCIM mapping is configured as: userPrincipalName -> userName

We tested multiple reprovisioning scenarios in another tenant and could not reproduce the behavior.

On-Demand Provisioning was executed for the affected user, but Entra provisioning still exported the old userName value.

Newly created and reprovisioned users export the correct/latest UPN as expected.
I tested manually changed the upn and done an on demand provisioning it works by sending the latest upn

Could you help clarify:

Under what conditions can Entra provisioning continue exporting an older userName value even after the UPN has changed?
Why provision on demand sending the some email address that is not a upn

Regards,

Shree

Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-05-22T06:50:59.6533333+00:00
Hello Shree Varshan G

Thank you for reaching out to Microsoft Q&A.

It looks like what you’re seeing is a by-design behavior of the Entra SCIM provisioning engine. Here’s what’s happening and how to fix it:

Why you still see the old “userName”

In SCIM the “userName” attribute is treated like the object’s primary key in the target system. By default the provisioning service only sends it on the initial Add operation (when the target object is created).

Later, when you change the userPrincipalName (UPN) in Entra ID, the provisioning job runs as a delta (an Update), and it only patches attributes that are configured to flow on update. Because “userName” was only mapped for the Add flow, the provisioning service never includes it in the patch, so the target sees (and logs) the original value.

Why “Provision on demand” is still exporting the old email

On-demand provisioning in the portal just triggers the same delta sync pipeline. It won’t automatically re-send attributes that aren’t flagged for update. So even though you kicked it off manually, it saw no change in “userName” from its point of view and sent the cached value.

How to get your new UPN to flow through

Go to your Enterprise App in the Azure portal → Provisioning → Attribute mappings → Show advanced.

Find the mapping for userName (Source = userPrincipalName → Target = userName).

Edit it so that the flow is allowed on both Create and Update (or set FlowType = Always).

Save and then either:

Run another full sync (Start-Provisioning cycle with PolicyType = Full), or

Delete the user in the target SCIM system so it’s re-created with the new UPN.

After that you should see the correct “userName” in your provisioning logs.

Reference docs:

Customizing User Provisioning Attribute Mappings for SaaS Applications https://docs.microsoft.com/azure/active-directory/manage-apps/customize-application-attributes

On-demand provisioning deep dive https://docs.microsoft.com/azure/active-directory/app-provisioning/provision-on-demand

Map User provisioning attributes overview https://docs.microsoft.com/azure/active-directory/manage-apps/define-conditional-rules-for-provisioning-user-accountsIf the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".
Shree Varshan G 40 Reputation points

2026-05-22T19:00:46.5566667+00:00
Hi,

I tried the approach that you suggested, but I am still observing a provisioning behavior in Microsoft Entra ID where the values for userName and emails``[type eq "work"]``.value appear to be interchanged during SCIM provisioning.

Example:

Current Entra user attributes:

userPrincipalName = ******@gmail.com

mail = ******@gmail.com

The user also has multiple alias email addresses configured, and one of the aliases is:

******@gmail.com

Current SCIM mappings:

userPrincipalName -> userName

mail -> emails``[type eq "work"]``.value

However, during provisioning we are observing:

userName being sent as ******@gmail.com (one of the alias email values)

Primary email in the target application becoming ******@gmail.com

mail still being sent as ******@gmail.com

So effectively:

the alias email value is appearing in place of userName

the UPN/mail value is appearing in place of the email field

We would like to understand:

Under what scenarios can this behavior occur?

Can SCIM correlation/matching logic cause previously provisioned alias values to continue flowing as userName?

Can Entra internally preserve or reuse historical identifiers during update flows even when the attribute mappings are configured correctly?

Could alias/Primary SMTP resolution from Exchange Online affect the userName value exported during provisioning?

I have attached the current attribute mapping configuration for reference.
Shree Varshan G 40 Reputation points

2026-05-26T09:30:28.2466667+00:00

thanks for the detailed explanation i will give it a try and let you know
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-05-27T02:34:55.7066667+00:00

Shree Varshan G

You're welcome.
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-05-29T08:35:07.43+00:00

Shree Varshan GFollowing up to check if the resolution provided was helpful. Let us know if you need any further assistance.
Shree Varshan G 40 Reputation points

2026-05-29T10:28:02.5866667+00:00

it perfectly works when I removed the contact and resync and tried using Provision on Demand, thanks for prompt assistance
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-06-01T03:40:51.7333333+00:00

Shree Varshan G

You're welcome.

If the resolution was helpful, please take a moment to accept the answer and upvote it 👍 to make it helpful to the community.

Answer accepted by question author

Sina Salam 31,376 Volunteer Moderator

Hello Shree Varshan G,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you have Question Regarding Entra SCIM Provisioning Exporting Old userName Value.

Most of all, regarding your questions:

Under what conditions can Entra provisioning continue exporting an older userName value even after the UPN has changed?

When:

User already matched using old value
Matching attribute still resolves to that identity
Target object holds legacy identifier

Why provision on demand sending the some email address that is not a upn

Because:

It uses same matching and correlation engine
It does NOT bypass identity linkage - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/provision-on-demand

The cause is not simply the userPrincipalName → userName mapping. The issue is caused by the existing provisioning matching/correlation state between Microsoft Entra ID and the target SCIM application. - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/how-provisioning-works, https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes

The best practice advice to you is to:

Review the SCIM user attribute mappings and confirm which attribute is configured for “Match objects using this attribute.”- https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes
Stop using a mutable value such as userPrincipalName, mail, or email address as the primary matching attribute if those values can change. - https://microsoft.github.io/zerotrustassessment/docs/workshop-guidance/identity/RMI_120
Use a stable immutable identifier for matching, preferably: Microsoft Entra ID objectId > SCIM externalId
Keep the display/login value mapping separately as: userPrincipalName > userName
Break the old correlation for the affected user by removing the user from the application scope or deleting the stale target SCIM user, then re-provision the user cleanly after the matching rule is corrected.
Restart provisioning and run Provision on demand again to confirm that the current UPN is now exported to userName. On-demand provisioning uses the same provisioning configuration, mapping, and matching logic as normal provisioning, so it is useful for validating the corrected configuration. - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/provision-on-demand

After the matching rule is changed to an immutable identifier and the stale target correlation is removed, Microsoft Entra will correctly identify the target account by externalId and export the current UPN into userName as expected.

Use the below official Microsoft resources for more reading and steps:

Microsoft Entra provisioning architecture: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/how-provisioning-works
Customize Microsoft Entra attribute mappings: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes
On-demand provisioning in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/provision-on-demand
SCIM support in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/scim-support-in-entra-id

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

0 comments

1 additional answer

Your answer

Shree Varshan G 40 Reputation points

2026-05-22T19:00:46.5566667+00:00

Hi,

I tried the approach that you suggested, but I am still observing a provisioning behavior in Microsoft Entra ID where the values for userName and emails``[type eq "work"]``.value appear to be interchanged during SCIM provisioning.

Example:

Current Entra user attributes:

userPrincipalName = ******@gmail.com

mail = ******@gmail.com

The user also has multiple alias email addresses configured, and one of the aliases is:

******@gmail.com

Current SCIM mappings:

userPrincipalName -> userName

mail -> emails``[type eq "work"]``.value

However, during provisioning we are observing:

userName being sent as ******@gmail.com (one of the alias email values)

Primary email in the target application becoming ******@gmail.com

mail still being sent as ******@gmail.com

So effectively:

the alias email value is appearing in place of userName

the UPN/mail value is appearing in place of the email field

We would like to understand:

Under what scenarios can this behavior occur?

Can SCIM correlation/matching logic cause previously provisioned alias values to continue flowing as userName?

Can Entra internally preserve or reuse historical identifiers during update flows even when the attribute mappings are configured correctly?

Could alias/Primary SMTP resolution from Exchange Online affect the userName value exported during provisioning?

I have attached the current attribute mapping configuration for reference.
Shree Varshan G 40 Reputation points

2026-05-26T09:30:28.2466667+00:00

thanks for the detailed explanation i will give it a try and let you know
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-05-27T02:34:55.7066667+00:00

Shree Varshan G

You're welcome.
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-05-29T08:35:07.43+00:00

Shree Varshan GFollowing up to check if the resolution provided was helpful. Let us know if you need any further assistance.
Shree Varshan G 40 Reputation points

2026-05-29T10:28:02.5866667+00:00

it perfectly works when I removed the contact and resync and tried using Provision on Demand, thanks for prompt assistance
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-06-01T03:40:51.7333333+00:00

Shree Varshan G

You're welcome.

If the resolution was helpful, please take a moment to accept the answer and upvote it 👍 to make it helpful to the community.

Answer 1

Shree Varshan G

Thank you for your reply.

Why you are seeing alias (******@gmail.com) as userName

This behavior is not random — it occurs due to a combination of SCIM identity anchoring, matching logic, and source attribute resolution differences (Exchange vs Entra).

1. userName acts as the persistent identifier (anchor)

In SCIM, userName is commonly treated as a unique identifier/login ID.

https://community.rsa.com/s/article/User-Provisioning-Using-SCIM-API-1e4ce6aa

Once a user is created in the target system, Entra provisioning correlates future updates using the previously sent identifier.

Even if the Entra attribute (UPN) changes, the provisioning service may continue to:

reuse the original value (cached / matched value)

or use a value returned by the target during matching

This explains why an old alias or previously used email can continue appearing as userName.

2. Matching / correlation can override mapping behavior

In provisioning:

Entra does not blindly push mappings every time

Instead, it:

Finds the existing user in the target

Matches based on identifiers (userName, emails, externalId, etc.)

Uses that identity for updates

If your target system:

treats emails[type eq "work"].value as unique identifier

OR returns alias (******@gmail.com) as primary

Entra may reuse that value for userName during updates, even though mapping says UPN.

3. Exchange / proxyAddresses influence

Your scenario strongly indicates Exchange-backed attributes:

Users have:

UPN = ******@gmail.com

Primary mail = ******@gmail.com

Alias = ******@gmail.com

In Microsoft Entra:

Email-related attributes come from Exchange attributes like proxyAddresses and mailNickname

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname

Different services may resolve:

Primary SMTP

Alias

mail attribute

Depending on synchronization timing and attribute source:

Alias (******@gmail.com) can still be considered authoritative in some flows

4. Attribute mapping is NOT strictly authoritative on updates

Even with correct mapping:

userPrincipalName -> userName

mail -> emails[type eq "work"].value

Entra provisioning engine:

uses delta sync logic

only updates attributes when change is detected AND allowed in flow settings

Matching + cached state can still override mapping

Microsoft explicitly states mappings must be carefully aligned, otherwise:

incorrect or unintended values can be provisioned if mappings don’t align with application schema and identity logic

https://microsoft.github.io/zerotrustassessment/docs/workshop-guidance/identity/RMI_120

5. Why values look “interchanged”

Observed:

userName = alias (abc)

emails = primary (def)

This typically happens when:

Target system:

promotes alias as login/identifier

Entra:

still sends mail correctly

But correlation phase influences userName selection

So, it is not true swapping — it is:

Different attributes being sourced from different identity anchors

Below is the recommended resolution: -

Option 1 — Force deterministic mapping

Update mappings:

Set userName mapping to:

FlowType = Always (Create + Update)

This ensures UPN is always re-sent (not just on create)

Doc: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes

Option 2 — Change correlation strategy

Update Matching precedence:

Prefer:

externalId (objectId) (already correct in your screenshot)

Avoid:

matching based on emails or userName if target behaves differently

This prevents alias-based re-correlation

Option 3 — Reset target identity

Because SCIM is stateful:

Delete user from target system

OR

Use:

“Restart provisioning with clear state”

Forces:

fresh Create call

correct userName = UPN

Option 4 — Align email mapping source

Instead of:

mail → emails[type eq "work"].value

Use (recommended in many integrations):

userPrincipalName → emails[type eq "work"].value

Ensures:

both userName and emails come from same source

avoids alias confusion

https://facilio.com/help/docs/admin-guide/users-and-control/user-management/scim-provisioning/scim-azure-ad/

Option 5 — Validate Exchange attributes

Check in user object:

proxyAddresses

Primary SMTP (uppercase SMTP:)

Aliases (smtp:)

Ensure:

correct primary email is set

no stale alias marked incorrectly

Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-06-02T05:20:32.72+00:00

Shree Varshan G

If the resolution was helpful, please take a moment to accept the answer to make it helpful to the community.

Thank you for contacting Microsoft Q&A!
Shree Varshan G 40 Reputation points

2026-06-02T06:36:34.78+00:00

one thing i need an help from you can you assign a moderator to answer this question i cannot find an option to ask answer from moderator please help me

https://learn.microsoft.com/en-us/answers/questions/5908661/teams-incoming-webhook-403-error-in-lambda-worked