Why Does a Linear Customer Request Only Show a Quote, Not the Full Thread?

Because that's what the integration is built to capture. When a customer request gets created from a linked Intercom or Zendesk conversation, Linear's own docs say it "will quote the original message from the user," and the integration pages for Intercom and Zendesk each confirm the same scope. You'll see "the initial Intercom message" or "the initial message in Zendesk" for any linked conversation, not everything said afterward.

The request isn't a mirror of the conversation. It's a pointer to it. Alongside the quoted line, Linear attaches a link back to the source, the requester's name, and a timestamp, and the request itself can be edited afterward to add images, video, or extra context by hand. The full back-and-forth, the replies, the clarifying questions, the moment the customer mentions a second symptom, stays in Intercom or Zendesk. Reaching it means clicking through, every time.

What actually gets captured, and what doesn't

Break the request down into its parts and the design makes more sense:

• The opening line, quoted verbatim. Whatever the customer wrote in the message that triggered the request becomes the quote. If that message was the whole ask ("can we get SSO before our renewal"), the quote carries the full context. If it was one line in a longer back-and-forth, the quote carries one line.
• A link to the source conversation. This is the one field that scales with the conversation. It doesn't matter how long the Intercom thread gets after the request is created, the link still points at it.
• The requester and a timestamp. Enough to know who asked and when, without opening anything.
• An editable body. Someone can paste in the rest of the relevant context by hand. Nothing does this automatically once the request exists.

None of this updates live. A request created from message one of a conversation doesn't grow a second quote when message six changes the story. It's a snapshot, not a subscription. What crosses over is the opening line and a link, and everything the customer says after that stays on the Intercom or Zendesk side until someone reads it and brings it across by hand.

Getting back to the full thread

The fix is built into the request, it's just a click most people skip. Every request created from an integration carries that link to the source conversation. Open it, and you're reading the same Intercom or Zendesk thread the customer actually had, replies and all.

Two habits make this less of a tax:

• Read the source before acting on the request, not just the quote. Treat the quote as a headline, not the article. If the request is more than a day or two old, assume something has been added to the conversation since.
• Paste forward anything load-bearing. If a later reply changes the ask (narrows it, adds a workaround, mentions a deadline), add it to the request body directly. That's what the editable field is for, and it's the only way the extra context survives if the issue gets referenced later without anyone reopening the original thread.

Neither habit is automatic. Both depend on someone remembering to do them, which is exactly where this breaks down at any real volume.

One thread, watched from both sides

Picture a support agent linking an Intercom conversation to a new Linear issue right after the customer's opening message, a report that a PDF export is missing the signature block on page two. The request quotes that line, and it's accurate. It's also the only thing anyone looks at again, because the request card is what shows up when the agent checks status later.

The conversation keeps going, though, on the Intercom side, where nobody on engineering is reading it. A couple of days later the customer narrows the ask, saying it's not every export, only the ones generated after a document gets re-signed. The next message adds a deadline, a compliance date later that week that forces a manual fallback if the fix doesn't land in time.

Neither update reaches the Linear request. The engineer who eventually picks up the issue reads "missing signature block, page two," loses most of a day trying to reproduce it on a plain export, and only finds the re-sign condition by digging back through the file the customer originally attached. The deadline never reaches anyone on the engineering side at all. It's sitting in the Intercom thread, one click from the request, and nobody clicked.

Three reasons this breaks down at volume

The design trades a full copy of the conversation for a lightweight pointer to it, and it doesn't hide that. It holds up fine at low volume, where one person can hold "check the source" as a personal habit. It stops holding up for three predictable reasons:

• Nothing flags that the source has changed. A request created from message one of a conversation looks exactly the same whether the conversation ended there or grew to fifteen messages with a deadline attached. There's no unread indicator, no "3 new replies" badge on the request card.
• Pasting context forward is a manual, one-off act. Someone has to notice the new information, judge it worth adding, and edit the request. At a handful of requests a week that's plausible. Past a few dozen, some of it gets missed every time, and there's no way to tell which requests are missing something without opening every linked conversation to check.
• The habit doesn't survive a handoff. The agent who created the request knows to check the thread. The engineer who picks up the issue three days later, with no relationship to the original conversation, has no reason to suspect the quote is incomplete unless someone tells them.

Between the quote and the thread is where Modem sits. It reads Intercom and Zendesk conversations continuously through the Linear integration, not just at the moment someone links one, so a follow-up message that changes the ask or adds a deadline gets folded into the same tracked topic instead of sitting unread in a thread nobody revisits. When it files or updates the Linear issue, the customer's full context travels with it, not just the line that happened to be typed first. Modem is the company writing this, so weigh it against the cheaper option before reaching for it. A team norm of re-checking the source thread before triage, and again before calling an issue done, closes most of this gap for free. Modem starts doing work a person cannot once that norm reliably fails to hold, which for most teams is a question of request volume, not discipline. The wider mechanics of the feature this sits inside are covered in the complete guide to Linear customer requests, and what you can attach to a request once you're in there is covered in how to add custom fields to a Linear customer request.

A fifteen-second fix for triage

Add one line to your triage checklist. Before assigning a request-linked issue, open the source conversation and confirm the quote still matches the latest message. It takes fifteen seconds per issue, and it would have caught both the narrowed scope and the deadline in the example above on the first read.