Merge duplicate user accounts

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.)

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).

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.

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 a choice too, but the values are never shown. Instead of the password itself, each account's Password cell says one of:

The primary's password is selected by default, so leaving this row alone keeps things exactly as they are today. If you choose a secondary's password instead, the merged user signs in with that password from the moment the merge completes — their previous one stops working.

Where it goes next is the same as for any other password change, and depends on what each platform is set to do:

If a platform doesn't sync passwords, the person keeps whatever password they already had there — merging doesn't change it.

Choose the secondary's password when the duplicate is the account the person actually uses and knows the password for — merging onto a primary they've never signed into would otherwise lock them out until you reset it.

One limitation, and only for a small number of schools whose default password was set up before ADAdmin stored a re-readable copy of it: where the chosen password is one of those defaults, only its one-way hash exists. The merged user still signs in with it in the app, and Google Workspace still receives it (Google is sent the stored hash, not the plaintext). Microsoft Entra and on-premise Active Directory both need the plaintext, so for those two the password stays as it was until the school re-saves its default under School settings → Password. The notifications bell asks for that re-save when it applies to you.

Choose the Wonde ID carefully. The Wonde ID is how the nightly MIS import finds this person. Whichever record still exists in your MIS is the Wonde ID to keep — if the merged user keeps the wrong one (or none at all), the import stops updating them, or creates them again as a brand-new account. Duplicate accounts are very often exactly this: the same person under two Wonde IDs, only one of which the MIS still sends.

If the records hold different Wonde IDs, or the choice would leave the merged user without one, a warning appears on the next step and again on the preview, and you must acknowledge it before merging. Once the merge runs, only the kept account holds that Wonde ID — it is removed from the record being deleted, so the import can never match the deleted twin and bring it back.

Select Next: review sync impact when done.

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.

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.

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.
• Password — whether the kept account keeps its own password or takes the one you chose from a removed account, and who that password came from.
• MIS link (Wonde ID) — which Wonde ID the merged user keeps, which record it came from, and any Wonde IDs being dropped. If the merged user would keep none, the preview says so in plain terms.
• 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.

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).

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.