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.
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. One creates a Linear issue from a HubSpot ticket. One updates the HubSpot ticket when the Linear issue changes status. One mirrors comments between the two. That is the minimum viable shape.
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.
That is the first Zap. Tested end to end, it 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.
The complications here are real and worth knowing about up front. Comment loops happen when the Zap that adds a Linear comment fires the Zap that adds a HubSpot note, which fires another Linear comment, and so on. The fix is to tag mirrored comments with a prefix or metadata flag that the reverse Zap ignores. Attachment handling is also tricky. Zapier can pass through file URLs but does not always re-upload attachments cleanly across systems. Edits and deletes are not tracked at all by default.
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. There are a few things that Zapier can technically handle but 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. The HubSpot ticket and the Linear issue have different ideas about the current state, and Zapier does not have a built-in arbiter. Teams either pick a side that always wins or live with occasional drift.
Backfill for tickets and issues that existed before the integration was set up. The Zaps only fire on new events, so anything that predates the wiring stays disconnected unless you write a one-shot backfill, usually as a separate set of Zaps or a script.
Real-time reliability at volume. Zapier is fast enough for low-volume integrations and noticeably slow at high 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 when something breaks. Zapier's task history is useful for one-off debugging and unhelpful for understanding patterns. Teams that need to know "how many tickets failed to sync this week and why" usually layer their 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.
The first is when the integration is genuinely occasional. A handful of escalations a month, where the support team can manually clean up edge cases without complaint. Zapier is faster to set up than any purpose-built tool and free at low volume.
The second is when you need a one-off flow that no purpose-built tool covers. A specific automation that fires on a custom HubSpot workflow trigger, sends a Linear issue, and notifies a Slack channel with a custom message. Zapier handles long-tail glue work better than anything else.
The third is when you are still figuring out what you need. Building the Zaps clarifies which fields matter, which events need to fire, and what the team's actual workflow looks like. A month of running on Zapier is a cheap requirements document for whatever you build or buy next.
If you are in one of those three buckets, build the Zaps and do not overthink it.
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. Engineering re-asks for customer context because the HubSpot notes are not mirrored into Linear cleanly. 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.
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.
How many tickets per week need engineering work? Under five, Zapier is fine. Twenty or more, Zapier becomes a maintenance project. The crossover is somewhere between the two and varies by team.
How much does a missed customer update cost? If a support rep failing to tell a customer about a shipped fix is a minor annoyance, Zapier's edge cases are tolerable. If it puts a renewal at risk, the cost of a missed sync is higher than the cost of a real integration.
Who owns the Zaps when they break? If the answer is "the support lead in their spare time," the integration will eventually stop being maintained. If the answer is "a dedicated ops engineer," the maintenance is doable but it is a real cost. Either way, the maintenance is part of the decision.
There is no universally right answer. There is a right answer for your team's volume, your team's tolerance for misses, and your team's 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.