AddThisFeature

Account Merge

Collapse two duplicate accounts into one without losing work.

involved User Accounts

What it adds

A controlled flow that merges a source account into a target account, resolving conflicts across ownership, billing, and content.

What your agent is told to do

7
  1. 1

    Require proof of control over both accounts in the same flow — a verified challenge to each, not just being signed into one.

  2. 2

    Show the user a merge plan before anything moves: what will be kept, what will be reassigned, what will be discarded, and what cannot be undone.

  3. 3

    Resolve each conflict class explicitly — workspace memberships, subscriptions, usernames, handles, preferences, API keys. Pick a rule per class and state it in the UI rather than guessing.

  4. 4

    Reassign owned records to the target account rather than copying them, so history, timestamps, and references stay intact.

  5. 5

    Run the merge as a resumable job with a recorded plan, so a partial failure can be retried or reversed instead of leaving two half-accounts.

  6. 6

    Do NOT delete the source account until the merge has been verified. Deactivate it, keep the mapping, and reap it later.

  7. 7

    Adding an extra sign-in method to one account is owned by Account Linking; send users there when they do not actually have two accounts.

Edge cases it handles

6
  • Both accounts holding paid subscriptions must be handled deliberately — cancel one with credit, or refuse and require billing to be sorted first. Never leave the user paying twice.
  • Both accounts being members of the same workspace must collapse to a single membership at the higher role, not two rows.
  • Where both accounts own a unique value such as a username, decide which survives and free the other rather than erroring mid-merge.
  • Third-party integrations authorised by the source account must be re-authorised or explicitly migrated; tokens scoped to a dead account fail silently later.
  • Anything that references the source account by ID — links, mentions, webhooks, exported data — needs a redirect from old ID to new for a defined period.
  • A merge must be blocked when either account is suspended or mid-deletion, and it must be single-flight so two merges cannot run against the same pair.

Definition of done

8
  • Control of both accounts is proven before the merge begins.
  • A plan showing kept, moved, and discarded data is confirmed by the user first.
  • Owned records are reassigned, not duplicated, and their history survives.
  • Duplicate memberships and unique-value conflicts resolve to a single defined outcome.
  • A partial failure can be retried or rolled back from the recorded plan.
  • The source account resolves to the target for a defined period after the merge.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.