If you have tried Zapier and outgrown it, the next stop most teams consider for HubSpot to Linear sync is Make (formerly Integromat). Make is a different shape of automation platform: visual scenario builder, more powerful conditional logic, friendlier pricing at moderate volume, and a steeper initial learning curve. For the right use cases, it is a meaningful step up.
This guide walks through how to actually build a HubSpot to Linear integration in Make, the three scenarios most teams end up with, where Make is genuinely better than the alternatives, and the honest read on when to replace it with a purpose-built sync.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What Make's HubSpot to Linear Integration Looks Like
Make connects tools through "scenarios," which are visual flowcharts of modules linked by data flows. The HubSpot module exposes triggers and actions like "Watch Tickets," "Get a Ticket," "Update a Ticket," and a few dozen others. The Linear module exposes "Create Issue," "Update Issue," "Add Comment," and similar. Between them, you can build almost any HubSpot to Linear flow.
The thing that distinguishes Make from Zapier is what happens between the trigger and the action. Make supports routers, filters, iterators, aggregators, and inline data transformations, all configured visually. A scenario can branch based on ticket severity, transform a HubSpot pipeline stage into a Linear status, fetch a customer record from a third system, and conditionally send Slack notifications, all in one diagram.
That power comes with cost. Each module is an operation, and each scenario run consumes operations equal to the number of modules executed. Scenarios with comment sync, conditional branches, or data lookups burn through the operation budget faster than the equivalent Zapier task count would suggest. Pricing is friendlier than Zapier at moderate volume and unfriendlier at high volume.
For the rest of this guide, "the integration" means three scenarios working together. The shape is similar to the Zapier setup covered in the Zapier HubSpot to Linear guide, and the differences are in execution.
Before you start
- A Make account on at least the Core plan if you expect production volume.
- Both HubSpot and Linear connections authorized in Make.
- A dedicated HubSpot pipeline for engineering escalations so you do not watch every inbound ticket.
- A custom HubSpot ticket property to hold the Linear issue URL. Every downstream scenario relies on it.
- An operations estimate for your real ticket and comment volume, so the plan you pick has headroom.
Scenario 1: Create a Linear Issue from a HubSpot Ticket
This is the foundational scenario and the one most teams build first. The trigger is HubSpot's "Watch Tickets" module, scoped to a specific pipeline. The action is Linear's "Create an Issue" module.
- 1
Set up the HubSpot trigger
Drop a "HubSpot" module on the canvas. Pick "Watch Tickets" as the trigger. Connect your HubSpot account. Configure the trigger to watch a specific pipeline, usually the engineering escalation pipeline, and set the polling interval. Make polls every fifteen minutes on the Core plan and faster on higher tiers.
- 2
Add a router for severity branching
Drop a Router module after the trigger. Add a route for each severity that should produce a Linear issue, and a "do nothing" route for severities that should not. This is where Make's visual logic pays off. The same branching in Zapier requires multiple filter steps and is harder to reason about visually.
- 3
Configure the Linear Create Issue module
On the route that fires, add a "Linear" module and pick "Create an Issue." Map the HubSpot fields to Linear fields with Make's data mapping panel. Title from ticket subject. Description from the ticket body. Severity-derived labels. Team from a default or from a HubSpot custom property.
- 4
Update HubSpot with the Linear issue URL
Chain a final "HubSpot" module that calls "Update a Ticket" and writes the Linear issue URL back to a custom property. This is the link the downstream scenarios rely on. Without it, you cannot find the Linear issue from the HubSpot ticket later.
- 5
Test with a real ticket
Run the scenario manually with a real test ticket and verify the Linear issue is created cleanly. Make's execution history is detailed, so debugging is easier than Zapier's task-by-task view. Look for failed mappings, missing required fields, and any rate-limit issues before turning the scenario on.
The scenario should run end to end in under thirty seconds once polling fires. The first build takes most teams about an hour, longer than the Zapier equivalent because the scenario builder is more powerful and therefore more decisions need to be made.
Scenario 2: Sync Linear Status Changes Back to HubSpot
The second scenario closes the loop that the first one leaves open. Without it, the HubSpot ticket sits at its initial status forever while Linear moves through Backlog, In Progress, In Review, and Done. The trigger is Linear's "Watch Issue Updates" module, filtered to status changes. The action is updating the matching HubSpot ticket.
The status mapping is the other place Make's visual builder helps. Use a Switch module or a Set Variable with a complex expression to translate Linear states to HubSpot pipeline stages. Both are easier to maintain than the equivalent multi-step Zap, especially as the status list grows over time.
When the scenario fires, the HubSpot ticket should move to the right pipeline stage automatically. Add an internal note module to document the status change with a timestamp and the Linear issue URL, so support has an audit trail without leaving the ticket.
Scenario 3: Mirror Comments Between Systems
This is the scenario that produces the most operations consumption and the most ongoing pain. Make handles it more cleanly than Zapier does, but the underlying problems are the same. The trigger is Linear's "Watch Comments" module. The action is to add an internal note to the matching HubSpot ticket. The reverse direction uses a HubSpot "Watch Engagements" trigger.
Where Make Beats Zapier
A few places where Make is genuinely the better tool for this integration.
Branching logic
Routers and Switches express conditional flows visually. A scenario that creates Linear issues for one severity, sends a Slack message for another, and ignores the rest is easy in Make and painful in Zapier.Data transformation
Make's expression language is more powerful than Zapier's Formatter. Pipeline-stage-to-status mapping and label normalization are all easier in Make.Execution visibility
Make's execution history shows the full data at each module, which makes debugging much faster than Zapier's task log.Pricing at moderate volume
Operations are cheaper than Zapier's tasks at most price points. For a single multi-step scenario, Make is usually the cheaper run.
Where Make Falls Short
The cases where Make is the wrong tool are equally specific.
Setup time
The first scenario takes longer to build than the equivalent Zap, because the visual builder asks you to make more decisions. For a one-step trigger, Zapier is faster.Operations consumption at high volume
A scenario with a router, three main-path modules, and an error handler can burn ten operations per run. At ten tickets per day that is 3,000 operations per month for one scenario, and comment sync grows the budget quickly.Ongoing maintenance
Scenarios that started simple accrete branches over time. One router becomes three, then five, then a flowchart only one person on the team can read.Comment and attachment edge cases
The same problems that hit Zapier hit Make. It handles them more cleanly, but neither tool handles them transparently.
When Make Is the Right Answer
Make is the right tool for HubSpot to Linear sync in three specific situations.
Make fits when
- The integration has real branching logic that changes often
- You already run other automations in Make
- You need flexible data transformation HubSpot and Linear fields do not map without
Reach for something else when
- This would be your only Make scenario
- The flow is one-direction and rules rarely change
- You want the customer-facing reply staged automatically
If you are in one of those three fits, Make is a solid choice and will serve you well.
When to Replace Make with a Purpose-Built Sync
The signs that Make has outgrown its usefulness follow the same pattern as Zapier, just with a longer leash.
The first sign is that the scenario count keeps growing. One scenario becomes three, three becomes five, and now there are scenarios that exist to fix problems in other scenarios. The integration is technically configured and effectively a maintenance project.
The second sign is operations exhaustion. The monthly operation count climbs past the plan limit, and the next plan up is meaningfully more expensive. You start optimizing scenarios for operation efficiency, which is a sign you are paying for the wrong layer.
The third sign is the customer-facing miss. A bug was fixed, the status updated in Linear, the scenario ran, the HubSpot ticket moved to the right stage, and nobody told the customer because that part still requires a human writing a reply from scratch. The integration did its job and the workflow still failed.
Make can move the ticket to the right stage automatically. It still cannot tell the customer the fix shipped.
For HubSpot Service Hub and Linear specifically, the purpose-built version of what the three scenarios above are trying to do is IssueLinker. Ticket-to-issue creation, two-way status sync, and comment mirroring are first-class features instead of scenarios you maintain. The customer-facing reply is staged with the engineer's resolution note attached, ready to send. The full pattern is covered in the Linear HubSpot integration guide, and the trade-offs against other purpose-built tools are covered in the Unito vs IssueLinker comparison.
Make scenarios growing faster than you can maintain them?
If your HubSpot to Linear integration is a stack of Make scenarios and an operations budget, IssueLinker handles the whole loop as a purpose-built sync. No scenarios to debug, no operations to optimize, and the customer hears about the fix the moment it ships.
A Quick Decision Framework
Three questions usually clarify whether Make is the right tool for your HubSpot to Linear sync.
| Question | Lean Make | Lean purpose-built |
|---|---|---|
| How much branching logic does the flow need | Rules change often, real conditional behavior | Mostly one-direction, rules rarely change |
| How many other integrations live in Make | You already run several scenarios | This would be your only scenario |
| How much operations budget for comment sync | You have headroom at production volume | Comment sync alone would push you up a plan |
The next post worth reading either way is the bug tracking template guide, which covers the fields the integration should carry regardless of which tool you build it on.
