In Brief: HubSpot offers two native Jira apps. The original Jira app links tickets to Jira issues from the ticket record or a workflow, with updates taking up to 24 hours. Jira (Data Sync), in beta, syncs tickets, issues, notes and comments automatically, driven by filters and stage mapping. For most teams escalating tickets to engineering on Jira Cloud, Data Sync is the stronger choice.
Support lives in HubSpot. Engineering lives in Jira. Somewhere between the two, a customer's bug report gets copied into a Jira issue by hand, the developer fixes it, and nobody tells the support agent, who tells the customer nothing. The HubSpot Jira integration exists to close that gap, but HubSpot now lists two different Jira apps in its marketplace, and they behave very differently once they are switched on.
As with the HubSpot - Slack integration, most teams install one of them, accept the defaults and never open the settings again. This guide breaks down what each app actually syncs, where each one stops, and which setup decisions separate a working integration from a backlog full of duplicate issues.
HubSpot Tickets
↓
Original app
One by one, up to 24h
⇅
Data Sync
Automatic, two-way
Jira Cloud Issues
Two Jira Apps in the HubSpot Marketplace
The original Jira app is built around association. A support agent opens a HubSpot ticket, attaches an existing Jira issue or creates a new one, and the issue then shows up on the ticket and its associated contact and company records. Eight read-only Jira properties (status, summary, ID, priority, assignee, identifier, link and reporter) land in HubSpot for use in workflows and reports.
The newer Jira (Data Sync) app is built on HubSpot's data sync engine, the same framework behind HubSpot's native Xero integration. Instead of linking records one at a time, it creates and updates records automatically based on rules you define: which Jira site, project and issue type to sync, in which direction, and which tickets qualify. HubSpot still labels it as beta (as of September 2026) in its official setup documentation, and a Super Admin has to opt the account in before it can be connected.
| Capability | Jira (original app) | Jira (Data Sync) |
|---|---|---|
| How records connect | Manual association from the ticket, or a workflow action | Automatic, based on sync rules and filters |
| Sync direction | HubSpot creates issues; Jira data comes back as read-only properties | Two-way, or one-way in either direction |
| Sync speed | Delay of one to 24 hours | Described by HubSpot as real time |
| Notes and comments | Two-way, switched on per ticket | Two-way, configured as a separate sync |
| Ticket stage updates | ✕Only via workflows reading Jira Issue Status | ✓Jira statuses mapped to HubSpot ticket stages |
| Custom field mapping | ✕Not available, workflow action sets summary and description only | ✓Requires Data Hub Starter or higher |
| Automation | "Create Jira issue" workflow action (Professional or Enterprise) | Filters decide which tickets and issues create records |
| Sync monitoring | Jira card on the ticket record | CRM syncs tab with in-sync, failing and excluded counts, plus a sync card per ticket |
| Status | Generally available | Beta as of September 2026, Super Admin opt-in |
Both apps require a Jira Cloud account.
Which Jira App Should You Use?
The choice comes down to volume and ownership. If only a handful of tickets reach engineering each month and an agent decides each one individually, the original app is enough. If escalation should follow rules, and support needs to see engineering progress without asking, Data Sync is built for it.
|
Stay with the original Jira app if Agents escalate a small number of tickets and choose each one manually A delay of several hours before updates appear is acceptable You want a simple setup with no sync rules to design Your team would rather not run beta software on a live support process |
Move to Jira (Data Sync) if Escalation should follow a rule, such as a ticket property or pipeline Support needs Jira progress reflected in HubSpot ticket stages You need custom fields such as severity or product area on both sides Developers want a direct link back to the HubSpot ticket inside Jira |
Not sure which one fits your Service Hub setup? Our HubSpot team can help you decide.
How the Jira (Data Sync) Flow Works
A Data Sync setup is really two syncs working together. The first connects HubSpot tickets with Jira issues for one site, project and issue type. The second connects HubSpot notes with Jira issue comments, and only works for tickets that the first sync already covers.
| HubSpot | Sync | Jira Cloud |
|---|---|---|
|
Support ticket In a mapped ticket pipeline |
→
If the filter matches |
Jira issue Created in the chosen project and issue type |
|
Ticket properties Custom mappings need Data Hub Starter |
↔︎
Two-way |
Issue fields Default and custom field mappings |
|
Ticket stage Updated from Jira only |
←
One way |
Issue status Each status mapped to a stage |
|
Ticket notes On tickets already in sync |
↔︎
Two-way |
Issue comments Configured as a separate sync |
|
Ticket Link HubSpot record URL |
→
One way |
Jira URL field Developers open the ticket in one click |
Before mapping any field in both directions, decide which system owns it. Otherwise a property updated by support and a field updated by engineering will keep overwriting each other, which is why clear field ownership sits at the centre of our CRM Data Quality Framework.
The Setup Decisions That Make or Break the Sync
Connecting Jira (Data Sync) takes minutes. Configuring it well takes a plan, because each screen in the setup asks a question about how your support and engineering teams actually work. These are the decisions, in the order HubSpot asks them:
- Scope: each sync covers one Jira site, project and issue type. Syncing bugs and feature requests from two projects means four syncs, and HubSpot allows as many as you need.
- Direction: two-way creates records in both systems, while one-way options keep either HubSpot or Jira as the only place new records start.
- Conflict resolution: choose which app wins when both have changed the same record and it is unclear which is more recent.
- Stage mapping: map every HubSpot ticket stage in the chosen pipeline to a Jira status, so "In Progress" in Jira means something specific in HubSpot.
- Filters: in a two-way sync you must define when a ticket creates an issue and when an issue creates a ticket. Without a filter, every new record creates a copy on the other side.
- Notes sync: set up the notes and comments sync with the same site, project and issue type, and repeat the ticket filter logic so notes follow the same rules.
"Switching the sync on is the easy part. The filter is where the real work happens, because if you haven't decided which tickets deserve engineering time, every password reset ends up in a sprint backlog," says Antonio Karneluti, CTO of Loncom Consulting.
Once the sync is live, the CRM syncs tab shows how many records are in sync, failing or excluded. Check it weekly for the first month. A green connection does not prove the data is moving, a pattern we have seen before when auditing a HubSpot - Shopify integration that looked healthy on paper.
Limitations to Plan Around
Neither app is broken, but both have boundaries that surprise teams after launch. Knowing them in advance is the difference between a design decision and a support ticket about your support tickets.
| Limitation | App | How to plan around it |
|---|---|---|
| Jira Cloud only | Both | Self-hosted Jira needs a custom API integration or a third-party connector |
| Ticket status syncs one way | Data Sync | Treat Jira as the owner of resolution status and train agents not to close escalated tickets manually |
| Jira properties are read-only in HubSpot | Original | Assignee, priority and status must be changed in Jira itself |
| Attachments on notes don't sync | Original | Share screenshots and logs through a link rather than a file attachment |
| Synced notes post as the integration user | Original | Ask agents to sign notes, or developers won't know who to follow up with |
| Older comments don't sync retroactively | Original | Summarise earlier context in the issue description when you attach it |
| Workflow action has limits | Original | EPIC issues and issue types with extra required fields can't be created from a workflow |
| Uninstalling deletes associations | Original | Export ticket and issue links before switching apps or reconnecting |
Treat each of these limits as a design input, not a surprise: decide early who owns ticket status, how files are shared and how agents sign their notes. The same planning applies on larger platforms, as our breakdown of why a Salesforce - HubSpot sync keeps breaking shows.
Need HubSpot and Jira to work as one system?
Explore Our Integration ServicesHow Loncom Approaches a HubSpot Jira Integration
We start with the process, not the app. Before anything is connected, we map how a ticket travels today: which pipeline it lives in, who decides it needs engineering, and what support needs to know back from Jira. That map decides which app fits, and whether the native options are enough or a custom integration is the better route.
From there, we design the filters and stage mapping, pilot the sync on a single Jira project, and only then roll it out across the rest. Every sync direction has a reason, and the sync is monitored after launch rather than assumed to be working. It is the same audit-first thinking behind our WinMan - HubSpot integration architecture.
Planning a HubSpot Jira integration? Let's map it together.
Book a Free ConsultationFAQ
Is there a native HubSpot Jira integration?
Yes. HubSpot offers two native Jira apps in its marketplace: the original Jira app, which links HubSpot tickets to Jira issues, and Jira (Data Sync), which runs an automated sync between tickets and issues and between notes and comments. Both require a Jira Cloud account.
What is the difference between the Jira app and Jira (Data Sync)?
The original Jira app connects records one at a time from the ticket or through a workflow, and brings Jira data back as read-only properties with a delay of up to 24 hours. Jira (Data Sync) creates and updates records automatically based on filters, supports custom field mappings and maps Jira statuses to HubSpot ticket stages. Data Sync is in beta as of September 2026.
Does the HubSpot Jira integration work with self-hosted Jira?
No. Both HubSpot Jira apps work only with Jira Cloud. Jira instances running on servers your company hosts itself need a custom API integration or a third-party connector.
Can Jira update the status of a HubSpot ticket?
With Jira (Data Sync), yes. You map each HubSpot ticket stage to a Jira status, and status changes in Jira update the ticket stage in HubSpot. The sync runs one way only, so a stage change in HubSpot does not change the Jira status. With the original app, Jira Issue Status is a read-only property you can use in workflows.
Which HubSpot plan do I need for the Jira integration?
Both apps can be installed on any HubSpot plan by a Super Admin or a user with App Marketplace permissions. The original app needs a Professional or Enterprise subscription for the Create Jira issue workflow action and custom reports. Jira (Data Sync) needs Data Hub Starter or higher for custom field mappings.
Can HubSpot deals or contacts sync to Jira?
Not directly. Both native apps are built around HubSpot tickets. In the original app, creating or associating a Jira issue from a contact or company record automatically creates a HubSpot ticket in the default pipeline. Syncing deals with Jira requires a custom integration.
How does Loncom implement a HubSpot Jira integration?
Loncom starts by mapping how tickets move between support and engineering, then chooses between the original Jira app, Jira (Data Sync) or a custom integration. We design the filters and stage mapping, pilot the sync on one Jira project, and monitor sync health after launch so failures are caught early.
Leave a comment