Dynamics 365 Tech Blogs: Power Pages Identity and Account Change Design

A Power Pages solution can use Microsoft Entra External ID to authenticate portal users. Microsoft Power Pages then associates the authenticated identity with a Dataverse Contact record. This article explains how those identities are connected, how email changes should work, and what is required to support Google, Facebook, BC Services Card, or another third-party identity provider.

1. Purpose and Scope

This design covers the following scenarios:

Changing only the portal user's communication email.
Changing an Entra External ID email/password sign-in email.
Using a username or alias instead of an email to sign in.
Changing to another Google account.
Switching from Google to Facebook or another identity provider.
Future BC Services Card account linking.
Contact association, logout, security, monitoring, and recovery.

2. Important Identity Terms

The following values are related, but they are not the same value and do not always need to contain the same email address.

Value	Purpose	Owner
Contact email	Business communication and portal user profile data	Dataverse
Entra sign-in email	Credential identifier for an email/password account	Entra External ID
Entra username or alias	Alternative sign-in identifier, such as a client number	Entra External ID
Federated provider identity	Google, Facebook, BC Services Card, or another provider account	External identity provider
Entra Object ID	Stable identifier of the Entra user object	Entra External ID
Power Pages external identity	Associates the authenticated identity with a Contact	Power Pages and Dataverse

3. Identity Association Model

Google / Facebook / BC Services Card
        |
        | provider issuer + provider user ID
        v
Entra External ID user
        |
        | Entra Object ID or sub claim
        v
Power Pages external identity
        |
        v
Dataverse Contact

When the user signs in for the first time, Power Pages can use the email claim to find one existing Contact if Contact mapping with email is enabled. After the association is created, Power Pages stores the identity provider's stable sub or Object ID value as the external identity username. Later sign-ins use this established identity association instead of repeating the Contact search by email.

Microsoft explains that Power Pages uses the sub claim, or the Object ID claim for Microsoft Entra providers, because it uniquely identifies the user. Microsoft also explains that the configured email claim can be used to search the Contact's Primary Email Address during Contact mapping. Power Pages OpenID Connect FAQ

4. Initial Email Matching Versus Permanent Association

Email can have two different roles:

Initial matching: Power Pages may use the token email claim to find a unique existing Contact.
Profile synchronization: Login claims mapping may write the token's email value into the Contact's Primary Email field.

Email is not normally the permanent association key after the external identity has been linked to the Contact. However, email is still present in the login token and may still affect the Contact through claims mapping.

Power Pages requires an email, emails, or upn claim for OpenID Connect sign-in. The claims are processed in priority order to set the Contact's Primary Email. Therefore, the team must not assume that the Contact email will remain independent from the sign-in email unless the provider and claims mapping have been tested and configured for that business rule. Power Pages OpenID Connect FAQ

5. Email A, B, and C Example

Assume the following initial state:

Entra user E456, sign-in email A
        |
        | initial email match
        v
Contact C789, email A

The portal user later changes only the Contact email:

Entra user E456, sign-in email A
        |
        | existing identity association
        v
Contact C789, email B

The portal user then changes the Entra sign-in email to C:

Entra user E456, sign-in email C
        |
        | same E456 to C789 association
        v
Contact C789, email B

This association is valid because the stable relationship is E456 -> C789. Email A is no longer needed to find the Contact after the initial association. Changing the Contact email to B and the sign-in email to C does not by itself break the association.

There is one important limitation: on the next sign-in, the token may contain email C, and Power Pages claims mapping may update the Contact's Primary Email from B to C. Therefore, the statement "the Contact will remain email B" is not guaranteed.

The SDD must choose one of these rules:

Synchronized emails: The sign-in email and Contact Primary Email must be the same. After changing the Entra sign-in email to C, update the Contact email to C as part of the same workflow.
Independent emails: The sign-in email may be C while the business communication email remains B. Claims mapping must not overwrite the business email. A separate Contact field may be safer for the business communication email.

6. Can Power Pages Match a Contact Using Another Field?

Entra External ID can allow a user to sign in with a username or alias, such as a customer ID or account number. This changes what the user enters on the Entra sign-in page. Entra External ID alias and username sign-in

It does not change Power Pages' built-in Contact-mapping rule. The standard automatic mapping searches the Contact's Primary Email. Power Pages does not provide a built-in configuration for matching an arbitrary Contact column such as Client Number, Application Number, or a custom external identifier.

If email matching is not suitable, use one of these approaches:

Invitation-based association: Create an invitation for the existing Contact and let the portal user redeem the unique invitation code. Power Pages Contact invitations
Custom account-claiming process: Ask for a client number and additional proof, then perform the association through an approved server-side process.
Staff-assisted association: Send uncertain or conflicting matches to an authorized support or identity-administration team for review.

A client number alone must not be accepted as proof that the person owns a Contact. It should be combined with an invitation code, verified email, approved identity proof, or staff review.

7. Reference Power Pages Architecture

Power Pages Identity Management UI
        |
        v
Power Pages Web API
        |
        v
Dataverse Identity Change Request
        |
        v
Server-side processor --------------> Email service
        |
        +----------------------------> Microsoft Graph
        |                                      |
        |                                      v
        |                              Entra External ID
        v
Dataverse Contact / related business records
        |
        v
Operations monitoring and recovery view

A common Dataverse-centric design uses Power Pages, a Dataverse request table, and Dataverse plug-ins. Power Pages JavaScript remains UI-only and never receives Microsoft Graph credentials. An organization may instead use an Azure Function or another secured backend service when its integration architecture, network controls, API gateway, and operational model support that option.

Power Pages Web API supports create, read, update, and delete operations on Dataverse data tables. It does not provide a general browser endpoint for privileged Microsoft Graph operations. The portal should create or update the request record and allow server-side processing to handle the identity change. Power Pages Web API overview

8. Required Components

Component	Responsibility
Power Pages UI	Collects the new email, verification code, and request status.
Power Pages Web API	Creates and updates the portal user's own request record.
Identity Change Request table	Stores workflow state, audit data, retry state, and errors.
Server-side processor	Dataverse plug-in or approved backend service that validates requests, verifies codes, calls Graph, and updates Dataverse.
Email service	Sends verification codes and security notifications.
Authentication redirect/callback	Proves ownership of a new Google, Facebook, or other provider account.
Graph app registration and service principal	Provides approved application permission to update Entra identities.
Operations monitoring view	Supports investigation, manual review, and controlled retries.

A Dataverse application user is normally not required when a plug-in calls Microsoft Graph. The plug-in already executes inside Dataverse. A Dataverse application user is required when an external service, such as an Azure Function, connects back to Dataverse using server-to-server authentication.

9. Supported Business Scenarios

Scenario	Required Action
Change communication email only	Verify the new email and update the Contact. The sign-in identity remains unchanged.
Change Entra email/password sign-in email	Verify the new email, update the same Entra user through Graph, apply the selected Contact-email rule, and sign the user out.
Use a username or alias	Configure the Entra sign-in identifier policy. Keep an email claim available for Power Pages.
Change to another Google account	Authenticate the new Google account and perform a controlled account-linking or migration process.
Switch Google to Facebook	Authenticate and link Facebook before removing Google. This requires a proof of concept for the selected Entra configuration.
Add BC Services Card	Use the approved BC Services Card authentication integration and link its stable identifier. The Power Pages organization cannot change the BC credential.

10. Communication Email Change Only

The authenticated portal user selects Change contact email.
The portal user enters the new communication email.
The system creates an Email Change Request.
A verification code or link is sent to the new email.
The portal user verifies ownership of the new email.
The Contact email is updated.
The Entra sign-in identity is not changed.

If the Contact email must remain different from the sign-in email, the claims mapping configuration must be tested to ensure the next login does not overwrite the Contact value.

11. Entra Sign-In Email Change

Microsoft Entra External ID does not provide a complete Power Pages self-service flow for changing a portal user's sign-in email. The solution must implement a custom, verified process if this feature is required.

The authenticated portal user selects Change sign-in email.
The solution requires recent authentication or another approved security check.
The portal user enters the new email.
Power Pages creates an Identity Change Request.
The backend obtains the Entra user by immutable Object ID, not by old email.
The backend checks whether the new sign-in identity is already in use.
A verification code or link is sent to the new email.
The portal user submits the verification code.
A plug-in validates the code, expiry time, attempt count, and request owner.
An asynchronous plug-in retrieves the complete Entra identities[] collection.
The plug-in replaces the correct emailAddress identity and preserves every other identity.
The plug-in updates the user through Microsoft Graph.
After Graph succeeds, the solution applies the selected Contact-email synchronization rule.
The request becomes Completed.
The current Power Pages session is ended and the portal user signs in again using the new email.

Microsoft Graph requires User.ManageIdentities.All to update the identities property. Updating this property replaces the complete collection, so the implementation must first read and preserve identities that are not being changed. Microsoft Graph update user API

The Graph authentication setup is:

Create or consent an app registration in the Entra External ID tenant.
Create the related service principal.
Grant the required Microsoft Graph application permission.
Grant administrator consent.
Use an approved certificate or secret-storage approach.
Request a Graph token using the client-credentials flow.
Call PATCH /v1.0/users/{entraObjectId}.

12. Third-Party Identity Providers

Google, Facebook, BC Services Card, and other external providers own their own credentials. A Power Pages solution cannot change a Google password, change a Facebook credential, or modify a BC Services Card. It can only control which verified identity is accepted and how that identity is associated with the portal user.

Microsoft Graph represents an external identity with values such as signInType, issuer, and issuerAssignedId. The combination of issuer and issuer-assigned identifier is the provider-side identity key. It is not the provider's display email. Microsoft Graph objectIdentity resource

12.1 Provider Email Changes but the Provider Account Is the Same

Google subject G123, old email
        |
        v
Entra user E456
        |
        v
Contact C789

If Google changes the email but keeps the same provider identifier G123, and Entra keeps the same user E456, the Contact association normally continues to work. The Contact's communication email may need a separate update, depending on the solution's business rule and claims mapping.

12.2 Changing to a Different Google Account

A different Google account has a different provider identifier. This is not an email change. It is an account-linking or identity-migration operation.

The portal user signs in with the currently linked identity.
The portal user selects Add or change sign-in method.
The solution redirects the browser to the configured provider and forces account selection.
The portal user authenticates the new Google account.
A secure callback validates the token, issuer, subject, state, and nonce.
The backend confirms that the new provider identity is not linked to another portal user.
The request is recorded in Dataverse.
The verified new identity is linked to the existing Entra user, if the approved Entra design supports this operation.
The portal user tests the new sign-in method.
The old identity is removed only after the new sign-in succeeds.

12.3 Switching from Google to Facebook

Google identity -----+
                     +---- Existing Entra user ---- Existing Contact
Facebook identity ---+

The intended design is to link Facebook to the existing Entra user, test the Facebook sign-in, and then optionally remove Google. The user must not simply select Facebook on the normal registration page before linking it, because the user flow may create a second Entra user.

Entra External ID supports Google, Facebook, Apple, Microsoft Entra ID, and custom OIDC identity providers. However, Microsoft does not document a complete built-in external-tenant user flow for an authenticated customer to merge or replace social accounts on the same user object. The implementation team must complete a proof of concept before committing to Google-to-Google or Google-to-Facebook switching. Entra External ID identity providers

The custom Dataverse table and plug-in are not enough by themselves. They can manage workflow state and call Graph, but they cannot prove that the portal user owns the new Google or Facebook account. A secure provider authentication redirect and callback, or a Microsoft-supported account-linking feature, is also required.

12.4 BC Services Card

BC Services Card authenticates the person and returns an approved identifier and identity attributes to the service provider. The Power Pages organization may associate that verified identifier with the portal user, but it cannot modify the BC Services Card credential itself. BC Services Card system interfaces

13. Request Table and Workflow Status

For an email-only MVP, the table can be named Email Change Request. If provider switching is included, use the more general name Identity Change Request.

Recommended fields:

Contact
Request type
Entra Object ID
Current and new email
Current and new provider
Issuer and provider identifier
Verification-code hash
Expiry time and attempt count
Correlation ID
Status
Error code and error details
Created, verified, and completed dates

Recommended email-change status flow:

Requested
  -> Verification Sent
  -> Verified
  -> Entra Updated
  -> Contact Updated or Contact Update Not Required
  -> Completed

Other outcomes should include Expired, Cancelled, Failed, and Manual Review Required.

14. Logout and Session Handling

The portal user should be signed out only after the request reaches Completed. Accepting the verification code may only move the request to Verified if the Graph operation runs asynchronously. In that case, the front end should check the request status until processing completes.

if (request.status === "Completed") {
  window.location.replace(
    "/Account/Login/LogOff?returnUrl=%2Fidentity-change-complete"
  );
}

The logout endpoint performs the logout automatically. It normally does not ask the portal user to confirm. The solution may show a message before the redirect, but it should not offer a Cancel option after the sign-in identity has already changed.

With external logout configured, Power Pages can also start logout at the OpenID Connect provider. The logout endpoint handles the current browser session. If the solution must terminate sessions on all browsers and devices, the backend can call Microsoft Graph revokeSignInSessions, subject to approved permissions and the platform's revocation delay. Microsoft Graph revoke sign-in sessions

15. Security and Recovery Requirements

Require recent authentication for sensitive identity changes.
Verify every new email or provider account before changing the identity.
Store only a hash of the verification code.
Use short expiry periods and limit verification attempts.
Apply rate limits to request creation and code submission.
Do not use email equality as sufficient proof of account ownership.
Prevent a provider identity from being linked to more than one portal user.
Use the Entra Object ID, not the current email, to find the account being changed.
Preserve all unrelated entries when updating identities[].
Keep the old provider identity until the new sign-in method has been tested.
Record a correlation ID and enough error information for support.
Provide controlled retry and manual-review procedures.

Microsoft Graph and Dataverse do not share one database transaction. If Graph succeeds but the Contact update fails, the request should remain at Entra Updated and retry only the Dataverse step. If Graph fails, the Contact should not be updated as though the sign-in change succeeded.

16. Recommended MVP Scope

For MVP, support a sign-in email change only if it is a confirmed business requirement. The SDD must explicitly state whether the Contact email and sign-in email are synchronized or independent.

Google-to-Google, Google-to-Facebook, and BC Services Card account linking should remain future capabilities unless the implementation team completes the required Entra proof of concept, authentication callback design, security review, duplicate handling, recovery process, and provider-specific testing.

17. Key SDD Decisions Still Required

Can portal users change only the communication email, or also the Entra sign-in email?
Must the Contact email always match the Entra sign-in email?
If the emails can differ, which Contact field stores the communication email?
Will login claims mapping update the Contact Primary Email on every sign-in?
Is email matching enabled only for initial Contact association?
Will invitations be used when an existing Contact must be claimed without email matching?
Is provider account switching in MVP or a future phase?
Which approved component will implement the provider authentication callback?
Are all-device session revocation and security notification to the old email required?
Who monitors failed requests and performs manual recovery?

Power Pages Identity and Account Change Design