How Linear triage works

What Triage is, and why it exists

Triage is a per-team inbox: issues created by an integration, or by a workspace member outside the team, land there first instead of going straight into the team's active workflow. It's turned on per team in Team Settings, and once enabled appears as its own entry in the sidebar. It can also be reached directly with the keyboard shortcut G then T.

The point of the extra step is quality control. Without it, an integration or an outside teammate could put an issue directly into a team's backlog with no review, no priority, and no owner. Triage gives someone a moment to look at every such issue before it becomes part of the team's real workflow.

The four actions, and the keyboard flow

Everything in Triage resolves down to one of four actions, each with its own keyboard shortcut so a team can move through a queue without touching the mouse:

1. 1

   Accept (1): moves the issue into the team's default workflow status, with the option to add a comment before it leaves Triage.

2. 2

   Mark as duplicate (2, or MM): merges the new issue's attachments and any linked customer requests into the canonical issue it duplicates, then cancels the new one.

3. 3

   Decline (3): cancels the issue outright, with an optional explanation for why it isn't going forward.

4. 4

   Snooze (H): sets the issue aside until a chosen time, or until new activity arrives on it, and hides it from the rest of the team for as long as it's snoozed.

Requiring priority before issues leave Triage

A team can turn on a setting that requires every issue to have a priority set before it can leave Triage. That forces a small but useful decision at the one point every incoming issue is guaranteed to pass through, so urgency is recorded before an issue disappears into the general backlog rather than being guessed at later.

Rotating who owns Triage

Triage Responsibility assigns a rotating owner for incoming issues, so clearing the queue is a shared, scheduled duty rather than whoever happens to notice new issues first. The rotation can sync with an existing on-call schedule from PagerDuty, Opsgenie, Rootly, or Incident.io, so the same schedule that already handles incidents also covers who owns Triage that week.

Automating Triage: Rules, then Intelligence

Triage Rules apply an action automatically when an issue matches a condition, on its reporting team, status, assignee, label, project, or priority. Rules run top-down in a defined order, so an earlier rule takes precedence over a later one; if a rule routes an issue to a different team, that team's own Rules then get a chance to act on it in turn.

Triage Intelligence goes a step further: it reviews each new issue against the workspace's history using an LLM, suggesting properties like a label or priority and flagging issues that look like duplicates of something already tracked. It can be left as a suggestion for a person to confirm, or configured to apply automatically, and the guidance it follows can be refined over time as it gets things wrong.

Triage Rules, Triage Intelligence, and Triage Responsibility are all Business and Enterprise features.

How issues actually reach Triage

Beyond issues a teammate files directly, Triage is where automatically created issues land: from support-tool integrations including Intercom, Front, and Zendesk, from a shared inbox for engineering teams that routes customer messages straight into Linear, from Slack, from error tracking via Sentry, and from Linear's own Asks. A team's real Triage queue is usually some mix of all of these rather than any single source.

Keeping Triage healthy

Triage stays useful for as long as a team treats clearing it as a real, owned duty rather than an optional chore. In practice that comes down to a few habits: keeping a rotation in place so responsibility never quietly defaults to nobody, turning on the require-priority setting so urgency gets recorded at the one guaranteed checkpoint, and being disciplined about marking real duplicates as duplicates rather than accepting near-identical issues separately, which is what keeps the merged history in a canonical issue actually useful.