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.
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. One creates a Linear issue from a HubSpot ticket. One updates HubSpot when the Linear issue status changes. One mirrors comments. The shape is similar to the Zapier setup covered in the Zapier HubSpot to Linear guide, and the differences are in execution.
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, mirroring HubSpot notes to Linear comments, is structurally similar with a HubSpot "Watch Engagements" trigger.
The comment loop problem applies here the same way it does in Zapier. A mirrored comment in HubSpot fires the HubSpot trigger, which adds a Linear comment, which fires the Linear trigger, and so on. The fix is to prefix mirrored comments with a tag like "[synced]" and add a filter to the trigger that ignores those. Make supports this with a single filter expression, which is cleaner than the multi-step Zap workaround.
Attachment handling is the harder problem. Make can pass file references between modules, but actually re-uploading attachments cleanly across systems requires extra modules to download and re-upload binary data. Most teams that build this scenario settle for text-only comment sync and leave attachments as a manual step.
Where Make Beats Zapier
A few places where Make is genuinely the better tool for this integration.
Branching logic. Routers and Switches let you 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 to build in Make and painful to build in Zapier.
Data transformation. Make's expression language is more powerful than Zapier's Formatter. Pipeline-stage-to-status mapping, severity label normalization, and custom field manipulation are all easier in Make.
Execution visibility. Make's scenario execution history shows the full data at each module, which makes debugging much faster than Zapier's task log. When something breaks, you can see exactly where.
Pricing at moderate volume. Make charges per operation, and 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 in Make 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. Make's pricing flips on you when the operation count grows. A scenario that uses a router, three modules in the main path, 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. Add comment sync and the budget grows quickly.
Ongoing maintenance. Make scenarios that started simple tend to accrete branches over time. A scenario with one router becomes three, then five, then a flowchart only one person on the team can read. The visual builder makes the growth invisible until someone has to debug it.
Comment loop and attachment edge cases. The same problems that hit Zapier hit Make. Make 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.
The integration has real branching logic. Different severities go to different teams, different customer tiers trigger different notifications, and the routing rules change often. Make's visual builder handles this gracefully where Zapier becomes a wall of filter steps.
You already use Make for other automations. Adding the HubSpot to Linear scenario to an existing Make workspace is a small marginal cost. Starting fresh on Make for this one integration is more setup than the integration justifies.
You need flexible data transformation. The HubSpot fields and the Linear fields do not map cleanly without intermediate processing. Make's expressions handle this in one module where Zapier needs a multi-step Formatter chain.
If you are in one of those three buckets, 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.
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.
How much branching logic does the integration need? If routing rules change rarely and the flow is mostly one-direction, the iPaaS flexibility is overkill. If the rules change often or the flow has real conditional behavior, Make's visual builder earns its keep.
How many other integrations live in Make? If this is your only Make scenario, the platform's overhead is high relative to the value it produces for one workflow. If you already run five scenarios, the marginal cost of adding HubSpot to Linear is small.
How much operations budget do you have for this integration alone? Comment sync at production volume is the line item that surprises most teams. Run a back-of-the-envelope estimate before committing, and compare it to the flat-rate alternatives. The cheapest setup on paper is not always the cheapest after a year of running it.
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.