Issues queue triage

Outcome

Every operational anomaly the platform raises — a claim stuck in submission, an auth utilization breach, an ingestion batch failure, an EVV exception spike — lands in one consistent inbox, gets assigned, gets resolved, and is visible on the dashboard so leadership knows when something needs attention.

Prerequisites

Scope	What it lets you do
ops.issue.read	View list / detail
ops.issue.write	Triage / resolve / waive

The Issues queue collects across categories. You do not need to enable it; the platform raises issues as it observes thresholds breached.

What lands in the queue

Category	Examples
Billing	Claim stuck in BUILT past N hours; rejection rate spike on a payer.
Eligibility	Sweep failure; subscriber-not-found rate spike.
Authorizations	Auth nearing exhaustion within 7 days.
Ingestion	Batch failed to map; expected file did not arrive.
EVV	Exception rate above threshold on a source.
Reporting	Scheduled email failed to deliver.
Accessibility	User-reported (see 8.4 — Keyboard & accessibility).

The queue is filterable by category, severity, age, assignee.

The queue

/issues. Default filter: OPEN + IN_PROGRESS.

Column	Meaning
Severity	INFO, WARNING, ERROR, CRITICAL.
Category	One of the above.
Subject	Short headline.
Body	Up to 200 char preview; click for full.
Assigned to	Empty if unassigned.
Age	Time since raise.
State	OPEN, IN_PROGRESS, RESOLVED, WAIVED.

Issue detail

Click into /issues/:id. The page has:

Section	Content
Header	Severity, category, subject, raised-at.
Narrative	The full message; the platform fills in member / claim / auth / batch identifiers.
Linked records	Click-throughs to the underlying claim / auth / batch / etc.
Communication	Notes; visible in audit log.
State actions	Take, Resolve, Waive, Reassign.
Suppression	If the issue is one of a recurring pattern, suppress with a reason.

Triage flow

Steps

1. Open /issues. Sort by severity descending, then age descending.

2. Take the top row. The state moves to IN_PROGRESS; you become the assignee.

3. Click into the linked record (claim / auth / batch). Take the appropriate action there:

   Category	Typical action
   Stuck claim	Resubmit or fix per 2.1 — Build & submit a claim.
   Auth nearing exhaustion	Renew per 3.3 — Manage authorizations.
   Failed batch	Re-run mapping per 5.5 — Manage ingestion mappings.
   EVV exception spike	Triage per 4.2 — Work the EVV exceptions queue.

4. Return to the issue and click Resolve. Add a note explaining what you did. The issue moves to RESOLVED.

5. If the issue is noisy (the same condition keeps being raised even though you have decided to live with it), click Suppress. Define the suppression scope — by category + linked entity, or by category + duration. Suppression is audit-logged.

Daily triage discipline

A clean issues queue every morning is the cheapest form of monitoring. Suggested discipline:

• CRITICAL within 1 hour.
• ERROR within 4 hours.
• WARNING by end of business day.
• INFO weekly.

Tenants with an operations analyst typically own the queue end-to-end and escalate per category when needed.

Validation

Check	Expected
Resolved row drops out of the active filter	Yes.
Audit log carries every state change	Yes — see 6.3 — Audit log lookup.
Suppressed issues do not re-raise during the suppression window	Yes; the platform notes the suppression every time it would have raised.
Dashboard issue count matches the open queue	Yes (eventual within 1 minute).

Troubleshooting

Symptom	Cause	Fix
Issue refuses to resolve	A precondition is unmet (e.g. linked claim still BUILT)	Resolve the underlying problem first; then re-resolve the issue.
Same issue keeps re-raising	The raise condition is still true after you "resolve"	Suppress with a brief duration while you work the root cause.
Issue's linked record link 404s	The record was deleted	Resolve and waive; note that the source record is gone.
Suppress button greyed	Missing ops.issue.suppress	Ask a tenant admin.

Next

8.1 — Glossary for the domain terms you will encounter, or revisit Getting Started any time a new teammate joins.