Before this work, there was no way to understand whether a district’s data actually met a partner’s expectations without manually inspecting each field, one at a time and across every district connection.

Even though partners defined what “good data” meant (through Required, Supported, and Not Supported fields) at the field level, there was no aggregated view of how those expectations were being met.

As a result, understanding a single connection meant drilling through raw data previews, field by field. Basically, compliance wasn’t measured and partners had to manually:

If the field was shared, data appeared. If not, nothing surfaced... no warning, no explanation, no signal. This process was repeated across fields, across collections and across every district in the system.

With no summary layer, there was no way to understand compliance at a glance, only through an accumulation of repeated manual checks.

The idea made sense from the start., but the challenge was scale. A single partner could be connected to hundreds of districts, sometimes well over 600, and there was no quick way to tell which ones actually needed attention. Every connection looked the same, whether it was healthy or silently missing critical data.

Clicking a pill opens a summary built specifically for that district: which fields are required, what the partner expects to see, and what the district actually shared back in response.

The goal was turning "you're at 56% compliant" from a slightly worrying number into something a partner could genuinely act on the same day.

This ended up being the real design question, and it wasn't an obvious one.

A full table showing every field would give partners the complete picture, but most of those fields would already be matching what the partner asked for, which means a lot of scrolling past things that didn't need attention.

Showing only the fields that fell short of what the partner marked Required or Supported would be faster to scan, but it would also hide the bigger context of how compliant a district actually was overall.

We shipped with violations-only first. It matched what partners actually needed in the moment. A short, fast list of exactly what to fix, rather than a full audit they'd have to filter through themselves.

Once it shipped, it became clear that some partners wanted to audit every single field, not just the broken ones, especially when they were trying to understand why a tenant was sitting at 56% instead of higher. That's a fair thing to want and it wasn't something the violations-only view could answer on its own.

So we added a second table underneath the violations summary, collapsed by default, that showed the complete field-by-field breakdown.

Partners who just needed to know what to fix could ignore it entirely, and partners who wanted the full picture could expand it and dig in.

Neither version was wrong on its own, the first shipped fast and solved the most common need well, and the second extended it once real usage showed there was a second need too, without requiring us to undo anything we'd already built.

Before Smart Rostering, confirming whether a single field was shared meant five separate steps: find the connection, open the raw data preview, navigate to the right collection, scan the column headers for what was there, and try to notice what was missing. If a district had opted out of sharing a field, its column simply didn't appear in the table. No flag, no message, just absence.

Multiply that by every field a partner cared about, across every tenant they were connected to, and it's clear why nobody was actually doing this audit regularly. It wasn't just a slow process, but also an impractical one.

Smart Rostering collapsed all five of those steps into a single colored pill sitting right in the tenant table. The compliance percentage didn't just summarize the old manual check faster, it replaced a process that was effectively too tedious to use at scale with one a partner could actually run on hundreds of their connections without thinking twice.