The short version. Triage rules are Linear's front door for incoming work: they route issues to the right team and fill in properties automatically. If you came looking for "nothing leaves Triage without a priority", you want a different Linear feature — a team setting called Require explicit prioritization — and it is native, free with your plan, and does exactly that. This page covers what the rules do, what the setting does, and the boundary neither of them reaches.
A Triage rule runs when an issue enters Triage, filters on the issue's properties, and can update its team, status, assignee, label, project and priority. Rules run from the top down, and an issue routed to another team then picks up that team's rules as well. Triage rules are available on Linear's Business and Enterprise plans.
No — a Triage rule sets a value, it does not demand one. But do not conclude from that that Linear cannot require anything here: a separate team setting, Require explicit prioritization, does require a priority to be set when moving issues out of Triage. The rules and the setting are different mechanisms, and the setting is the one that enforces.
No. They run when an issue enters Triage. Once an issue has left, nothing re-evaluates it — so a rule cannot check anything later in the workflow, such as whether an estimate is present by the time work is finishing.
Business and Enterprise. Triage itself is available more widely, and so is the Require explicit prioritization setting — it is the rules that act on arriving issues which need the higher tiers.
Turn on Require explicit prioritization in Team settings under Triage. It is native, it is free with your plan, and it does exactly this. Reach for a third-party tool only if the field you need required is something other than priority — an estimate, an assignee, a label from a particular group — because the setting covers priority and nothing else.
Linear's documentation describes them plainly: rules run when issues enter Triage, filter on the issue's properties, and can update the issue's team, status, assignee, label, project and priority. Rules are executed top-down, conflicting rules are flagged in the interface, and an issue moved to another team by a rule then has that team's rules applied to it as well. Holding Shift while selecting filter values gives you an any-of condition rather than an all-of one.
They are on Business and Enterprise. This matters more than it looks: a good part of the advice written about enforcing process in Linear assumes Triage rules are available, and for a workspace on a smaller plan they are not.
Routing, mainly, and it is a real problem well solved. Bug reports from a support inbox land in one queue and need to reach four teams. A rule reads the labels, sets the team, and the issue is in front of the right people without anyone triaging the triage. The top-down ordering with conflict flagging is a sensible design for a rule set that grows, and re-applying the receiving team's rules after a route is the behaviour you would want but might not have thought to ask for.
If your problem is where does this go, Triage rules are the answer and you do not need anything else. It is worth saying that clearly, because the rest of this page is about a problem they do not solve, and it would be easy to read that as a criticism. It is not one.
Two limits, and both follow from what a Triage rule is rather than from any gap in the implementation.
A rule sets a value; it cannot require one. It can assign a priority to an arriving issue. It cannot decline to let the issue leave Triage until a human has chosen one. The distinction sounds academic until you look at the result: a rule that sets every unprioritised bug to Medium has produced a board where every bug has a priority and none of them means anything. The field is now worse than empty, because empty was at least honest about not having been considered.
This is exactly why the Require explicit prioritization setting exists and is worth turning on: it demands the decision instead of manufacturing one. Note it is a separate mechanism from the rules — it lives in Team settings under Triage, not in the rule list — and the two are easy to confuse when someone tells you "Linear can't require fields". For priority leaving Triage, it can.
Everything here is about Triage, and only Triage. Rules fire when an issue enters it; the prioritisation setting applies when an issue leaves it. Neither can check whether an estimate is present when work finishes, or whether an assignee is set when work starts, and neither covers a field other than the ones listed. Most of what a team writes in its handbook is about those later moments rather than about intake — and one field at one boundary is the whole of what Linear enforces.
The missing shape is a check on any boundary, for any field, with a consequence when it fails. Priority-out-of-Triage is the one instance of that shape Linear ships; the rest look the same and have nowhere to live. In LineGuard:
area label group is empty — or a nested group of conditions, if the real rule is more specific than that.The comment is not decoration. A rule that reverts silently is indistinguishable from a bug, and the person who moved the issue learns nothing except that Linear is behaving strangely. A rule that explains itself teaches the process on the issue, in the moment, to the person who needed to know.
Because Linear delivers a change after it has been committed, this corrects rather than prevents: the issue does move, and comes back within a couple of seconds. The native prioritisation setting has no such window, which is a real advantage — another reason to use it for the case it covers rather than rebuilding it. For workflow hygiene that window is nothing, and the upside is that it applies to every write path — the app, the API, Slack, an integration you forgot was installed. More on that trade-off in required fields for Linear.
These are complements, not alternatives, and the division is clean:
A workspace on Business with all three is not doing the same thing three times. It is inferring, then asking, then checking.
Turn on the prioritisation setting first — it is free and it removes one whole class of problem. Then, if something is still leaking, one rule will tell you how badly within a fortnight: nothing enters Done without an estimate, reverting with a comment, and the audit log counting how often it fired. That number is the thing worth having — not because the rule fixed it, but because you now know whether "we always estimate before Done" was ever true.
The free plan runs three rules on one team, no card, every trigger and condition included. Plans and limits.
Not a workspace admin? Send it to the person who is.
Related: Required fields for Linear · Enforcing a definition of done in Linear · Workflow automation in Linear