Exceptions: queue, resolve, escalate, dismiss

What is an exception?

An exception is anything the platform flagged during ingestion, rule evaluation, or billing-run reconciliation that could not be auto-resolved. Exceptions are the platform's way of saying: "this row needs a human." Examples:

• A roster file referenced a member ID that doesn't exist anywhere in the platform.
• An eligibility event landed for a member whose state machine doesn't permit that transition.
• A billing-run cycle resolved zero billable days for an active member (suspicious; may indicate a rule bug).
• A service-delivery event lacked a corresponding eligibility window.
• A duplicate member was detected across two payer rosters.

The Exceptions screen

Open Exceptions from the left nav. Default view: all OPEN exceptions for your tenant, grouped by category and sorted by severity descending. Filters at the top let you narrow by category, severity, payer, date range, and status.

The four resolution actions

Resolve

The underlying issue is fixed; close this exception. Typical use: corrected roster uploaded, offending rule edited, affected billing cycle re-run. Requires a one-sentence resolution note (written to the audit trail).

Escalate

Raises the exception to your tenant's escalation queue (visible to OWNER / ADMIN). Use when an exception requires a decision you can't make yourself.

Dismiss

Says "this exception is noise; don't bother me with it." Requires a dismiss reason. Dismiss is NOT delete — the exception row stays in the database; it just no longer appears in the OPEN queue.

Re-open

Resolved or Dismissed exceptions can be reopened from the row menu. Re-opening writes an audit row and moves the exception back to the OPEN queue.

Bulk actions

With multiple rows selected you can bulk Resolve, bulk Dismiss, or bulk Escalate. Bulk actions require a single shared note that applies to every selected row.

How exceptions reach the queue

• Layer 1 / 1b ingestion: roster rows or service-delivery events that fail schema validation, member resolution, or transition validation.
• Layer 2 rules engine: ambiguous billable-day resolution, retroactive-window-still-open edge cases, eligibility × service-delivery mismatches.
• Layer 3 output: zero-charge active members, missing PHI fields required for export.
• Background jobs: leakage detection, retention purge, audit chain verification.

Working through a busy queue

• Sort by category. Many exceptions in the same category share a root cause.
• Fix the root cause once (re-upload corrected file, override rule), then bulk-Resolve.
• For repeated false-positives, tune the rule that's raising them rather than perpetually dismissing.

Audit footprint

Every action writes an audit row tagged EXCEPTION_* (RESOLVED, DISMISSED, ESCALATED, REOPENED). The chain is hash-linked.

Permissions

• OPERATIONS, BILLING_MANAGER, ADMIN, OWNER can Resolve, Escalate, and Dismiss.
• VIEWER is read-only.
• Re-opening a Resolved exception requires ADMIN or OWNER.
• Escalation queue is visible to ADMIN and OWNER only.