Update claims-mapping.md

Gargi-Sinha · web-flow · commit 7fa2f08ee3b8 · 2023-08-30T08:31:44.000-07:00
diff --git a/articles/active-directory/external-identities/claims-mapping.md b/articles/active-directory/external-identities/claims-mapping.md
@@ -36,7 +36,7 @@ For information about how to add and edit claims, see [Customizing claims issued
 
 If you need to issue the UPN value as an application token claim, the actual claim mapping may behave differently for B2B users. If the B2B user authenticates with an external Azure AD identity and you issue user.userprincipalname as the source attribute, Azure AD instead issues the mail attribute.  
 
-For example, let’s say you invite an external user whose email is `james@contoso.com` and whose identity exists in an external Azure AD tenant. James’ UPN in the inviting tenant is created from the invited email and the inviting tenant's original default domain. So, let’s say James’ UPN becomes `James_contoso.com#EXT#@fabrikam.onmicrosoft.com`. For SAML application that issues user.userprincipalname as the NameID, the value passed for James is `james@contoso.com`.  
+For example, let’s say you invite an external user whose email is `james@contoso.com` and whose identity exists in an external Azure AD tenant. James’ UPN in the inviting tenant is created from the invited email and the inviting tenant's original default domain. So, let’s say James’ UPN becomes `James_contoso.com#EXT#@fabrikam.onmicrosoft.com`. For the SAML application that issues user.userprincipalname as the NameID, the value passed for James is `james@contoso.com`.  
 
 All [other external identity types](redemption-experience.md#invitation-redemption-flow) such as SAML/WS-Fed, Google, Email OTP issues the UPN value rather than the email value when you issue user.userprincipalname as a claim. If you want the actual UPN to be issued in the token claim for all B2B users, you can set user.localuserprincipalname as the source attribute instead. 
 

-Original file line number
+Diff line change
 If you need to issue the UPN value as an application token claim, the actual claim mapping may behave differently for B2B users. If the B2B user authenticates with an external Azure AD identity and you issue user.userprincipalname as the source attribute, Azure AD instead issues the mail attribute.
 -For example, let’s say you invite an external user whose email is `[email protected]` and whose identity exists in an external Azure AD tenant. James’ UPN in the inviting tenant is created from the invited email and the inviting tenant's original default domain. So, let’s say James’ UPN becomes `James_contoso.com#EXT#@fabrikam.onmicrosoft.com`. For SAML application that issues user.userprincipalname as the NameID, the value passed for James is `[email protected]`.
 +For example, let’s say you invite an external user whose email is `[email protected]` and whose identity exists in an external Azure AD tenant. James’ UPN in the inviting tenant is created from the invited email and the inviting tenant's original default domain. So, let’s say James’ UPN becomes `James_contoso.com#EXT#@fabrikam.onmicrosoft.com`. For the SAML application that issues user.userprincipalname as the NameID, the value passed for James is `[email protected]`.
 All [other external identity types](redemption-experience.md#invitation-redemption-flow) such as SAML/WS-Fed, Google, Email OTP issues the UPN value rather than the email value when you issue user.userprincipalname as a claim. If you want the actual UPN to be issued in the token claim for all B2B users, you can set user.localuserprincipalname as the source attribute instead.