Understanding and actioning sync errors

The Sync status page and the Logs page both group identical failures into one issue — "48× Add to classroom — permission denied" — so you triage causes, not individual rows. Both surfaces read the same grouping, so they never disagree: fix or ignore a cause on either page and it clears from both, and from the notification bell. Each group carries an urgency badge and an action strip.

The four badges

Badge	Meaning	What to do
You can fix this	Bad or missing data you can correct (a user with no email, a class with no owner)	Use the Fix button — it takes you to the existing screen that repairs that cause (e.g. the orphaned-classrooms review, or the affected user's record)
Will retry	Transient provider hiccups (rate limits, timeouts, 5xx)	Usually nothing — the engine retries on its next pass. Retry outstanding re-queues them immediately
Needs escalation	Provider-side permission or quota configuration (e.g. Google admin scopes)	Not fixable from here — this guide and your Google/Microsoft admin. No fake fix button is offered
Known issue	A recognised, recurring pattern with its own dedicated review flow (e.g. an orphaned classroom, a frozen provisioning window)	Use Fix to open that dedicated flow. These are calm by design — they don't count towards the bell's "N issues" total, since they already have their own notification or are a known, expected state

Fix

Fix never does anything new — it routes you to the remediation that already exists for that cause: orphaned/ownerless classrooms go to the orphaned-classroom review, a frozen provisioning window goes to End of year, and single-user data problems open that user's record. After fixing, use Retry outstanding to prove the fix without waiting for the nightly run.

Retry

Retry outstanding re-queues the group's still-failing users/groups through the normal sync engine — the same queue every other change uses. It's safe and idempotent: the engine reconciles current state, so retrying something already fixed does nothing. Attributed in the logs.

Ignore (declutter without deleting)

Ignoring never deletes anything — it's a reversible state that hides a group from the active triage view while keeping the full history:

Ignore these current errors — clears this batch; new instances still surface.
Ignore this type going forward — "I know about this, stop showing it" — future instances are hidden too, until you un-ignore.

Ignored groups are counted ("N ignored groups hidden") and viewable via the Ignored errors → Show ignored filter, where an Un-ignore button restores them. Every ignore/un-ignore is attributed in the logs and audit trail.

"Failed 47 times, last seen today"

A problem that can't be fixed on its own — a class that can't be created because it has no mentor, an account the provider keeps rejecting — used to fail identically every run, filling the logs with the same message hundreds of times. Now each such recurring failure is recorded once per affected user and problem, with a running count and a last seen time, so a group reads "Failed 47 times · Last seen 2 hours ago".

That's more useful than a wall of duplicates: the count tells you how persistent it is, and a recent last-seen tells you it's still happening — exactly what to act on. If you fix the cause, the count simply stops climbing and the last-seen goes stale (and a later successful sync marks the group resolved). A different error for the same user is still its own separate group — nothing is hidden or merged that shouldn't be.

Everything that filters by date — the "last N days" window, the sort order, the warning dot on the school switcher, the dashboard error counts — goes by last seen, not by when the problem first appeared. That matters most for the errors you most want to know about: a failure repeating every night keeps one row whose original date recedes into the past, so going by that date would have made the most persistent problems the first to disappear from view.

"Held" — a mass change the sync refused to make

Occasionally a group will say the sync held something rather than failing it: a removal of group memberships, or a batch of account suspensions, that it declined to carry out.

This is a safety net, not a bug. If a MIS feed arrives empty or half-imported, the correct-looking conclusion is "every pupil has left every group" — and acting on it would strip the school's groups in a single pass. So when a run's removals look like that rather than ordinary churn, the removals are skipped, the additions still go ahead, and the hold is logged with the numbers it saw.

What to do: check that school's MIS import first — see Wonde data. If the roll really has changed that much (a genuine mass leaver processing, say), the hold clears by itself on the next run once the numbers stop resembling a failed import, and the removals are then applied normally. If you believe a hold is wrong and it's blocking something time-critical, escalate rather than working around it.

"Inconclusive" — a check that couldn't reach a verdict

Inconclusive is not a failure. It means an automated check ran but didn't have what it needed to judge — usually a comparison with nothing valid to compare against yet. Nothing is broken, and nothing was changed.

It's reported separately from errors deliberately. A check that reports "all fine" when it actually learned nothing is worse than one that admits it, so these are surfaced honestly rather than rounded up into a green tick or down into a red error. No action is needed from you; if a check stays inconclusive for days, raise it.

From the dashboard

The errors-over-time bars on the Dashboard and Sync pages are clickable — a click opens the Logs page pre-filtered to exactly that day's errors, with a dismissible date chip.

Result

Errors stop being a wall of red: each group tells you whether to act, wait, or escalate — and gives you the one-click way to do it.