Settings nobody revisits until something goes wrong.

The alerts are the monitoring.

A roster sync runs on a schedule, often overnight, and moves thousands of student and staff records into downstream systems. Nobody watches it happen. The notification email is the entire monitoring layer for most districts, because there is no operations team sitting in front of a dashboard at 3am.

Which means this settings page is not a preferences panel. It decides whether a failure gets noticed.

Two opposite failures, one screen.

Get it too quiet and an import fails silently. Nobody finds out until a teacher reports a missing roster days later, by which point the bad data has propagated downstream.

Get it too loud and every administrator receives a success email every single night. Within two weeks those messages are filtered into a folder nobody opens, which produces exactly the same outcome as having no notifications at all, except everyone believes they are covered.

Organize by person, or by event?

Both are legitimate and they answer different questions. A list organized by event answers coverage: who is subscribed to import failures? A list organized by person answers accountability: what is this administrator getting?

You cannot lead with both. Whichever you choose, the other question becomes harder to ask.

People first, with a way back to events.

Collapsed rows summarize coverage; expanding one shows the individual preferences behind that summary.

Every toggle says what will actually arrive.

A toggle labeled "import communications" tells an administrator nothing about what lands in their inbox or how often. Configuration screens are where wrong assumptions survive longest, because nothing contradicts them until an incident does.

So each preference carries an explanation of what triggers the email and what it contains. Not what the setting is called, what the setting does.

That last one is the distinction that changes behavior. An import-completed email is a receipt. An import-failed email is a request for action. Naming the difference at the point of configuration is what lets someone subscribe to the second without drowning in the first.

The settings, rebuilt and interactive.

I rebuilt this as a standalone prototype with fictional records, embedded below. Add a recipient and watch the summary pill change as you toggle preferences, then filter by notification type to see the coverage view.

Why person-first won.

Organizing by event would have made coverage auditing the default view, which is arguably the more important question. It would also have made routine edits, adding a new hire or removing someone who left, into a hunt across several event groups.

Person-first won because editing is the frequent task and auditing is the rare one. Someone joins or leaves every few weeks. Someone audits coverage once a year, usually after an incident. Optimizing the layout for the rare task would have taxed every routine edit, and the type filter recovers the audit view in one control.

Shipped, and in daily use.

The settings are in production. Administrators can see at a glance who is covered, adjust an individual without touching anyone else, and filter the roster to confirm somebody will hear about a failed run before it happens rather than after.

Quiet screens carry loud consequences.