Why not use the email address as the user id?

An email address is a contact method and often a login identifier, but it is not a durable owner. People change addresses, providers may return unverified emails, aliases behave differently across systems, and addresses can be reassigned. Use an internal stable user id for ownership, then attach emails and providers as replaceable identities.

When is it safe to merge two accounts?

It depends on how strongly you can prove the same person controls both accounts. A safe merge usually requires authentication into both accounts, or a trusted recovery process with support review. Matching email strings alone is not enough. The merge also needs predefined conflict handling, resource transfer rules and an audit trail.

What should happen during an email change?

Treat it as a sensitive account operation, not a profile edit. Require recent authentication, collect the new address, verify it, then update the account’s primary contact while keeping resource ownership unchanged. The user’s documents, settings and other objects should still point to the same internal account id before and after the change.

How do anonymous accounts fit into this?

An anonymous account should still have a real internal account id and own resources through that id. When the user later registers or adds a provider, link the new identity to the existing account instead of creating a separate owner. If a duplicate already exists, merge deliberately rather than overwriting ownership.

Account Changes, Merging & Recovery

Account changes, merging and recovery are the lifecycle operations that keep a user’s durable application account and owned data intact while login methods, emails, providers or duplicate accounts change. They treat identity as mutable evidence of access, not as the permanent owner of documents, projects, settings or other resources.

The hard part is that users do not stay neatly attached to one login forever. They change email addresses, lose provider access, start anonymously, sign in later with a different method, or accidentally create duplicate accounts. If resources are owned by an email address or provider subject, those changes can orphan data or expose it to the wrong person. The system needs a stable account record that survives identity churn.

A robust design separates identity, account and resources. Identity is the proof used to authenticate, such as a password, OAuth login, magic link or anonymous token. The account is the internal user record, identified by a stable id. Resources point to that account id. Linking adds another identity to the same account. Merging moves or reconciles resources from one account record to another under explicit rules.

The main trade-off is extra ceremony around changes that look simple in the user interface. Email changes should usually require re-authentication and verification of the new address before it becomes primary. Merges should not rely on matching emails alone, because emails can be unverified, reassigned, aliased or attacker-controlled. You also need conflict rules, audit logs and retry-safe operations, which make the implementation more complex.

Engineers meet this in sign-up, account settings, support tooling, recovery flows and authentication provider integrations. Typical cases include converting an anonymous user into a registered one, connecting a Google login to an existing password account, detecting duplicate accounts, or helping support merge records. The important implementation detail is that ownership changes are deliberate data migrations, not incidental profile updates.

Go deeper

User SystemsAccount Changes, Merging & RecoveryHandle an email change, a duplicate account and a merge without losing ownership of the objects the old identity created.Open the lesson

Common questions

Why not use the email address as the user id?: An email address is a contact method and often a login identifier, but it is not a durable owner. People change addresses, providers may return unverified emails, aliases behave differently across systems, and addresses can be reassigned. Use an internal stable user id for ownership, then attach emails and providers as replaceable identities.
When is it safe to merge two accounts?: It depends on how strongly you can prove the same person controls both accounts. A safe merge usually requires authentication into both accounts, or a trusted recovery process with support review. Matching email strings alone is not enough. The merge also needs predefined conflict handling, resource transfer rules and an audit trail.
What should happen during an email change?: Treat it as a sensitive account operation, not a profile edit. Require recent authentication, collect the new address, verify it, then update the account’s primary contact while keeping resource ownership unchanged. The user’s documents, settings and other objects should still point to the same internal account id before and after the change.
How do anonymous accounts fit into this?: An anonymous account should still have a real internal account id and own resources through that id. When the user later registers or adds a provider, link the new identity to the existing account instead of creating a separate owner. If a duplicate already exists, merge deliberately rather than overwriting ownership.

Every term