03.03 · Concept
Account Changes, Merging & Recovery
Handle an email change, a duplicate account and a merge without losing ownership of the objects the old identity created.
Account recovery and linking should preserve a durable internal owner, not treat email addresses or provider identifiers as the owner of data. Email changes, anonymous upgrades and duplicate accounts need explicit proof, conflict rules, auditability and safe retries so documents, projects, settings and other resources remain attached to the right account.
What this lesson answers
- how should user account merging preserve ownership
- why not merge accounts by matching email
- how to handle email change safely
Notes
Account changes are not just profile edits; they are ownership migrations. In a production system, user-created objects should usually belong to a stable internal user id, not directly to an email address, OAuth provider id, or anonymous session id. Email addresses change, providers can be added or removed, and anonymous users may later create real accounts, but the user’s data should continue to point at the same durable owner record.
A good mental model is to separate identity, account, and resources. Identity is how someone proves they are allowed in: email password, Google login, magic…
References
Common questions
- Should user data be owned by an email address?
- No. User-created data should usually reference a stable internal user record. Email addresses, OAuth provider identifiers and anonymous session tokens are login identities, not durable owners. They can change, disappear or be linked later, while the application account should remain the anchor for documents, settings and other resources.
- Is matching email enough to merge duplicate accounts?
- No. Matching email is not sufficient proof that two accounts belong to the same person. Email ownership can change, providers may expose unverified addresses, and aliases can collide. A safe merge requires proof of control for both accounts or a trusted recovery path, plus clear handling for conflicts.
- What makes an account merge safe to retry?
- A safe merge records intent, moves ownership deliberately, and avoids treating a half-finished operation as success. The process should be idempotent enough that a retry does not duplicate objects, overwrite the wrong fields or leave resources orphaned. An audit trail also helps support explain or reverse the change.
Short definition: what is Account Changes, Merging & Recovery?