> ## 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.
# Signals
> Complete reference of the conditions Triage watches for — what each signal detects, how its priority works, and what makes an entry clear
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}}
;
};
## How to read this page
Triage watches for a fixed set of **signals** — named conditions across your organization's data. Each section below describes one signal, grouped by the kind of thing it watches. For each signal, you'll see:
* **What it detects** — the plain-English condition that makes an entry appear.
* **Priority** — either a flat level, or *escalating*: priority climbs as the run gets closer. See [the escalation curve](/features/preflight/triage#how-urgency-works) for how the time-based levels work.
* **Time anchor** — the date Triage uses to sort the entry and decide whether it falls inside your time horizon. Usually this is the linked run's start date; for action items, it's the item's due date.
* **What clears it** — the specific actions that make the entry disappear.
Every signal is enabled by default. Admins can turn any of them off for the whole organization under **Settings → Organization → Triage** — see [Filters & views](/features/preflight/triage/filters-and-views#turning-signals-on-or-off) for details.
## Action items
**What it detects:** Action items past their due date that aren't marked done or cancelled.
**Priority:** Always . An item past due is as critical as it gets — there's no "slightly overdue" bucket.
**Time anchor:** The item's due date.
**What clears it:**
* Mark the item Done or Cancelled
* Push the due date to a future time
* Delete the item
* Snooze it (personal only — others still see it)
**What it detects:** Open action items (Todo or In progress) with no one on the recipient list. Nobody is accountable, so nothing will move them forward.
**Priority:**
* If the item has a due date: escalating via the default curve ( → as the deadline approaches).
* If the item has no due date: flat .
**Time anchor:** The due date, if set. Otherwise none — the item shows regardless of the time horizon.
**What clears it:**
* Assign the item to one or more people
* Mark it Done or Cancelled
* Delete the item
**What it detects:** Open action items where you personally are on the recipient list. This is "my work" — the lens you'll land on by default as a non-admin.
**Priority:** Uses the item's own priority field (you set it when creating the item). If the item's priority is left at "None," Triage falls back to the time-driven escalation curve so time-boxed items still rise to the top.
**Time anchor:** The item's due date, if set.
**What clears it:**
* Mark the item Done or Cancelled
* Remove yourself from the recipients
* Delete the item
## Runs
**What it detects:** Upcoming runs with no accepted guide. Triggers for runs that have never been invited to a guide, for runs where every invitation was rejected or cancelled, and for runs where invitations are still pending.
**Priority:** Escalating via the default curve. A run a month out sits at ; the week before, ; the last 48 hours, .
**Time anchor:** The earliest active (non-cancelled) booking's start time.
**What clears it:**
* A guide accepts an invitation for the run
* The run's bookings are all cancelled
* The run's earliest booking moves to the past
**What it detects:** Upcoming runs on a rate flagged "Requires tickets" where no ticket has been uploaded yet. One entry per run, not per booking — tickets attach to the run as a whole.
**Priority:** Escalating via the default curve.
**Time anchor:** The earliest active booking's start time.
**What clears it:**
* Upload at least one ticket to the run
* Flip the rate's "Requires tickets" setting off (see [Filters & views](/features/preflight/triage/filters-and-views#configuring-requires-tickets))
* The run's earliest booking moves to the past
This signal only fires on rates you've explicitly marked as requiring
tickets. If you've never enabled it, you'll never see the signal — it's
safe to leave on.
**What it detects:** Runs whose total booking count has exceeded the rate's configured capacity. Helm tracks this as a first-class run status, so the signal is always in sync with what you'd see on the run detail view.
**Priority:** Flat . Over-capacity is an immediate operational issue regardless of timing — you can't double-book the boat.
**Time anchor:** The earliest booking's start time.
**What clears it:**
* Increase the rate's capacity
* Move one or more bookings to a different run
* Cancel enough bookings to fit within capacity
**What it detects:** Runs flagged as inconsistent, usually because the bookings on the run have diverging information — different start times, different pax counts, different pickup details — that need a human to resolve.
**Priority:** Escalating via the default curve. Earlier in the cycle you have time to investigate calmly; closer to the run, it's urgent.
**Time anchor:** The earliest booking's start time.
**What clears it:**
* Resolve the conflicts (unmerge bookings, cancel the conflicting one, or update details so they line up)
* The run's earliest booking moves to the past
## Guide invitations
**What it detects:** Guide invitations that were sent but haven't been accepted or rejected yet.
**Priority:** Escalating via the default curve. A pending invite three weeks out is ; the week before, ; 48h before, .
**Time anchor:** The linked run's earliest booking start time.
**What clears it:**
* The guide accepts the invitation
* The guide rejects the invitation (this moves the entry to the **Rejected guide invites** signal instead)
* You cancel the invitation
* The run moves to the past
**What it detects:** Guide invitations that were explicitly rejected. Requires re-inviting the same guide (with different terms, usually) or inviting someone else.
**Priority:** Flat . A rejection is an immediate staffing gap regardless of how far out the run is.
**Time anchor:** The linked run's earliest booking start time.
**What clears it:**
* Send a new invitation (which supersedes the rejected one)
* Another guide accepts a different invitation for the same run
* You cancel or delete the rejected invitation
* The run moves to the past
## Integrations
**What it detects:** Third-party connections (currently WooCommerce) whose recent sync health is reported as degraded or unhealthy.
**Priority:** Flat . A failing integration affects data freshness across the whole organization, not just one run.
**Time anchor:** None — this signal has no date. It's always shown regardless of the time horizon filter, and stays until the integration recovers.
**What clears it:**
* A subsequent sync succeeds and the health check flips back to healthy
* The integration is disconnected from the organization
If you're seeing this signal repeatedly on the same integration, check the
connection's settings under **Settings → Integrations**. The detail panel
in Triage links straight there.