How to connect Linear to Slack without adding the ceremony back

Linear's notifications are already good. They are targeted, they respect what you are involved in, and the product is designed by people who clearly dislike being interrupted. That changes the question: an integration that forwards Linear events into Slack is adding a second, worse copy of something that already works.

What Linear cannot do is see anything outside itself. It does not know which customers asked for something, it does not know that a support conversation is about the bug in front of you, and it cannot tell the person who reported a problem that it has been fixed. That is the gap worth building into.

What we'll cover

• What Linear's own Slack integration covers
• Designing the action, not the notification
• Building it with CodeWords
• Getting support signal into triage
• Closing the loop when something ships
• Two notification streams is one too many
• Cycle reporting for people outside the team
• Who should be able to file from Slack
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

What Linear's own Slack integration covers

Worth establishing precisely, because it decides what is left to build.

Issue and comment activity posted to channels, configurable per team, with no development.

Link unfurling, so a pasted issue link shows its title and state — small and genuinely useful.

Personal notifications that are already targeted and that most people have tuned to their preference.

That covers the outward direction competently. A second stream duplicating it means everything is seen twice or muted twice, and muted twice is what actually happens.

What it does not cover is the inward direction: a support conversation becoming an issue, with the customer and the account attached, and the person who reported it hearing when it ships. Linear cannot see any of that, and it is where the remaining value is.

Designing the action, not the notification

If the useful direction is inward, then the thing being designed is a Slack action rather than a message format.

Trigger on an explicit action, not on keywords. Keyword detection creates issues nobody meant to create, and a backlog of those is worse than no integration.

Ask for what you need at the point of filing — a short form on the action, collecting the customer and a one-line description — rather than parsing it out of a conversation.

Default the team from the channel the action was used in, so filing takes one decision rather than three.

Show what was created, with a link, in the thread. Silent success is indistinguishable from failure.

Let the filer add the customer count if they know it is a repeat, since they usually do and it is the field that changes prioritisation.

Keep it to one screen. A filing form with eight fields is a form people abandon, and the point of filing from Slack is that it is faster than opening Linear.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which Slack signal creates or updates an issue, and what should come back.
3. Authorize the connection to Linear with an API key scoped to the workspace, and to your Slack workspace.
4. Describe the exceptions: a duplicate of an existing issue, a team that cannot be resolved, a state that does not exist for that team.
5. Point it at a test team before anything reaches the real backlog.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Getting support signal into triage

The core of it, and the details determine whether the backlog improves or fills with noise.

Create into triage, never into a cycle. Triage exists precisely so incoming work is reviewed before it becomes committed, and bypassing it fills a cycle with things nobody chose.

Search before creating. The same problem gets reported repeatedly, and an automation that does not look first is the main source of backlog duplication.

Add to the existing issue instead. When it is a repeat, comment on the issue and increment the count rather than creating a second one.

Attach the conversation. Linear's attachments link an external resource with a title and URL, which is the right home for the support ticket or the Slack thread.

Record which account and which plan, since that is what turns a report into prioritisation input.

Require a person to trigger it. An explicit action on a message is better than keyword detection, which produces issues nobody meant to create.

Closing the loop when something ships

The half that makes support willing to keep filing, and the half nearly everybody skips.

Tell the people who reported it. When the issue closes, the support agents and account owners who filed it should hear, in the channel where they work.

Include what shipped and when, briefly, so the agent can tell the customer without reading a changelog.

Notify internally, not automatically to the customer. An automated "this is fixed" to somebody who reported something subtly different is a poor experience, and the agent knows which situation it is.

Link back to the original conversation, so the agent can pick the thread up rather than searching for it.

Report the loop weekly. How many reported issues shipped is a number support rarely sees and which changes how much effort they put into filing.

Two notification streams is one too many

The specific risk here, since Linear's own integration already exists.

Decide which stream owns which event, and turn the other off for it. Running both for the same events means people see everything twice and mute whichever is noisier.

Let Linear's integration handle issue activity, which it does well, and build only the messages it cannot produce.

Do not mirror personal notifications into a channel. Linear already notifies the right people; a channel copy reaches everybody else as well.

Resist status announcements. State changes are the highest-volume event in any tracker and the least actionable, which is why forwarding them is the fastest route to a muted channel.

Check after a month. Count the messages and ask whether anybody responded to each type. Whatever fails that test should be removed rather than filtered down.

Cycle reporting for people outside the team

The one outward message worth building, because Linear's own views assume you are in Linear.

What was committed, what completed, what carried, in plain language, at the end of each cycle.

Written for somebody who does not open Linear — support, sales, leadership — which means no identifiers and no jargon.

Include what shipped that customers asked for, which connects the cycle to the signal that came in.

Keep it short. Three or four lines and a link. A cycle report that reads like a status document gets skimmed.

Post it at a consistent time, so it becomes something people expect rather than something that arrives.

Who should be able to file from Slack

Worth deciding before you switch it on, because the answer shapes what the backlog looks like in six months.

Support agents, yes. They are closest to the reports, they file with context, and they are the reason this integration exists.

Account managers, yes, with a count. Their reports carry commercial weight that a bug report does not.

Everybody in the company, cautiously. Open filing produces volume and a large share of it is questions rather than issues, which is what triage is for and also what makes triage unmanageable.

Anyone filing should see what happens next, or they stop. A confirmation with the issue link and a note that it will be triaged is the minimum.

Route by where it came from. A report from a support channel and one from a sales channel are different signals and can reasonably go to different teams.

Review the volume after a fortnight. If triage has become a queue nobody clears, the filing route is too wide and narrowing it is better than letting triage rot.

Making it survive

Make it idempotent. Store the source identifier on the issue and check before creating, since Slack actions get repeated.

Look up state and team identifiers at run time, since they differ per team and a hard-coded one works in exactly one place.

Comment rather than edit. An automated comment is visible and does not overwrite anybody's description.

Handle the archived or moved issue as a normal case.

Report the outcome. Issues created, issues updated, and duplicates avoided — the last figure is the one that shows it is behaving.

Limits worth knowing about

The API is GraphQL and complexity is metered, so a deeply nested query is expensive even as a single request.

Workflow states are per team, so anything setting state needs the right identifier for the right team.

Pagination applies, and nested connections paginate independently of their parent.

Webhook delivery is at-least-once, which is why idempotency matters.

The product ships quickly, so an integration written against a field that changes shape will need occasional attention.

What to set up first

Support signal into triage, with a duplicate check and a customer count. It connects the two systems that most need connecting, it needs only create and comment permissions, and the count on an existing issue changes prioritisation conversations in a way that relaying anecdotes never does.

Two habits make the difference. Always search before creating, since an automation that duplicates is worse than no automation at all. And build the close-the-loop half at the same time, because support stops filing when reports disappear and that happens faster than you would expect.

Frequently asked questions

Should I use Linear's own Slack integration?

For posting issue activity to channels, yes — it exists, it works, and it needs no maintenance. Build something custom for the direction Linear cannot handle: signal coming in from support, and telling reporters when something ships.

Where should automatically created issues go?

Triage, always. It exists so work arriving from outside is reviewed before it becomes committed. Creating straight into a cycle is how a cycle fills with things nobody chose.

What should the filing action do if the issue already exists?

Show the existing issue in the thread and offer to add to it instead of creating a second. That single behaviour turns a duplicate-generating route into one that increments a customer count, which is the number product actually wants.

What information does product actually lack?

How many customers asked, which accounts, and on what plans. All of it exists in support and none of it reaches the backlog on its own, which is why prioritisation ends up being decided by whoever argued most recently.

Where should the "it shipped" message go?

To the channel where the person who filed it works, mentioning them. A general release channel does not reach the agent who raised it, and reaching that agent is the entire reason they will file the next one.

Should the filing form ask which team?

Default it from the channel and let the filer override. Filing should take one decision, not three, and a support agent generally does not know which engineering team owns a given area — the channel is a better guess than they are.

How many messages should this produce per week?

Few enough to read. If the channel is getting more than a handful, something is forwarding activity rather than carrying signal, and the honest fix is removing a message type rather than filtering it down.

Should everybody be able to file issues from Slack?

Support and account managers, certainly. Company-wide filing produces volume that turns triage into a queue nobody clears, and a rotting triage is worse than a narrower filing route. Review the volume after a fortnight and narrow it if needed.

What should somebody see after filing?

A confirmation in the thread with the issue link and a note that it will be triaged. Without it people assume nothing happened and either file again or go back to messaging an engineer directly.

Related reading

• Linear and CodeWords
• Connecting Jira to Slack
• CodeWords integrations and templates