> ## Documentation Index > Fetch the complete documentation index at: https://docs.helmkit.com/llms.txt > Use this file to discover all available pages before exploring further. # Triage > A single screen that surfaces everything across your organization currently in an attention-worthy state — action items overdue, runs missing staffing, integrations failing export const PriorityLabel = ({level, showLabel = true}) => { let label = ""; let color = ""; let svg = null; switch (level) { case "none": label = "None"; color = "#71717a"; svg = ; break; case "low": label = "Low"; color = "#71717a"; svg = ; break; case "medium": label = "Medium"; color = "#3f3f46"; svg = ; break; case "high": label = "High"; color = "#d97706"; svg = ; break; case "urgent": label = "Urgent"; color = "#dc2626"; svg = ; break; default: return null; } return {svg} {showLabel && {label}} ; }; ## What is Triage? Triage is one screen that shows everything across your organization currently in a state that needs a human. Not "what happened" (that's your Inbox), not "what's on the schedule" (that's your Calendar) — but **what's currently off, across the entire operation, and what should I fix first**. Concretely, Triage is where you see: * Action items that are overdue, unassigned, or assigned to you * Runs happening soon that still don't have a guide * Runs that need tickets but don't have them yet * Runs that are over capacity or in an inconsistent state * Guide invitations that have been sitting unanswered (or that were declined) * Third-party integrations that are failing to sync Open it in the morning, clear what you can, and you'll know your operation is in shape for the day. ## Signals: the core concept Every row in Triage comes from what we call a **signal**. A signal is a named condition — for example, "action item overdue" or "run missing tickets" — that Helm watches across your data. Triage has no inbox, no queue, no push. It's a view over your live data. When the thing is true, it's there. When the thing stops being true, it disappears. There's nothing to "mark read." A few things follow from this: * **Triage checks your live data every time.** There's no separate "things needing attention" list stored anywhere. Each time you open the page, Triage looks at what's happening right now and shows you what matches. Entries appear and disappear in real time as your data changes. * **Entries clear themselves.** Marking an action item done removes it from Triage within a second. Assigning a guide to a run clears the "no guide" entry. Getting your integration syncing again clears the sync-failure entry. There's no "dismiss" step. * **The same thing can match several signals.** An action item that's both overdue *and* unassigned shows up as two entries — one for each signal. That's intentional: two different problems with the same item deserve two different surfaces. * **New kinds of signals can be added at any time.** Because Triage looks at your existing information live, Helm can introduce new signals without you having to migrate or set anything up — they just start catching the things they were designed to catch. See the [Signals reference](/features/preflight/triage/signals) for the full list of what Triage currently watches. ## How urgency works Each entry in Triage has a priority from to . For most signals, priority isn't fixed — it climbs automatically as the relevant date approaches. Priority updates on its own. You don't need to refresh the page to see it climb — Triage checks about once a minute, and again whenever you switch back to the tab. The default escalation curve: | Time until the anchor date | Priority | | --------------------------------- | -------------------------------- | | More than 30 days away | | | 8 — 30 days | | | 2 — 7 days | | | Less than 2 days, or already past | | So a guide invitation that's been pending for weeks will quietly sit at , climb to as the run approaches, then in the last week, and in the last 48 hours — without anyone touching it. A few signals don't age — they're always shown at a flat priority, regardless of timing: * **Integration sync failures** — present until the integration recovers, no time anchor at all * **Runs over capacity** — flat * **Rejected guide invites** — flat And one signal skips the curve in the other direction: **overdue action items** are always , from the moment they go past due. ## How entries leave Triage This is the primary way. The action item is marked done, the guide is assigned, the ticket is uploaded, the integration reconnects successfully. Within about a second of the change, the entry disappears from everyone's Triage. Any entry can be snoozed for a chosen interval: 1 hour, 4 hours, until tomorrow morning, or until next Monday morning. Snoozes are **personal** — they only hide the entry from you, not from your teammates. The entry reappears when the snooze expires, unless the underlying state resolved in the meantime. Organization admins can disable individual signals under **Settings → Triage**. A disabled signal is invisible to everyone in the organization until it's re-enabled. This is useful if a particular signal is noisy for your workflow, or if you haven't set up the underlying data for it yet (for example, `run.missing-tickets` only makes sense once you've marked some rates as requiring tickets). ## What you see when you open Triage The page has three parts: On the left: an **Everything** button that resets the view, any **saved views** you've pinned as chips, and a **Views** dropdown with the rest. On the right: a **Filter** menu (signals, assignees, snoozed, run status), **Sort**, **Group**, and **Horizon** controls (default horizon: 14 days). See [Filters & views](/features/preflight/triage/filters-and-views) for the full breakdown. One row per matching entry: the thing's title, the signal that surfaced it, its priority chip, and its time anchor (if it has one). Click a row to open its details on the right. Shows the full record of whatever you selected — the action item, the run, the guide invitation, the integration. You can usually take action directly from here without leaving the page. ## Who lands where First time anyone on your team opens Triage, Helm picks a reasonable starting filter based on their role: * **Admins and owners** land on the full view — every enabled signal, no filter. The goal is operational oversight. * **Everyone else** lands with an **Assigned to me** filter pre-applied — they see what affects them personally, not the broader organizational state. After that first visit, Triage remembers what you had last time on this computer and opens with it next time. To share a specific view with a teammate, just copy the page link and send it — they'll see exactly what you see. ## Triage, Inbox, and Reminders Action items in Triage are the same action items you see inside an event. A reminder firing for an action item delivers to your **Inbox** — it doesn't change anything in Triage. The item may already be in Triage (because it's overdue, or assigned to you, or unassigned), but that's its own reason. Clearing the reminder from your inbox doesn't clear the Triage entry, and completing the item from Triage doesn't mark the reminder read. See the [Preflight overview](/features/preflight) for the full framing of how Inbox, Calendar, and Triage relate. ## Up next Every signal in Triage today — what it watches, how its priority escalates, and what clears it. Quick chips, horizons, sort, snooze, and the saved-view and admin-level signal controls.