The nightly Google group sync

Each night (every night except Friday into Saturday — the Google runs skip Saturday) Realsmart brings your Google groups back into line with the groups and memberships you manage in this admin. That happens in four steps, and it is worth knowing the shape of it — because one of those steps exists purely to stop a bad night doing damage.

The short version: record → change → record → check.

The four steps

1. Record what Google looks like now (about 1am)

Before changing anything, Realsmart reads your Google groups and writes down who is currently in each one. This is just a record — nothing in Google is touched. It's also when Realsmart checks whether a safety pause from an earlier night can end.

2. Make the changes (about 4am)

Realsmart compares what it expects each group to contain with the record from step 1, and makes only the differences: adding people who should be there, removing people who no longer should.

This is also where the safety net runs — see below. It needs the record from step 1, which is exactly why that step comes first.

3. Record what Google looks like afterwards (about 8:30am)

Realsmart reads your Google groups again. Now the record reflects what the overnight changes actually achieved, rather than what things looked like beforehand.

4. Check the result (about 10:45am)

Realsmart compares its own expectations against the fresh record from step 3. If the two agree, the night worked. If they disagree, that disagreement is reported so it can be looked into.

This step only reads and reports — it never changes anything.

Why two records rather than one

It looks like duplication, but the two records answer different questions and have to be taken at different moments:

• The first record (step 1) is the before picture. The safety net needs it to judge whether the changes about to be made are sensible. Taken after the changes, it would be useless for that.
• The second record (step 3) is the after picture. The check needs it to confirm the changes landed. Taken before the changes, it would report every correct change as a problem.

One record cannot be both a before and an after, so Realsmart takes two.

The safety net, and what it protects you from

Realsmart works out who should be in each group from your data. If that data is badly wrong for a moment — a failed MIS import, a half-finished upload — the honest answer to "who should be in these groups?" can briefly become "nobody". Acting on that would empty every group in the school in a single pass.

The safety net compares how many group memberships your school wants tonight with how many it wanted at the last nightly check. If that has suddenly dropped far more than day-to-day changes would, and Google still has the people who dropped out, the removals are held back and a card appears on your Dashboard (see Realsmart paused some changes to keep your groups safe). Additions and role changes still go ahead. The removals wait until your groups are back to normal, or until someone at your school chooses Let removals go ahead on that card.

You do not need to configure this. It is on by default.

What you might see in the logs

Most nights, nothing about this needs your attention. Two entries are worth recognising if you do see them in sync status and logs:

"MEMBERSHIP REMOVAL HOLD" — the safety net paused a large removal. Additions and role changes still ran, and a card on your Dashboard explains it. This is worth looking at: it usually means something upstream (an import, an MIS feed, a bulk action) went wrong. "MEMBERSHIP REMOVAL HOLD STILL IN PLACE" appears each night the pause continues; "MEMBERSHIP REMOVAL HOLD RELEASED" says it has ended and why — any removals still needed then happen at the next sync. These rows quote a technical command meant for Realsmart staff; ignore it and use the Dashboard card instead.

"MASS-REMOVAL BACKSTOP NOT IN EFFECT" — the before record was missing or too old when the changes ran, so the safety net had nothing to measure against. Your sync ran normally. Only the safety check was unavailable for that school on that night. It shows as Inconclusive, not as an error. If it appears once, it is almost certainly a slow night. If it repeats for the same school, tell Realsmart support.

What this means for you day to day

• This is the whole-school check, not the only route to Google. Changes you make in ADAdmin — adding or removing someone from a group, for example — are queued and normally reach Google within minutes (see How syncing works); the nightly run is the safety net that catches anything missed and removes memberships nothing justifies any more. If you need a whole-school pass now, use trigger a manual sync.
• A membership that disappeared overnight was removed because nothing in Realsmart justified it any more — see Google group settings for what counts as justification, including group-to-group mappings and shared-domain trusts.
• If a whole group looks wrong the morning after, check your Dashboard and the logs before re-importing anything. The safety net may have already held the change back for you.