Does Linear Customer Requests Support Discord or Microsoft Teams?
No, not directly. Linear's Customer Requests documentation names exactly six ways a request gets created and attached to an issue: Intercom, Zendesk, Front, Salesforce, Slack, and Linear's own Asks feature. Discord and Microsoft Teams are absent from that list, and nothing in Linear's docs suggests either one is coming.
That's not the same as saying Linear ignores the two platforms entirely. Discord has its own official Linear integration, just not one wired into Customer Requests. Microsoft Teams has no Linear integration at all, official or otherwise. The rest of this walks through what each channel actually gets, why the gap exists, and what closes it once volume outgrows a person copying names by hand.
The six sources Customer Requests actually watches
A Linear "customer" is an organization record with a domain, a tier, and optional revenue; a "request" is one piece of feedback tied to that customer, holding the original message and a link back to where it came from. Per Linear's docs, requests get created automatically in a specific set of ways:
- Intercom: synced live when you create or link an issue from an Intercom conversation.
- Zendesk and Front: created when you create or link an issue from a conversation in either tool.
- Salesforce: created from a case, on Enterprise plans.
- Slack: optional, when you create an issue from the Slack integration and choose to attach a customer.
- Linear Asks: automatic, any time an Ask turns into an issue.
Six named integrations, and every one of them is a support tool, a CRM, or Linear's own feature. Discord and Microsoft Teams don't belong to either category from Linear's point of view, and neither shows up anywhere in that list.
Discord creates issues, not customer requests
Linear does ship an official Discord integration, listed under Collaboration in Linear's integrations directory. Per Linear's Discord docs, a workspace admin turns it on, then each teammate links their own Discord account to their own Linear seat. Once linked, that person can run /linear issue in any channel to file an issue with a title, team, and optional description, status, assignee, and project. Two sibling commands round it out: /linear search searches Linear issues on the workspace by issue ID, title, description, or comments, and /linear wrap posts a daily summary of what someone worked on. A Discord message can also be attached to an existing issue afterward through a link action.
None of that touches Customer Requests. The issue Discord creates carries whoever ran the command as its creator, not whoever reported the bug, and nothing in the docs describes the resulting issue picking up a structured requester the way an Intercom-sourced issue does. A community member without a linked Linear seat can't file anything themselves, and their identity survives only if someone manually types it into the description.
Microsoft Teams has no integration at all
Teams doesn't even get the partial coverage Discord does. Linear's integrations directory lists integrations across twelve categories, from Engineering to Security & Compliance to Collaboration, and Microsoft Teams isn't in any of them. There's no /linear slash command for Teams, no official connector, and no mention of Teams anywhere in Linear's Customer Requests or Triage documentation. Anything that moves a Teams message into Linear has to go around the product entirely, usually through Linear's GraphQL API called from Power Automate or a small script, authenticated with a personal API key or OAuth2. That path can create an issue. It has no concept of a customer request to attach it to.
What that gap looked like at Sumpter Data
Sumpter Data runs a webhook-delivery API and sells a hosted plan to companies that need reliable retries and delivery logs. Reza Amini leads support and developer relations there, split between a two-thousand-member public Discord for self-serve developers and a Teams Connect channel with the company's largest account.
A Discord user posting as latency_gremlin asked in #feature-requests whether delivery logs older than seven days could be exported as CSV instead of expiring. Reza ran /linear issue himself, since latency_gremlin had no linked Linear seat, and typed "requested by latency_gremlin in #feature-requests" into the description by hand.
Eleven days later, a data engineer at Larkfield Beverages, one of Sumpter's enterprise accounts, raised almost the identical request in the Teams channel, on behalf of a compliance team that wanted delivery logs retained past the seven-day window and exportable before they aged out. Reza told them he'd get it logged and would check whether it had come up before.
Nothing in Linear connected the two. Reza's search turned up the Discord-sourced issue only because he happened to remember roughly how he'd worded its title eleven days earlier, and Larkfield's name existed nowhere on that issue until he added a comment by hand. If he'd been out that week, the two reports would likely have become two separate issues, each with one requester nobody could search for later.
Where the manual fix stops holding up
Typing a requester's name into a description or a follow-up comment works as long as one person is reading every channel and remembers to do it every time. That's the whole mechanism, and it has two predictable failure points. First, it depends entirely on a human noticing the connection between two differently worded reports; Reza catching "export delivery logs" and "retained past your 7-day window" as the same ask was closer to luck than process. Second, even when he does catch it, the record he produces is a sentence sitting inside an issue description, not a field Linear can query, so answering "which accounts asked for CSV export" later still means opening every candidate issue and reading it.
Two channels is already enough for that math to go bad. Once a support lead is splitting attention across a Discord server and a Teams channel instead of just one, both failure points above stop being occasional and start being the default state, and the fix has to be something other than asking one person to read more carefully.
Turning both channels into requests Linear can see
That's the category Modem works in. Modem's Discord integration and Microsoft Teams integration both subscribe to the channels you choose, capture messages in real time, and classify them regardless of who's linked to what account. A report phrased as "export logs before they expire" and one phrased as "retain past your 7-day window" get clustered into the same topic with every person who raised it attached as a real identity, not a name typed into a comment. When a topic is ready to become tracked work, Modem's Linear integration files or updates the issue directly, with the quotes and the requester list already on it. That's also a plain description of what we sell, so read the comparison above with the same skepticism you'd bring to any vendor explaining why a competitor's gap happens to be the gap it fills. Judged only on cost, the manual approach Reza used is free and holds up fine for as long as one person can keep both channels in their head.
Two related guides go deeper on each half. The Discord side, including exactly where /linear issue runs out of room, gets its own walkthrough in how to route Discord bug reports into Linear without losing the reporter. The Teams side, and what the Power Automate path actually involves, is covered in turning a Microsoft Teams message into a Linear or Jira ticket.
The direct answer again
Customer Requests reads from Intercom, Zendesk, Front, Salesforce, Slack, and Linear Asks, full stop. Discord can create a Linear issue through its own integration, but not a customer request, and the requester's identity only survives if someone types it in by hand. Microsoft Teams has no Linear integration at all, official or community-built, so anything that reaches Linear from a Teams message goes through the API directly, with the same manual attribution problem waiting on the other end. Neither gap is a bug in Linear. Both channels sit outside what Customer Requests was built to watch, and closing that gap is a job for whatever sits in front of Linear, not a setting inside it.
