The short version. Linear automates more than most people realise, and the honest answer to "do I need something else?" is usually no. This page maps what is built in, which plan each part needs, and what each is actually for — and then names the one thing Linear deliberately does not do, so you can tell quickly which side of the line your problem falls on.
Five things, mainly. Triage rules route and set properties on issues arriving in Triage. A team setting requires a priority before an issue leaves Triage. Loops let Linear Agent take on recurring work on a schedule or an event. Pull request automations move a linked issue's status as a PR is drafted, opened, reviewed, readied or merged. And auto-close and auto-archive clear out work that has gone quiet. Form templates additionally require fields at intake.
Triage rules and Loops are on Business and Enterprise, and Loops consume AI credits per run. Pull request automations, auto-close, auto-archive and templates are configured per team without those tiers.
A check at an arbitrary transition. Linear gates exactly one — priority, leaving Triage — and does not let you name another field or another boundary, so there is no native way to say an issue may not enter Done while its estimate is empty. That is a deliberate design position: keeping the write path open is what makes the app fast on every path into it.
A Loop reasons; a rule evaluates. An agent deciding the next best action from plain-language instructions is right for follow-ups, delegation and work that needs judgement. For a constraint that must be applied identically on the four-hundredth issue as on the first, at no marginal cost per check and with a record of each one, you want something deterministic.
For routing, recurring work, status changes driven by code, and a required priority out of Triage, no — Linear covers those natively and you should use them. For enforcing any other condition at any other boundary, yes: that is the shape Linear leaves to integrations, which is why its own directory carries an Automations category.
Five mechanisms, each aimed at a different part of the workflow.
Triage rules — documented here. They run when an issue enters Triage, filter on its properties, and can update its team, status, assignee, label, project and priority. Executed top-down, with conflicts flagged, and an issue routed to another team then picks up that team's rules. Business and Enterprise.
Loops — introduced in July 2026. You describe recurring work in plain language and choose whether it runs on a schedule or in response to an event; Linear Agent uses context from the workspace and connected tools to decide the next best action. Reviewing and dispatching issues, coordinating follow-ups from unstructured notes, keeping project documentation current. Business and Enterprise, and runs consume AI credits.
Pull request and commit automations — part of the GitHub integration. PR events update the linked issue's status: by default opening a PR moves the issue to In Progress and merging it moves the issue to Done. Configurable per team across drafted, opened, review requested, ready for merge and merged, and you can send merges to different statuses depending on the target branch — staging to one status, main to another.
A required priority leaving Triage — the Require explicit prioritization setting, in Team settings › Triage. Requires a priority to be set when moving issues out of Triage. Distinct from Triage rules, available without the higher tiers, and the only field requirement Linear enforces on a status change.
Auto-close and auto-archive — part of workflow configuration, alongside defining your own statuses within Linear's fixed categories and choosing the default status for new issues. Quiet work closes and archives itself rather than accumulating.
Alongside these, a form template can require customer, label group, priority, title and due date before an issue is created — the one place Linear does enforce rather than assist.
Most confusion here comes from reaching for the wrong one, so the short version of what each is for:
Between them these cover most of what a team means by workflow automation, and all of them are cheaper to adopt than a third-party app because they are already in the tool.
What none of them does is let you check an arbitrary condition at an arbitrary transition. Linear ships exactly one instance of that shape — priority, leaving Triage — and does not generalise it. There is no way to name a different field or a different boundary, so there is no native way to express "an issue may not enter Done while its estimate is empty".
That is a design position, not an oversight. A validator in front of every write — the app, the API, the Slack integration, the branch automation — would slow the paths that make Linear feel fast, in service of a policy only some teams want. Linear's own directory carries an Automations category for precisely this: rules that belong beside the tracker rather than inside it.
The near misses are worth knowing, because they are what people try first. A Triage rule can set a priority but cannot require someone to choose one — that is the prioritisation setting's job, and only for priority, only leaving Triage. A form template requires fields at creation, which is the wrong moment for an estimate. Both are covered in more detail in required fields for Linear.
This is the genuinely interesting question now that Loops exist, and the answer is not that one is better.
A Loop reasons. You describe the outcome, and an agent works out the next best action from the state of the workspace. That flexibility is exactly right for work where the correct action depends on context nobody can enumerate in advance — chasing a stalled project, drafting a follow-up from a meeting note, keeping a document current.
A rule evaluates. It has a trigger, conditions and actions, and it does the same thing every time. That rigidity is the feature when the requirement is a constraint rather than a task: you want the four-hundredth issue checked identically to the first, at no marginal cost per check, with a record of every evaluation you can point at in a review. You would not want a model deciding, case by case, whether this particular issue really needed an estimate — the whole value of the constraint is that it does not negotiate.
Cost follows the same line. Loop runs consume AI credits; a deterministic rule evaluation does not, which matters when the thing you are checking happens on every issue change all day.
One shape, and deliberately only one: when an issue crosses a boundary you name, if the conditions you set are not met, then put it back and comment saying what was missing — and record the evaluation either way.
It sits after Linear rather than in front of it. Linear delivers a change once it has been committed, so LineGuard corrects rather than prevents: the invalid state is briefly real, and then it is not. The trade is coverage — because it acts on the change itself, it applies to every path that produced it, including the merge automation above, which is the path most likely to move an issue to Done with nothing filled in.
It does not route, does not run on a schedule, and does not reason. For those, use the things above.
Set up the native automations first — they are free with your plan and they solve the more common problems. If, after that, the thing still bothering you is that the board says work is finished when it plainly is not, that is the boundary check, and one rule will tell you how often it happens.
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 · Triage rules in Linear · Enforcing a definition of done in Linear