If you run support in HubSpot and engineering in Linear, the cheapest first attempt at connecting them is almost always Zapier. Both tools have first-party Zapier connectors, the trigger-and-action model maps cleanly to "create a Linear issue when a HubSpot ticket comes in," and the setup takes well under an hour. For a small team with a handful of bugs a week, it works.
This guide walks through the exact Zaps to build, what each one actually does, the two places the DIY approach quietly breaks down, and the honest version of when Zapier is the right call versus when a purpose-built sync is.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
What a Zapier HubSpot to Linear Integration Actually Does
Zapier connects HubSpot and Linear by listening for events on one side and firing actions on the other. The HubSpot connector exposes triggers like "New ticket," "Ticket property changed," and "Ticket status updated." The Linear connector exposes actions like "Create issue," "Update issue," and "Add comment." Between those two surfaces, you can wire up most of the common support-to-engineering flows.
The thing to be clear about up front is that Zapier gives you the plumbing, not the workflow. There is no single "HubSpot to Linear sync" Zap. There are a set of one-direction Zaps that you compose into a two-way integration, and the composition is your responsibility. That distinction is what determines whether the integration stays healthy or becomes a maintenance project.
For the rest of this guide, "the integration" means three Zaps working together.
Zap 1: ticket to issue
Creates a Linear issue from a new HubSpot ticket and stores the link back on the ticket.Zap 2: status back to HubSpot
Updates the HubSpot ticket when the Linear issue changes status.Zap 3: comment mirroring
Mirrors comments and notes between the two systems.
That is the minimum viable shape. Before you build, confirm you have the pieces each Zap depends on.
Before you start
- A Zapier account on a plan that supports multi-step Zaps if you want filters and field mapping.
- Admin access to connect both the HubSpot and Linear accounts in Zapier.
- A dedicated HubSpot pipeline or stage for engineering escalations, so you are not syncing every inbound ticket.
- A custom HubSpot ticket property to hold the Linear issue URL or ID. Every downstream Zap relies on it.
- An agreed mapping from Linear workflow states to HubSpot pipeline stages.
Zap 1: Create a Linear Issue from a HubSpot Ticket
This is the foundational Zap and the one most teams start with. The trigger is a new HubSpot ticket, optionally filtered to a specific pipeline or stage. The action is "Create Linear Issue" with the ticket data mapped to the Linear fields.
- 1
Set up the trigger
Choose HubSpot as the trigger app. Pick "New Ticket" as the event. Connect your HubSpot account if you have not already. Pick the pipeline that should fire Zaps. For most teams, this is the engineering escalation pipeline, not every inbound ticket.
- 2
Add a filter for severity or ticket type
Add a Filter step that only proceeds if the ticket has a specific severity, label, or property indicating it needs engineering work. Without this filter, every new ticket creates a Linear issue, which is almost never what you want.
- 3
Configure the Linear action
Choose Linear as the action app. Pick "Create Issue" as the event. Map the HubSpot ticket fields to Linear fields. Title from ticket subject. Description from the ticket body. Labels from the HubSpot severity field. Team from a default value or from a HubSpot custom field. Assignee usually stays unassigned at creation.
- 4
Store the Linear issue ID on the HubSpot ticket
After the Linear issue is created, add a final action that writes the Linear issue URL or ID back to a custom property on the HubSpot ticket. This is the link that every other Zap relies on. Without it, you have no way to find the Linear issue from the HubSpot ticket later.
Tested end to end, this Zap should turn a new high-severity HubSpot ticket into a Linear issue within a minute or two, and the HubSpot ticket should carry the Linear issue link as a custom property.
Zap 2: Send Linear Status Changes Back to HubSpot
The second Zap closes the most painful gap in the manual workflow. Without it, the HubSpot ticket sits at its initial status forever while the Linear issue moves through the engineering workflow, and support has no way to know whether the bug has been fixed.
The trigger is "Updated Issue" in Linear, filtered to status changes. The action is "Update Ticket" in HubSpot, scoped to the ticket linked to the issue.
The status mapping is also a small piece of work. Linear has its own workflow states like Backlog, Todo, In Progress, In Review, and Done. HubSpot has its own pipeline stages. You need a mapping that translates one to the other, and the mapping has to be maintained as either side adds new statuses. Most teams handle this with a Formatter step that converts the Linear status to the equivalent HubSpot pipeline stage.
When the Zap fires, the HubSpot ticket should move to the right pipeline stage automatically, and an internal note should be added documenting the status change. The customer-facing reply is still manual, by design. Support gets to decide when the customer hears about it.
Zap 3: Mirror Comments Between Systems
This is the Zap that separates the prototype integrations from the working ones, and the one most teams skip or get wrong. The trigger is "New Comment" on a Linear issue. The action is to add an internal note to the matching HubSpot ticket. The reverse direction, mirroring HubSpot ticket notes into Linear comments, is structurally similar but uses HubSpot's "Engagement Created" trigger instead.
Most teams that build this Zap end up with a "good enough" version that mirrors new comments but does not handle edits, deletes, or attachments perfectly. That is fine for a while. It is the part of the integration that produces the most support-to-engineering friction once volume grows.
What Zapier Cannot Do Without Real Work
The three Zaps above cover the basic loop. A few things Zapier can technically handle require enough engineering time that the "no-code" framing stops being accurate.
Conflict resolution
When both sides update the same field at nearly the same time, Zapier has no built-in arbiter. Teams either pick a side that always wins or live with occasional drift.Backfill
The Zaps only fire on new events, so anything that predates the wiring stays disconnected unless you write a one-shot backfill as a separate set of Zaps or a script.Real-time reliability at volume
Polling-based triggers can take up to fifteen minutes to fire on lower plans. Webhook-based triggers are faster but require more setup and a paid plan.Audit trail and observability
Zapier's task history is useful for one-off debugging and unhelpful for understanding patterns. Knowing how many tickets failed to sync this week usually means layering your own monitoring on top.
None of these are dealbreakers in isolation. Collectively, they are the reason most teams that start with Zapier eventually move to something else.
When Zapier Is the Right Answer
The honest read on Zapier for HubSpot to Linear is that it is the right call in three specific situations.
Zapier fits when
- Escalations are genuinely occasional and support can clean up edge cases
- You need a one-off flow no purpose-built tool covers
- You are still figuring out which fields and events matter
Zapier struggles when
- Twenty or more tickets a week need engineering work
- A missed customer update puts a renewal at risk
- Nobody clearly owns the Zaps when they break
If you are in one of those three fits, build the Zaps and do not overthink it. A month of running on Zapier is a cheap requirements document for whatever you build or buy next.
When to Replace Zapier with a Purpose-Built Sync
The signs that the Zapier integration has outgrown its usefulness are predictable, and they show up in the same order on most teams.
The first sign is that someone on the team spends an hour a week tuning Zaps. Reauthorizing connections, fixing failed runs, adjusting filters that no longer fit, or rebuilding a Zap that someone broke by renaming a HubSpot property. That hour is the integration's true cost, and it does not show up on the Zapier invoice.
The second sign is that the comment mirroring has stopped being trusted. Support reps double-check Linear before replying to a customer because they no longer believe the HubSpot ticket has the latest engineering update. The integration is technically running and effectively not.
The third sign is that a customer-facing miss has been traced back to a missed Zap. A bug was fixed two weeks ago, the customer was never told, and someone has to write the apology email. Once that has happened twice, the case for a purpose-built sync makes itself.
The hour a week you spend nursing three Zaps is the integration's real price, and it never shows up on the invoice.
For HubSpot Service Hub and Linear specifically, IssueLinker is the purpose-built version of what the three Zaps above are trying to do. Ticket-to-issue creation, two-way status sync, and comment mirroring are first-class features, not Zaps you maintain. There is no Zapier task budget, no comment loops to debug, and no rebuilding when HubSpot changes a property name. The full pattern, including the four integration approaches teams consider, is covered in the Linear HubSpot integration guide.
Outgrowing your Zaps?
If your HubSpot to Linear integration runs on three brittle Zaps you keep having to fix, IssueLinker handles the whole flow as a purpose-built sync. Ticket-to-issue creation, two-way status, and comment mirroring, with no Zaps to maintain.
A Quick Decision Framework
If you are still weighing Zapier against a purpose-built tool, the decision usually comes down to three questions.
| Question | Lean Zapier | Lean purpose-built |
|---|---|---|
| Tickets per week needing engineering work | Under five | Twenty or more |
| Cost of a missed customer update | Minor annoyance | Puts a renewal at risk |
| Who owns the Zaps when they break | A dedicated ops engineer | The support lead in spare time |
There is no universally right answer. There is a right answer for your team's volume, your tolerance for misses, and your capacity to maintain the wiring. The post worth reading next, regardless of which way you lean, is the bug tracking template guide, which covers the fields the integration should carry either way.
