Understanding and actioning sync errors

The Sync status page and the Logs page both group identical failures into one cause — "Add to classroom ×48 — 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, a still failing count and an action strip.

One cause is one issue. The headline counts on every page ("3 things to look at", the bell's "Sync completed with 3 issues to look at") count causes, not rows: a cause that failed 1,000 times is one thing to look at. The row's ×N chip and "Seen N times" line keep the scale visible without making it the headline.

The five badges

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 what's still failing 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 causes 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.

"Seen 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 "Seen 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 since succeeded). A different error for the same user is still its own separate group — nothing is hidden or merged that shouldn't be.

Once every instance of a cause has since succeeded, the row leaves the live list and is folded away underneath as "N causes sorted themselves out" — good news, kept out of the way.

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 Sync activity bars on the Dashboard and Sync pages show what applied (green) with what didn't stacked on top (gold), and are clickable — a click opens the Logs page pre-filtered to exactly that day's failures, with a dismissible date chip.

Result

Errors stop being a wall of red: the pages lead with what worked, each cause is one line that tells you whether to act, wait, or leave it to Realsmart — and gives you the one-click way to do it.