Merge duplicate user accounts

Merge duplicate user accounts

Use Merge users to combine two accounts that belong to the same person. This works in two contexts, using exactly the same tool:

• Within a single school — two duplicate records for the same pupil or staff member in the school you're working in.
• Across schools in a trust — the same person with accounts at two different schools (multi-academy trusts, in MAT mode).

The merge keeps one account (the primary) and removes the other(s) (the secondary or secondaries) — their data is combined onto the primary and their old username is freed up so it doesn't sit blocking a future new starter. The secondary's cloud platform accounts (Google Workspace, Microsoft Entra) are handled as part of the process.

This action cannot be relied on to permanently keep someone out of the removed school. The merge itself is immediate and its database change is deliberately hard to reverse (see Undoing a merge below). But if the person you merged away is still genuinely enrolled or employed at that other school, the next scheduled data import from the school's MIS (SIMS, Wonde, etc.) will create a fresh, active account for them there again — see If this person is still at the other school below. Only merge someone out of a school they have actually left.

Before you start

• You must be a school admin (mentors and other staff cannot merge users).
• The tool is scoped to your context: in a single school you can only merge accounts within that school; in MAT mode you can merge across the schools you're authorised for.
• Confirm the two accounts you want to merge before you start.

Steps

Step 1 — Open Merge users {#step-1}

In the left sidebar, under Users & Groups, select Merge users. (In MAT mode, it also appears in the MAT sidebar alongside Find a user and Merge history.)

Step 2 — Search for the users {#step-2}

Type a name, username, or school ID into the search box. In a single school the results are that school's users; in MAT mode results appear from all schools you're authorised for.

For each result you can see: name, username, school, and status (Active / Suspended).

Step 3 — Select primary and secondary {#step-3}

For each user in the results:

• Primary (radio button) — the account to keep. Choose the most complete or most recently active account.
• Secondary (checkbox) — the account(s) to remove. You can select more than one secondary.

A single user cannot be both primary and secondary.

Select Next: compare fields when you have made your selections.

Step 4 — Choose which field values to keep {#step-4}

The Compare step shows a side-by-side table of both accounts' field values:

For each field, select the radio button next to the value you want the merged user to have. The primary's values are selected by default.

Passwords are always kept from the primary and are never shown.

Select Next: review sync impact when done.

Step 5 — Handle the email change (if shown) {#step-5}

If your field choices will change the primary user's email address (e.g. you chose a username from the secondary account), you'll see a warning:

"This merge will change the primary user's email address."

For each connected platform (Google Workspace, Microsoft Entra), choose:

• Rename the old account now — ADAdmin updates the cloud account immediately (optionally keeping the old address as an alias)
• Leave it — let the next sync handle it — the change is applied at the next scheduled sync

Select Next: secondary sync options when ready.

Step 6 — Choose what to do with secondary cloud accounts {#step-6}

The Sync options step lets you decide what to do with each secondary user's cloud accounts:

"Do nothing" is not permanent. Whichever option you pick, once the merge completes the secondary is marked removed, and the next regular sync for that school will suspend its cloud account anyway if nothing has already suspended it. Choosing Suspend or Rename & suspend here just does it immediately instead of waiting for the next sync.

A merged-away account is never marked "protected". If either the primary or a secondary account was protected before the merge, the kept (primary) account stays protected — protection is never lost — but it is never applied to the accounts being removed. There's no option to protect a secondary; see If this person is still at the other school for why that wouldn't help anyway.

If any data issues are detected (e.g. missing IDs), a warning panel appears. Tick "I have reviewed these issues…" to acknowledge before proceeding. If the primary and a secondary are at different schools that don't share a Google sign-in domain, this panel also warns that the removed school's groups, Classroom and calendar access will be lost — see Merging someone who works at more than one school if that's not what you want.

Select Continue to preview.

Step 7 — Review the full preview and confirm {#step-7}

Before anything irreversible happens, the Preview step shows everything the merge will do:

• Identity / email — whether the kept account's sign-in address changes and exactly what it becomes. If it changes, a brand-new cloud account is created at the new address on the next sync — existing Drive files, Classroom content and email stay on the old account (handled per your email-change choice). If the schools share a sign-in domain, the preview says so and no account rename happens.
• Groups & Classroom memberships — how many memberships move to the kept account (duplicates are skipped automatically).
• Classroom ownership — any classes the removed account owns transfer to the kept account, so no classroom is left without a working owner.
• Guardians — parent contacts move to the kept account (duplicates skipped).
• History — the removed account's activity log is re-attributed to the kept account, so the full history survives.
• Protection and role — if either account was protected, the merged account stays protected; if the accounts had different roles, the preview flags what the merged role will be and what that affects.
• Kept vs discarded — a plain statement of what is removed.

Select Confirm & merge and confirm the dialog.

Step 8 — Review cloud action results {#step-8}

The Cloud review step runs the cloud actions first (before touching the database). You'll see a table of results:

• Succeeded — the cloud action completed
• Failed — something went wrong (see the detail column for the error)

If any actions failed, you can:

• Retry failed actions — try again
• Proceed anyway — skip the cloud step and apply the database changes

The database is not modified until this step completes (or you choose to proceed anyway).

Step 9 — Confirm the result {#step-9}

The Result step confirms whether the merge succeeded. If successful, the secondary users are deleted and the primary account holds the merged data.

Select Back to search to merge more users, or Merge audit log to review what was changed.

If this person is still at the other school {#still-there}

Merging always frees up the secondary's username so it doesn't sit there blocking a genuine new starter. That part is permanent, and it's the point of merging — it's how ADAdmin keeps school data tidy when the same real person had two records by mistake.

But ADAdmin isn't the only thing that decides who's active at a school — the school's own MIS (SIMS, Wonde, etc.) is, and it's checked again on every scheduled sync. If the person you merged away is still genuinely enrolled or employed at the other school, its next import will simply create a fresh, active account for them there again — a new record, freshly set up in Google Workspace or Microsoft Entra, exactly as if they were a new starter. This happens automatically and isn't something suspending, renaming, or any other choice on the merge screen can prevent, because the MIS import doesn't know (or care) that a merge happened — it only knows what the school currently reports.

What this means in practice:

• Merging is durable for someone who has actually left the other school — nothing will bring them back.
• Merging is not durable for someone who is still genuinely there — they will reappear on the next import, with a brand-new account, regardless of what you chose on the sync options step.
• If you're not sure whether someone has left, check with the school before merging rather than relying on the merge to remove them.

Merging someone who works at more than one school {#multiple-schools}

Merging is for combining two records that are the same account by mistake — not for someone who genuinely has a legitimate, ongoing role at more than one school (for example, a teacher who works at two schools in your trust). If that's the situation, don't merge them.

Here's why merging doesn't work for this: the tool can only keep one live account, at the primary's school. The moment you merge, the other school's copy of that person is removed, and their groups, Google Classroom, and calendar access at that school are removed with it. Adding the old email address as an alias afterwards does not bring any of that back — group and Classroom membership is driven by which school has an active record for that person, not by what email aliases exist. If the two schools happen to share the same Google sign-in domain, this isn't an issue (they're really one shared account and the tool tells you so); if they don't share a domain, you'll see a warning about this on the sync options step, and it's telling you exactly that.

What to do instead: keep a separate, active account for this person at each school where they genuinely work. That's the normal, supported way to represent one person with a legitimate role at multiple schools — each school's own sync keeps their groups and Classroom access there up to date independently. If you're not sure how to set that up, contact support.

Undoing a merge {#undoing-a-merge}

Merges can be reviewed and undone from Merge history in the sidebar (the same page as "Merge audit log" above — one page, two names depending on where you land on it).

The undo wizard reverses the database changes and can attempt to recreate cloud accounts — but cloud undos are best-effort. If the cloud actions involved deleting or suspending Google or Entra accounts, those actions may not be fully reversible.

See Merge history and undo for the full step-by-step undo flow, including how to choose which cloud actions to reverse and what to do if a reversal fails.

Troubleshooting

• "I can't find Merge users in the sidebar" — it's under Users & Groups (alongside Users and Groups). You must be signed in as an admin; mentors and other staff don't see it.
• "I picked the wrong primary" — select Back to selection in the top-right to start again. No changes are made until the final Execute step.
• "Cloud action failed with an API error" — try Retry failed actions. If it keeps failing, use Proceed anyway to apply the database changes and fix the cloud account manually.
• "The secondary user had an important email address I need to keep" — tick "keep old address as a Google alias" for that secondary in the sync options step. This keeps the address reachable on that secondary's own account, which stays suspended — it does not move the address onto the kept (primary) account, and it will not restore that person's groups or Classroom access at the removed school. If you need the primary account itself to receive mail at the old address, add that as an alias manually in the Google Admin console afterwards.
• "The merged-away user reappeared after a few days" — see If this person is still at the other school: this happens when the person is still genuinely in that school's MIS data, and it's expected, not a bug.
• "This person genuinely works at more than one school — should I merge them?" — no, see Merging someone who works at more than one school.

Related

• Merge history and undo
• Find a user across schools
• Understanding MAT mode
• Switch school context