Required fields for Linear

The short version. Linear can require fields when an issue is created through a form template, and it can act on issues arriving in Triage. It does not gate a status change on whether a field is filled — the write path stays open by design. LineGuard adds that one thing: a rule that watches for a transition, checks the fields you care about, and reverts the issue with a comment explaining what was missing. Then it logs it.

What Linear enforces today

More than most people assume, and it is worth knowing before you install anything. As of August 2026:

• Form templates can require fields. Linear's documentation is explicit that any field can be required in a form template, and that when a form uses required fields Linear follows up to collect anything missing before the issue is created. The property fields a form can require are customer, label group, priority, title and due date. Standard (non-form) templates do not support required fields.
• Triage rules can act on arriving issues. On Business and Enterprise plans, Triage rules run when issues enter Triage, filter on issue properties, and can set an issue's team, status, assignee, label, project and priority. Rules run top-down and a routed issue picks up the receiving team's rules.
• Loops can run recurring work. Introduced in July 2026, a Loop is described in plain language and runs on a schedule or in response to an event, with Linear Agent deciding the next best action from workspace context. Business and Enterprise, and runs consume AI credits.
• Statuses are fully yours. You define the statuses per team, order them within categories, set the default, and enable auto-close and auto-archive.

If a form at the front door is what you need, you do not need us — use a form template. That is the honest answer to a good part of the searches that land here.

The part that is left to integrations

What none of the above does is make a field required in order to change status. Linear's status configuration has no notion of a disallowed transition or a precondition on one, and the docs describe no field validation on a status change. That is a deliberate design position rather than an omission: Linear optimises for typing fast and moving on, and putting a validator in front of every write — the app, the API, the Slack integration, the branch automation — would slow the paths people value most. Linear's own directory carries an Automations category for exactly this reason: policy that only some teams want belongs beside the tracker, not inside it.

Two near misses are worth naming, because they are the things people try first:

• Triage rules set values; they do not require them. A rule can assign a priority to an arriving issue. It cannot decline to let the issue leave Triage until a human has chosen one — and a default priority nobody chose is the thing that made the field meaningless in the first place.
• Loops trigger on events, but they reason rather than enforce. An agent deciding the next best action from plain-language instructions is the right tool for follow-ups and delegation. For a constraint you want applied identically on the four-hundredth issue as on the first, at no marginal cost per check, you want a rule that evaluates rather than a model that considers.

Why creation is a different question

Requiredness is not really a property of a field — it is a property of a field at a moment. An estimate matters when work is finishing; a priority matters when the issue leaves Triage; an assignee matters when it enters In Progress. Ask for all of them at creation and people either type something to get past the form or file the thought somewhere else entirely. We wrote the longer argument in required fields are the smallest part of workflow hygiene.

This is why LineGuard attaches requirements to transitions rather than to fields, and why it is a complement to form templates rather than a replacement for them. A form is the right tool for intake. A rule is the right tool for a boundary.

What LineGuard adds

One shape, applied to the fields Linear already has:

When an issue enters or leaves a status (or a specific field changes), if the fields you name are empty — or match some other condition you set — then put the issue back and comment on it saying what was missing.

• Fields it can require: estimate, labels, priority and assignee — including whether a label from a particular group is present.
• Triggers: entering a status, leaving a status, a named field changing, issue creation, or any update.
• Conditions: empty, not empty, equals, not equals, contains, one-of — nested with AND and OR.
• What it does: reverts the status (to the previous one, a named one, Triage, or the first backlog status) and posts a comment. The comment template can list the fields that were missing.
• What it records: every evaluation — which rule, which issue, what matched, what it did, whether the action succeeded. The audit log is the point, not a byproduct: a rule firing forty times a week is telling you the process is wrong, and you cannot learn that without the record.

Note that estimate and assignee are two of the four, and neither is in the set a form template can require. That overlap is small on purpose.

Rules teams actually write

• Nothing enters Done without an estimate.
• Nothing leaves Triage without a priority and a label.
• Nothing enters In Progress unassigned.
• Bugs reaching Done need a root-cause label from the cause group.

Each is a trigger, a condition, and a consequence. The consequence is the part that decides whether the rule survives contact with the team: a rule that only reports gets ignored, and a rule that reverts silently is indistinguishable from a bug — which is why the comment matters as much as the revert.

Corrective, not preventive

Worth being direct, because it follows from how Linear's webhooks work: they arrive after a change is committed. LineGuard cannot stop a change from happening. It sees the result and reverses it, usually within a couple of seconds, which means there is a brief window where the invalid state is real.

For workflow hygiene that window is nothing. For anything where a few seconds of wrong state would cause actual harm — a payment approval, an access grant — do not use this, or anything else built on webhooks, as the only safeguard. The upside of correcting rather than preventing is coverage: it applies to every write path, including the ones you forgot existed.

Starting

The free plan runs three rules on one team with seven days of audit history, with no feature gates — every trigger, condition and action is included. It is deliberately enough to answer the only question worth answering first: pick the one constraint your team already agreed to in writing and already fails to follow, turn on that single rule, and watch the log for two weeks. Either it stops firing, or you have learned something a retro would not have told you. Plans and limits.

Add to Linear — free