Onboard a school that already has a Google setup

Onboard a school that already has a Google setup

A school joining from another provider usually already has Google users, groups and Classrooms — live, in daily use, under the previous provider's naming. If our sync ran naively it wouldn't recognise them and would create duplicates beside the real accounts. Cloud reconciliation prevents that: see how their setup lines up with Realsmart first, then converge deliberately.

The golden rule

Keep Google sync OFF or in Preview mode for the school while reconciling. The reconciliation page shows a red warning if the sync is live. Nothing on the reconciliation page changes anything — the audit only reads from Google, and the matching only compares.

Steps

Step 1 — Run a cloud audit {#step-1}

Open Cloud reconciliation (/v2/admin/sync/reconciliation) and select Run cloud audit. This reads the school's existing Google users, groups and Classrooms (read-only) and takes a few minutes.

Step 2 — Read the picture {#step-2}

For each of People, Groups and Classrooms you get four piles:

• Already line up — their cloud address matches what Realsmart would use. The sync will simply adopt these; nothing to do.
• Need a decision — the same person or group exists on both sides under different names (matched by name). You'll choose a direction for these.
• Only in their Google — no Realsmart counterpart (service accounts, extras, or people the MIS import hasn't brought in yet).
• Only in Realsmart — no cloud counterpart; a live sync would create these.

Every item explains what it means in plain language.

Step 3 — Start guided matching {#step-3}

Select Start guided matching. The wizard walks through five steps, and nothing changes until you confirm at the end:

1. In their cloud — what the audit found (people, groups, classrooms), read-only.
2. In Realsmart — what the MIS import manages, and what a live sync would create.
3. Line them up — the heart of it. Naming mismatches are usually systematic, not random: their groups might all carry a house- prefix, or use double dashes (year--7 vs year-7), or differ only in capitalisation. The wizard detects these patterns and proposes each as a rule — confirm one rule and it resolves all of its pairs at once, instead of matching hundreds of items by hand. You can untick any single pair, resolve ambiguous items yourself (the wizard never guesses), and match leftovers manually with a search.

4. People decisions — for people who exist on both sides under different sign-ins, pick a direction: adopt their sign-ins into Realsmart (Direction A — nothing changes in Google), or rename their cloud accounts to Realsmart naming (Direction B — a real change, typed-confirmation, run through the same safe machinery as renaming a user). Or leave it for later. 5. Preview & apply — the exact ledger of what will be adopted, linked and converged, and what a live sync would still (correctly) create. Applying makes local associations only — their existing groups, classrooms and account IDs become the ones the sync manages — with every pair re-checked server-side at that moment. No duplicates by surprise.

Matching can only be applied while the sync is off or in preview — converge first, then go live. Entra estates are shown for visibility; converging usernames lines Entra up too, since sign-in names drive UPNs.

Step 4 — Preview, then go live {#step-4}

Once converged, put the sync in Preview mode, run a preview, and check the plan is calm (no unexpected creates). Then flip to live.

Troubleshooting

• "Lots of people are in 'Only in their Google'" — usually the MIS import hasn't run for this school yet, so Realsmart is missing them. Import first, then re-run the audit.
• "The same person shows in both 'Only in' piles" — their cloud name and MIS name differ too much to match automatically. Handle them with Merge users or the rename wizard.