Rostering Data Quality

---
name: rostering-data-quality
description: Diagnose rostering / SIS / LMS data-sync issues in EdTech contexts — K-12 (Clever, ClassLink, OneRoster), higher-ed (SIS/LMS), corporate L&D (HRIS/LMS). When to escalate to product vs coach the partner's admin. Reach for this skill when a partner says "the data isn't right" or when partner-engagement metrics drop without an obvious user-side cause.
---

# Skill: Rostering Data Quality

Rostering issues masquerade as engagement issues. A partner who looks "red" on the health score may simply have a broken sync. **Check the rostering first; declare the partner red second.**

## Step 1 — Identify the rostering surface

Before diagnosing, pin down:

| Segment | Common surfaces |
|---|---|
| K-12 (district / school) | Clever, ClassLink, OneRoster (via Clever/ClassLink or direct), legacy CSV upload from SIS |
| Higher-ed | SIS (Banner, Workday Student, Colleague, Jenzabar), LMS-side rostering (Canvas, Blackboard, D365), LTI integration |
| Corporate L&D | HRIS (Workday, BambooHR, ADP), LMS (Cornerstone, Docebo, Saba, Litmos), SCIM provisioning, identity provider sync (Okta, Azure AD) |

Document which surface is in play for the partner. The diagnostic playbook diverges from here.

## Step 2 — Identify the failure pattern

Common patterns:

- **Stale data** — sync hasn't run in N days. Look at last-sync timestamp first.
- **Partial sync** — some entities synced, others didn't. Usually a permission / scope issue or a vendor-side outage during an incremental window.
- **Schema mismatch** — fields renamed, dropped, or repurposed on one side. Usually a partner-side admin change that wasn't communicated.
- **Identifier drift** — same user has different IDs across systems. Typically caused by email-as-identity changing (marriage, name change, departmental moves) without a stable backing ID.
- **Role / grade misclassification** — users sync but with wrong role / grade / cohort. Typically a partner-side admin mapping error.
- **Orphan accounts** — users in our system who no longer exist in the source of truth. Usually a sync that handles adds but not removes (intentional or otherwise).
- **Duplicate accounts** — users in our system multiple times. Usually a sync re-keying without dedup.

## Step 3 — Decide who owns the fix

This is the most common error. Categorize:

| Failure pattern | Likely owner |
|---|---|
| Stale data, no recent sync | Partner-side admin OR vendor outage. Check vendor status page first; if green, it's the partner. |
| Partial sync | Usually vendor; sometimes a permission / scope change on the partner side |
| Schema mismatch | Partner-side admin change OR our integration regression. Diff our integration's expected schema against current source. |
| Identifier drift | Our integration design (we may be using a non-stable identifier as primary key) |
| Role / grade misclassification | Partner-side admin mapping; coach the partner, don't escalate to engineering |
| Orphan accounts | Our integration design (didn't subscribe to delete events) OR partner-side decision (they want to retain accounts) |
| Duplicate accounts | Our integration design (insufficient dedup logic) |

**Anti-pattern:** assuming the partner is to blame when it's our integration. **Anti-pattern:** assuming engineering needs to fix it when it's a partner-side admin config.

## Step 4 — Verify before escalating

Before opening an engineering ticket OR before pushing the partner to investigate, verify:

- **Vendor status page** — for Clever, ClassLink, Workday, etc. — is there a current outage?
- **Sync logs** — when did the last successful sync run? What did it return?
- **Source-of-truth spot check** — pull 3–5 specific entities from the partner's SIS / HRIS / LMS and compare against our copy. Are they the same?
- **Schema diff** — diff the current source schema against the version our integration expects. Any fields renamed, added, dropped?
- **Partner-side admin** — did the partner make any recent admin changes (school year rollover, new academic term, M&A, reorg)?

A 15-minute verification before escalating saves a 5-day round-trip.

## Step 5 — Communicate the diagnosis to the partner

A partner who heard "your data is broken" without a specific cause will distrust the PSM. The right framing:

- Name the failure pattern in plain language (not "stale data" — "the sync from your Clever account hasn't run since 2026-05-18")
- Name the likely owner clearly (yours / theirs / vendor)
- Propose the specific next step (you check X / they check Y / we open a ticket with vendor Z)
- Set a check-in date (not "I'll follow up" — "I'll check back Friday at 2 ET")

## Step 6 — Document the resolution

The partner profile gets an entry under "prior incidents." Include:
- What broke
- When detected vs when started (the delay is itself a finding — if it took 3 weeks to detect, instrumentation is the gap)
- Who owned the fix
- What the fix was
- What to monitor going forward

A rostering incident that resolves without documentation is a future repeat-incident.

## Step 7 — Escalation paths

- **Partner-side admin coaching** — PSM (`edtech-partner-success-manager`) handles directly; pull `ferpa-comms-translator` if the partner-admin needs a parent / institution-leadership-facing version
- **Vendor outage / vendor-side bug** — open a ticket with the vendor; track in `ravenclaude-core/project-manager`; PSM keeps partner informed
- **Our integration regression** — escalate to `ravenclaude-core/architect` or `data-engineer`; usually requires a code change
- **Persistent identifier-drift issue** — architecture review; `ravenclaude-core/architect`
- **Privacy implication** (e.g., orphan accounts retaining FERPA-covered records past required retention) — mandatory `ravenclaude-core/security-reviewer` and likely `regulatory-compliance` if installed

## What this skill does NOT cover

- Designing the integration architecture (route to `ravenclaude-core/architect`)
- Choosing a rostering vendor (route to `ravenclaude-core/architect`)
- Vendor contract negotiation (out of scope for any agent; that's a business / legal motion)
- Generic data-quality patterns unrelated to EdTech rostering (route to `ravenclaude-core/data-engineer`)