Compliance alerts and chapter overrides

Two of the most-used admin tools on the compliance page are alerts (automatic warnings when a chapter is behind) and overrides (per-chapter target adjustments for special cases). They solve different problems but share the same goal: keep your compliance program honest without manually chasing every chapter.

Compliance alerts

An alert is a notice that something has gone wrong on a chapter's compliance — most commonly, a requirement has gone past its due date without being satisfied. Alerts surface in three places: the Alerts tab on the org compliance page, the chapter dashboard's Alerts tab, and as notifications in the bell menu for affected admins.

When alerts fire

A nightly background job sweeps every organization with the operations module enabled and:

Marks any Not started, In progress, or Rejected requirement past its due date as Overdue (closed periods are skipped).
For each newly-overdue requirement, creates an alert (if one isn't already open for that chapter + requirement combo).
Sends notifications to every active org admin for the organization.

The alert carries:

Severity — Warning (the default for overdue alerts) or Critical (reserved for future use).
Title — e.g., "Overdue: Monthly Headcount Report".
Message — the chapter designation, requirement title, and what was due when.
Status — see the lifecycle below.

The sweep runs once per day. A chapter that misses a midnight deadline gets flagged on the next sweep.

Alert lifecycle

An alert moves through three statuses:

Open — newly created, no one has acted on it yet. The bell counts it.
Acknowledged — someone has seen it and clicked Acknowledge. The bell stops counting it, but the alert remains visible on the Alerts tab so it doesn't fall off the radar.
Resolved — the underlying issue has been addressed. The alert is closed out, with optional resolution notes.

What admins can do with an alert

Two actions on each open alert:

Acknowledge — marks the alert as seen. Records the user who acknowledged and the timestamp. Use this when you've noted the problem but haven't fixed it yet.
Resolve — closes the alert. Optional resolution notes ("Chapter submitted late on Friday, approved by regional"). Resolving without acknowledging first auto-marks the alert as acknowledged by the resolver in the same step.

Chapter officers can acknowledge alerts on their own chapter (so they can clear their alert badge), but resolution is typically an admin action.

There is no auto-resolve when the underlying requirement finally gets approved. If you want a clean Alerts tab, resolve alerts manually as the problems get fixed. Alternatively, let acknowledged alerts pile up — they don't count against the bell badge.

Where alerts are visible

Surface	What you see
Org Compliance → Alerts tab	All alerts across the org, filterable by status and severity, also respects the semester picker
Chapter dashboard → Alerts tab	Just alerts for that chapter
Bell menu	Notification per alert; badge count from the per-user count endpoint
Email	National admins get an email notification per new alert

the alerts tab with a list of overdue warnings and Acknowledge / Resolve buttons

Tips on alert hygiene

Acknowledge daily, resolve weekly. Acknowledge clears the bell so you can see today's new ones; resolve weekly to keep the historical list useful.
Use resolution notes. "Chapter submitted late, approved" tells a future regional admin what happened. An empty resolution leaves them wondering.
Don't ignore acknowledged alerts. If an alert sits acknowledged for three weeks, the underlying problem is still there.

Per-chapter overrides

An override is a per-chapter target adjustment for a single requirement. It lets you say: "the program says 5 service events per semester, but this colony only needs 3." The override applies only to that one chapter on that one requirement.

What overrides can adjust

Overrides set a custom target — the number a chapter needs to hit to satisfy a count or numeric requirement. They can only be applied to:

Count tracking — the target is the number of approved submissions the chapter needs.
Numeric tracking — the target is the value the chapter is self-reporting against.

You cannot override submission tracking requirements (where the requirement is satisfied by a single approved submission — there's no number to lower). You also cannot exempt a chapter from a requirement via an override — for that, use the Exempt status on the chapter status row directly.

How to grant an override

The override flow is launched from a count or numeric requirement's detail. The dialog lists:

Existing overrides for that requirement (which chapters, what their custom targets are, optional notes).
A form to add a new one — pick a chapter, set the custom target, leave notes explaining why.

Save it and the override is in effect immediately. From that point forward:

The chapter dashboard's progress bar uses the custom target, not the default.
The auto-transition logic for numeric tracking uses the custom target (the requirement flips to Submitted when the chapter hits the custom number).
The XLSX export reflects the override.

You can also edit or delete an existing override from the same dialog. Deleting an override snaps the chapter back to the default target.

Audit trail

Every override creates an audit log entry — who created it, when, and the chapter and custom target. Updates and deletes are logged too. The override row itself captures the granting admin, the optional notes field, and the timestamps. If a regional admin asks "why does this colony only need 3 events when everyone else needs 5?", the override row tells them, and the audit log says who decided. See Reports, exports, and audit logs.

When overrides apply

Overrides apply to the specific requirement they were created against. Because requirements are bound to compliance periods (see Semester management), an override granted in Fall 2025 does not carry over to the Spring 2026 requirement spawned from the same template. You re-grant it each period.

This is deliberate: a chapter's circumstances change semester to semester. A colony that needed 3 events instead of 5 in fall may be ready for the full 5 by spring.

Override use cases

Brand-new colonies still spinning up — lower service-hour or event targets while they grow.
Chapters under suspension or in academic recovery — reduce non-essential targets while focus is elsewhere.
Special-case logistics — a chapter at a school that just transitioned online and can't host in-person events.

What overrides do not do

Overrides do not waive a requirement (the chapter still has to submit; the bar is just lower), do not apply across requirements, and do not cascade across periods. If you need to truly exempt a chapter from a requirement, set that chapter's status row directly to Exempt — that removes the requirement from the chapter's overdue count and from the alert pipeline.

There are no limits today on how many overrides an admin can grant or how low a custom target can go. The audit log is the accountability mechanism.

How alerts and overrides interact

An override does not silence alerts — it changes the bar at which the requirement is considered satisfied. If a chapter has an override of 3 events and only logged 1 by the deadline, an overdue alert still fires.

Conversely, an alert acknowledgment does not satisfy the requirement — it just clears the badge. The underlying requirement still needs the chapter to submit, get approved, and cross its target (default or override).

Tips

Document override rationale. A blank notes field becomes a question mark later.
Re-grant overrides at period open. Make this part of your start-of-semester checklist.
Resolve alerts in batches. Friday afternoon: walk the Alerts tab, mark off everything that got cleared during the week, and leave the rest for follow-up.

Last verified against v0.62.1.