Triage new Linear issues

New Linear issues land with mixed priority and little structure. Bugs, questions, and noise sit in the same list until someone sorts them by hand. A bug that never says how to reproduce it waits until a person asks, often days later.

This guide builds a workflow that starts when a Linear issue is created, classifies it, and sets the issue's priority from that result. When the category is technical, it also comments on the issue asking for the steps, what was expected, and what happened. You'll start from a template, test it, and activate it on the team.

The template already uses the Linear Issue created trigger, Update issue, and Add comment. It does not store a Linear account. You choose the account when you activate. Until then the draft saves, and Studio tests simulate the Linear steps.

If the team only gets a handful of issues a week, Linear's own triage, labels, and a short issue template that asks for steps is less machinery than this. The workflow is for the team where new issues sit unsorted until someone has time.

What you'll build

Issue created, Issue text, Support Triage, Linear priority, Update issue, Bug?, and Ask for steps.

The false branch of Bug? goes straight to Output, after the priority is set. A question or a feature request is updated and does not get the comment.

Support Triage does not return a bug, feature request, or how-to label of its own. technical is its bucket for errors, bugs, outages, crashes, slow performance, and integration problems. product covers both how a feature works and a feature request. priority here is the severity this node returns (low, medium, or high). The event's own priority is a different field: Linear's number already on the issue. This template does not read that number. It writes a new one from the lookup.

Build it in the Studio

1Start from the template

Click Use this template above, or open Linear issue triage in Workflows.

The draft opens on the canvas. The components library is on the left. Triggers, AI, Action in an app, data transformation, and flow are the groups. Linear is under Triggers and under Action in an app.

The library home. This draft starts on Linear: Issue created.

Issue created is one Linear trigger, next to the app's other triggers.

Create issue, Update issue, and Add comment sit with the rest of Linear's actions.

The draft is not callable until you publish and activate it. Three Linear connections are still to choose.

2The workflow starts from an issue

Select the input step. It is Linear: Issue created, not an API request. The account line is empty until you connect Linear. Leave it empty while you test.

Team ID shows team_support. No Linear account is selected.

The step is named Issue created. The description on the step says it is triggered when a new issue is created. Team ID (team_id) is required. The template sets it to team_support. That is a stand-in. The trigger's sample event is an issue in that workspace (https://linear.app/acme/issue/SUP-412). Replace the team with yours.

Until an account is connected, Team ID stays closed and shows the stand-in. Connect Linear and, when the account's teams can be read, that field lists them. Picking one fills Team ID. Update issue and Comment do not read this setting. They only need the event's issue_id.

This workflow starts on Issue created. Linear also has Issue updated and Comment added or changed. Those are separate triggers. An update this workflow writes, and a comment it posts, do not start this automation again.

Event fields later steps read:

The event also includes priority, action, data, type, and url. priority on the event is Linear's number (the sample issue uses 2). A manual run or an API call can omit fields. Update issue and Comment need issue_id.

A repeat of the same delivery does not start a second run. The event id is issue_id, so the same issue does not start this workflow twice. A new issue is a new event and runs again.

3Classify the issue

Issue text builds the message Support Triage reads. A Linear issue has a title, and subject is optional on this node, so the template leaves it unmapped. A title can also be longer than the 200 characters subject allows, and the title field on the event allows 8,000.

{{input.title}}

{{input.description}}

Select Support Triage. message is mapped from that text.

message comes from Issue text. subject is not mapped.

The node decides on fixed, published rules:

• category is billing, technical, account, product, or other. technical is its bucket for errors, bugs, outages, crashes, slow performance, and integration problems. product covers both how a feature works and a feature request.
• priority is low for a question or feedback, medium when the customer has a problem but can keep working, and high when they're blocked right now. A message the node treats as a security problem is high.
• requires_human_review is true when a legal threat or a security problem is reasonably possible, or when the category or priority itself is unclear.

message is required and accepts at most 8,000 characters. Issue text is the title, a blank line, and the description, and each of those event fields also allows 8,000, so the two together can be too long for this step. Shorten the template if you see that. If the title and the description are both empty, the text is blank and this step fails. A title with an empty description still classifies.

4Set the priority the triage result warrants

Select Linear priority. It is a Lookup. It reads nodes.triage.output.priority. When that value equals a row's match, the result is that row's result. The result is a number, which is what Update issue's Priority field asks for.

Update issue describes its Priority as 0 (No), 1 (Urgent), 2 (High), 3 (Normal), and 4 (Low). The template maps the three triage words onto High, Normal, and Low, and leaves Urgent unused:

high maps to 2. The fallback is 0.

2, 3, 4, and 0 are stand-ins. Change them to the numbers your team uses. Keep each result a number. Typing 2 stores the number. Typing the word high stores text, and Priority expects a number. The fallback 0 is No priority, used only when the triage priority is none of the three words.

Update issue is Linear's Update issue action. It is on the path after Linear priority, and before Bug?, so every new issue gets a priority, including the ones that are not bugs.

Issue ID is the event's issue_id. Priority is the lookup's number. Title, description, State ID, Assignee ID, and Label IDs stay unmapped, so this step does not change them. State ID is how you would set a status, and it has to be a state UUID from your team. The template leaves it empty rather than invent one.

Issue ID is input.issue_id. Priority comes from Linear priority. If it fails, the run stops. No Linear account is selected.

If it fails is Stop the run. If the priority can't be set, the run fails and the comment does not run. Update issue is safe to retry: Kovca retries it if Linear is briefly unavailable. Choose the Linear account on this step before you activate. Studio tests simulate it and do not change the issue.

5Ask for steps when it is a bug

Select Bug?. One rule: nodes.triage.output.category equals technical.

category equals technical. The true branch posts the comment. The false branch goes to the result.

The true branch is every issue Support Triage calls technical, including one that already lists steps, and including one where requires_human_review is true. The template does not read the description for the words "steps" or "expected". If you only want the comment in some of those cases, change the rule.

Ask for steps is the comment.

Thanks for opening {{input.identifier}} ({{input.title}}). To look into this we still need the steps you took, what you expected to happen, and what happened instead. Reply on this issue with those three.

Comment is Linear's Add comment action.

The body is plain text or Markdown, and it has to be non-empty. This template's text is well under the 8,000 characters the field allows. The step posts on the issue from Issue created.

Issue ID is input.issue_id. Body comes from Ask for steps. If it fails, the run continues.

If it fails is Continue (output.ok is false). If the comment does not post, the priority is already set and the run still succeeds, with commented false. Add comment is sent once: Kovca does not retry it on its own. Choose the same Linear account. Studio tests simulate it and do not post.

6Test it

Open the Test tab. The template's examples are listed above the input. Leave Send real requests off: Update issue and Comment return their samples. Nothing is posted to Linear.

Run Cart total when you want an issue about a missing shipping fee, and How-to question when you want a shorter one. What Support Triage returns depends on the issue. A technical category takes Comment. Any other category takes Output after Update issue, and Ask for steps and Comment are skipped. Both paths set the priority.

Before you activate, run a stack of real issues from the team, including a few bugs and a few that should only have had their priority set. When the routes look right, turn on Send real requests once, with the Linear account chosen, to check those calls.

Publish, call it, and activate it

The same workflow can be called over the API. The body uses the trigger's field names. Create an API key under API keys and keep it on your backend.

curl https://kovca.io/api/v1/workflows/wf_.../execute \
  -H "Authorization: Bearer $KOVCA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 5b1c2d3e-4f5a-6b7c-8d9e-0f1a2b3c4d5e" \
  -d '{
    "input": {
      "issue_id": "5b1c2d3e-4f5a-6b7c-8d9e-0f1a2b3c4d5e",
      "identifier": "SUP-412",
      "title": "Cart total missing shipping for CA orders",
      "description": "Customers shipping to Canada see a cart total without the shipping fee.",
      "priority": 2,
      "action": "create",
      "data": {},
      "type": "Issue",
      "url": "https://linear.app/acme/issue/SUP-412"
    }
  }'

A run that classifies that issue as technical and medium takes the comment path. The fields below are that shape. Linear's medium row is 3 (Normal). Update issue and Comment return their samples, so updated and commented are true. The comment is Ask for steps filled in from that input. What the node returns for a given issue depends on the text, so run your own examples before you treat a route as settled.

{
  "request_id": "req_...",
  "run_id": "run_...",
  "workflow": { "id": "wf_...", "version": 1 },
  "status": "succeeded",
  "output": {
    "category": "technical",
    "priority": "medium",
    "requires_human_review": false,
    "linear_priority": 3,
    "updated": true,
    "comment": "Thanks for opening SUP-412 (Cart total missing shipping for CA orders). To look into this we still need the steps you took, what you expected to happen, and what happened instead. Reply on this issue with those three.",
    "commented": true
  },
  "steps": [
    { "id": "input", "status": "succeeded" },
    { "id": "body", "status": "succeeded" },
    { "id": "triage", "status": "succeeded" },
    { "id": "rank", "status": "succeeded" },
    { "id": "update", "status": "succeeded" },
    { "id": "bug", "status": "succeeded" },
    { "id": "ask", "status": "succeeded" },
    { "id": "comment", "status": "succeeded" },
    { "id": "output", "status": "succeeded" }
  ],
  "evaluations": 1
}

Use the issue id as the Idempotency-Key. A retry returns the original run instead of updating and commenting again. Kovca does not store the issue or the output, so keep the response from the first call. Values from steps that didn't run come back as null. On an issue Support Triage does not call technical, comment and commented are null. updated is still true, because the priority was set.

To run it from the team, open Activate. The checklist is what's left: connect Linear, choose that account on the trigger, on Update issue, and on Comment, and replace team_support. Publish & activate publishes the draft and starts it. The checklist's activate row runs on every issue created. A live automation runs that pinned version. Later edits don't reach it until you choose Publish & update.

Connect Linear is still to do. The panel shows up to 19 credits per event.

You sign in on Linear's page. The sign-in page names Composio, which holds the account access and uses it only for Linear. Kovca keeps an ID for the account. Don't connect an account until the routes look right in the Test tab.

A new issue on the team starts a run. Follow runs in Executions. While an automation is paused, events that arrive are skipped. A failed run is not retried on its own, because the priority or the comment may already have happened.

If the team is quiet

You don't need this if a person can read new issues, and the list is short. Linear can keep a triage view, labels can mark the kind of issue, and a short issue template can ask for steps before the issue is created. That's a fair setup for a few issues a week.

What the workflow adds is the same classification on every new issue, a priority taken from that result, and a comment asking for steps when the category is technical. You still have to replace the stand-in team, choose the Linear account, and read a sample of results before you activate it.

Make it yours

• Skip the comment when a person should review it. Add nodes.triage.output.requires_human_review is false on Bug?, and leave Match on all. A technical issue that needs a person is updated and not commented on.
• Use your priority numbers. Linear priority's results are numbers. 2 is a stand-in for High. Move high to 1 if blocked work should be Urgent.
• Set a status too. Map Update issue's State ID to a state UUID from your team. Leave it empty if priority is the only change you want.
• Leave low-priority issues alone. Put Update issue on a condition that matches high and medium only, if a question should keep the priority it was created with.
• Ask on another category too. Bug? only matches technical. product is both a how-to and a feature request, so it is updated and not commented on until you add a case of your own.
• Roll it out on a copy of the team. Point Team ID at a test team for a week and compare the priorities with what the team would have set.
• Change it without surprising a live team. Edit the draft and use Publish & update. The running version stays pinned until you do.

What it costs

Credits, and only for steps that succeed. Studio tests are free, and simulated actions are free.

• The run: 10 credits when a Linear event starts it, 1 credit when the API starts it.
• Support Triage: 5 credits.
• Update issue: 2 credits when it runs for real.
• Add comment: 2 credits when it runs for real, and only on the technical branch.

The text steps, the lookup, and the condition are free. A branch that doesn't run isn't charged. The Activate panel adds every step together, including steps on branches that can't run in the same event, so its number is an upper bound. With this template that upper bound is 19 credits per event. The response's credits field is the run's total. See billing, the workflows API, HTTP actions, and automations.