A customer asks you what's shipping this week. The answer lives in Linear, assigned and tied to a cycle. You do not want to paste a status update into Slack again, and you do not want to hand the customer a Linear seat that opens your whole workspace. So what do you actually do? The honest answer depends on the shape of your situation, not on which tool is "best."
TL;DR
Three shapes of "sharing Linear with customers" exist. Each has a different right answer.
- One sensitive issue, one external person, short-lived access. Use Linear's February 2026 private-team issue sharing on Enterprise. Per-issue, no portal, no branding. Right for security reviews, sensitive bug investigations, contractor handoffs.
- Ongoing per-customer project visibility. Use a dedicated portal product. Each customer logs in to a branded view filtered to their work; your workspace stays private. Right for agencies and B2B SaaS with multiple paying customers.
- Customer-side request submission with reply threading. Use a support tool integrated with Linear (Pylon, Front, Productlane, Intercom) for ticket-shape conversations, or use a portal product with an issue-request module if requests live alongside project status.
Anti-patterns to avoid: guest seats as the default for clients (they open the whole workspace, no read-only mode, per-seat cost spirals), Notion mirrors (drift within hours), Slack recaps (you become a human status bot).
Who this post is for
This post assumes you already run work in Linear and want to expose some of it to paying customers, named clients, or specific external stakeholders. If you do not use Linear yet, that decision is upstream of this article. If your audience is the open internet (a community, prospects, transparent product roadmap for everyone), the public roadmap guide covers that shape with a different set of trade-offs.
The three shapes below cover the agency, the B2B SaaS company, the technical consultancy, the dev team sharing with named accounts. They map cleanly to the situations Helium's paying customers describe, and to what Linear's native sharing actually addresses.
Shape 1: One sensitive issue, one external person, short-lived
This is the simplest case and the one Linear has actually solved.
Situation: a contractor needs to see a single bug to triage it. A security researcher needs visibility into one issue. A client's CTO wants to look at one specific ticket without seeing the rest of the project.
What changed in February 2026: Linear added private-team issue sharing on Enterprise plans. You share a single issue from a private team with a specific external user. They view it on a linear.app subdomain. They still need a Linear account, the access is per-issue rather than scoped to a project, and the view is unbranded.
When this is the right call: when "one issue" is genuinely the unit of work being shared. The access is short-lived. The audience is one named person. Branding does not matter (or actively shouldn't apply, as with security review threads). You are on Enterprise already, or one issue is a small enough share that paying for it is irrelevant.
When this is the wrong call: when "one issue" is really shorthand for "let my customer see the whole project." Sharing 30 individual issues with one client this way is operationally painful, the customer ends up with 30 bookmarks, and every new ticket requires another share action. The shape of the job is recurring per-customer visibility, not one-off sharing, and the tool here does not fit.
A screenshot or a public link works too if the issue is genuinely low-sensitivity and you do not need access to be revocable. Helium Rooms is overkill for a one-off share.
Shape 2: Ongoing per-customer project visibility
This is the case agencies and B2B SaaS companies actually face, and the one Linear does not natively address.
Situation: you have multiple customers. Each one wants to see their own project: what's in progress, what shipped this week, what's queued, who's on it. The visibility is recurring, not one-off. Each customer should see their own work, not yours, not other customers'. You want it to look like part of your service, not a third-party tool you're making them log into.
Why native sharing does not cover this: private-team issue sharing is per-issue. Customer Requests is a team-side tracker, not a customer-facing portal (the customer reports through Intercom or Front; the team triages in Linear; the customer never gets a portal page). Guest seats give clients full team write access, no per-project filtering, no branding, and cost per seat per month. Linear has actively chosen not to ship this surface: linear/linear#653 requesting public link sharing was filed externally and closed without action.
What fits the shape: a dedicated portal product that takes Linear data and renders it as a per-customer view. The customer logs in (or hits a shareable link), sees a branded portal filtered to their projects, teams, or labels, and never touches Linear. Your workspace stays private.
Helium Rooms (full disclosure: this is our product) ships this shape: per-customer rooms on your subdomain or custom domain, scoped to the Linear projects you choose, with issues syncing via webhook so the room reflects Linear state in near real time. There's a free tier to test the shape against your workflow. Helium is an official Linear integration.
SteelSync and Lindie cover the same shape but have both shown roughly a year without visible shipping activity and run fixed display layouts; the public roadmap guide has the current state of each. Verify on steelsync.io and lindie.app before betting a customer-facing surface on them.
When this is the wrong call: when you have one customer and one project, and the friction of setting up a portal product is genuinely larger than the friction of a weekly Slack update. At that scale, manual works (briefly). The break point is around three customers.
Shape 3: Customer-side request submission with reply threading
This is the support-and-ticketing shape, sometimes confused with Shape 2.
Situation: customers file requests, the team triages them, status updates flow back into the customer's conversation thread. The unit of communication is the ticket reply, not the project dashboard. Customers want to know "what's happening with the bug I reported," not "what is your team building this month."
What fits the shape: a support tool integrated with Linear. Pylon, Front, Productlane, and Intercom all pull Linear issue state into the customer's existing reply thread. The customer sees status updates inside the same ticket they opened. The team works in Linear. Productlane specifically positions as a support portal built around Linear; the others position as inbox-shaped tools that happen to integrate.
Linear's own Customer Requests feature sits underneath these integrations: a request comes in from the support tool, attaches to the Linear issue, and gives the team a per-customer view inside Linear. Note: Customer Requests is team-side. The customer-facing surface is whatever the support tool renders (Intercom message, Front conversation, Pylon thread).
When portal products fit this shape better: if requests need to live alongside project visibility ("here is what's shipping for you, and here is the request you filed last week, and here are the three open ones"), a portal with an issue-request module fits the shape better than a support-tool integration. Helium Rooms includes an IssueRequestModule that writes back to Linear Customer Requests, so customer-side request submission happens inside the same portal that shows project status. This collapses two surfaces (support tool + manual project recap) into one.
The decision between integration-shaped and portal-shaped is about where the conversation is anchored. Anchored on support tickets: use the integration. Anchored on project visibility: use the portal.
Anti-patterns to avoid
Guest seats as the default for clients, Notion or Trello mirrors of your Linear board, and weekly Slack recaps are the three patterns that recur when teams pick the wrong shape because the tool was already there. None scale past two or three customers. The hidden cost of guest seats post covers the math and the structural reasons each one breaks.
Decision framework (by scenario)
- You are sharing one sensitive issue with one external person occasionally: Linear's private-team issue sharing on Enterprise. If you are not on Enterprise and the issue is low-sensitivity, a screenshot or public link.
- You have multiple paying customers each needing recurring project visibility: Helium Rooms is the path we ship for this shape. SteelSync is the older alternative if you want a more established (if quieter) product. Don't reach for guest seats, mirrors, or recaps; they fail at scale by design.
- Your customer interaction is anchored on support tickets with reply threading: A support tool integration (Pylon, Front, Productlane, Intercom). Linear Customer Requests is the team-side tracker that sits underneath.
- Your customers need to see project status AND submit new requests in one place: Helium Rooms covers this with the IssueRequestModule writing back to Linear Customer Requests.
- You want a single public page for everyone (community, prospects, product transparency): That is a public roadmap problem, not a per-customer sharing problem. Different shape, different post.
- You have very specific design requirements no off-the-shelf tool covers, and engineering bandwidth to spare: Linear's GraphQL API. Budget weeks and ongoing maintenance for OAuth, sync, filtering, and a UI worth showing to a customer.
FAQ
Can you share a single Linear issue with a customer in 2026?
Yes, on Enterprise. Linear's February 2026 changelog added private-team issue sharing: you share one issue from a private team with one specific external user. The receiver still needs a Linear account, the access is per-issue rather than scoped to a project, and the view is unbranded Linear UI on a linear.app subdomain. It is a good fit for one-off sensitive cases (security, HR, a single bug review) where the audience is one named person.
For sharing without a Linear account, without per-seat fees, and across many issues per customer, the situation is Shape 2 above (ongoing per-customer project visibility), and a dedicated Linear-portal tool fits the shape better than native sharing. The customer logs in to your branded surface, sees their work, and never touches Linear. Helium Rooms, SteelSync, and Lindie all cover this shape with different cadences and design quality. Helium is the actively-shipping option today.
What's the difference between Linear Customer Requests and a customer portal?
Customer Requests is a team-side tracker that points inward. When a customer reports an issue through Intercom, Front, Slack, or Linear Asks, a request gets created and attached to the underlying Linear issue. The team uses it to prioritize what to ship by customer attributes. The customer does not get a portal page; they see status updates inside whatever support tool collected the request.
A customer portal points outward. The customer logs in (or opens a public link), sees their own scoped project view, checks status on their issues, and submits new requests directly. The team works in Linear; the customer sees Linear data through a branded, filtered surface they understand. The two are complementary. Customer Requests handles intake and prioritization on the team side. A customer portal handles visibility and status on the customer side. Helium Rooms ships the customer-side surface and links request submissions back to Linear Customer Requests.
Do customer support integrations (Pylon, Front, Productlane) work for project status?
For support ticket status, yes. These tools pull Linear issue state into the customer's existing reply thread, so when a bug is fixed or a feature ships, the customer hears about it inside the ticket they already opened. The integration is tight and the workflow is familiar to customers who already use the support tool.
For broader project status, they are weaker. A customer who wants to see what their agency is working on this month needs a scoped project view, not a stream of resolved tickets. The integration paths render single tickets and conversation threads, not project-level dashboards. If customers regularly ask about ongoing work outside the bug-fix or feature-request shape, that is Shape 2 territory and a portal tool fits the job. If almost all customer conversation is ticket-shaped, support-tool integration is enough.
Will Linear ship a native customer portal?
The long-running linear/linear#653 request for public link sharing was filed externally and closed without action. Linear has shipped customer-facing pieces (Customer Requests, private-team issue sharing on Enterprise, integrations with Intercom and Front and Pylon). None of those is a branded customer-portal product, and none has been announced. The signal from the closed issue and the active investment in integration partners is that Linear has chosen to delegate this surface to its ecosystem rather than build it natively.
Linear's own integration directory lists multiple third-party portal products, which is the second public signal in the same direction. That direction may change, but planning around a native customer portal that does not exist is a bet against the only public signals Linear has given on the question.