Linear integration
The bug report arrives in email. The issue belongs in Linear.
Most bugs are reported by someone who has never seen your tracker. They email support, or mention it in Slack, and somebody has to notice and retype it. this+that reads the message, works out that it is a bug, and a workflow files it in Linear with the original thread attached.
Linear's own MCP server
Linear publishes an official MCP server, and this+that connects to it as a built-in. You authorize with your Linear account, and your workflows can then use it as an action step. Linear documents the server as having tools for finding, creating and updating objects in Linear such as issues, projects and comments, with more on the way, so what a workflow can do grows as Linear extends it.
Workflows that reach into Linear
Describe it in plain language. The trigger is usually a message rather than something happening inside Linear.
"When a support email describes a bug, create a Linear issue and link back to the thread"
The person who reported it never sees Linear, and nobody has to translate their email into a ticket. The original conversation stays attached to the issue.
"If a customer follows up on a bug they reported, comment on the matching Linear issue"
The second email does not become a duplicate ticket. It lands on the issue the engineer is already looking at.
"When an issue is marked done, draft a reply to whoever reported it"
Closes the loop back to the person who raised it, which is the step that usually gets skipped because it lives outside the tracker.
"Every Monday, summarize what came in last week that has not been triaged"
Reported work that never made it into a project surfaces on its own rather than at the next planning meeting.
Two trackers, one on purpose
Linear stays the engineering tracker
We are not asking you to move your engineering work into DoBox. Linear is better at it, and your team already lives there. What this+that adds is the path from an incoming message into Linear.
DoBox holds what does not belong in Linear
The customer waiting on an answer, the follow-up somebody promised, the invoice question. Those are tasks too, and they are not engineering issues.
The source stays attached
An issue filed from an email keeps the thread, so the engineer picking it up can read what the customer actually said rather than a summary.
The reply is part of the work
A workflow can answer the reporter when the issue closes, so shipping a fix and telling the customer are one loop rather than two.
Linear alongside the channels the reports arrive on
A bug can arrive by email, in Slack, on WhatsApp Business, or from a teammate. All of those are read the same way, so the workflow that files the issue does not care which one it came from. Our own bug pipeline runs this way.
Stop retyping bug reports into Linear
Connect Linear and a workflow can file the issue the moment the report arrives, with the conversation attached and the reporter answered when it ships.
Free during beta · No credit card required