A self-hosted alternative to Jira Service Management
The ticket says the refund was approved. The refund ran in Stripe. Nothing in the service desk proves the approver was allowed to approve it, that the approver was not the person who requested it, or what Stripe actually returned. The status changed. The action happened somewhere else.
Latch Workflow is a self-hosted service desk that keeps the approval and the action on the same ticket — or the same case, if you work in a regulated function. It runs on your infrastructure: on-prem, in your private cloud, or air-gapped. Ticket data, the models that triage it, and identity stay inside your boundary.
This is a comparison page, so it should start by being fair. Jira Service Management is a mature ITSM product, and there are several things it does better than Latch. Those come first.
Where Jira Service Management is the better choice
Five things JSM does that Latch does not, or does less well. If two of these describe your requirement, the rest of this page is background reading rather than a buying case.
It lives where your engineers already work
If your engineering org runs on Jira Software, the link between a service desk ticket and the issue that fixes it is native, not integrated. Sprint boards, issue tracking, release versions, and the incident share one data model and one permission scheme. That gravity is real, and it is a legitimate reason to stay.
Mature ITIL practice support
Incident, problem, change, and request fulfilment are modelled as distinct practices with years of production use behind them. If you are assessed against ITIL, or your change advisory board expects those records to exist as objects rather than as conventions, JSM has already done that work. Latch has not.
Change calendars and deployment gates
Change requests carry risk scoring, CAB approval, freeze windows, and a calendar that ties back to the deployment pipeline. Latch enforces approvals on actions, but it has no change calendar and no concept of a change window.
Assets gives you a real CMDB
Hardware, software, licences, and dependency mapping, with every ticket linked to the configuration item it affects. This is a genuine capability gap. Latch tracks tickets and the actions taken on them. It does not track your estate.
A large marketplace and a large hiring pool
Thousands of Marketplace apps cover the long tail of ITSM requirements, and most service desk managers have already administered Jira. Latch offers a plugin SDK in TypeScript and Go, which is more work than installing an app and finding someone who knows it.
Atlassian does sell a self-hosted option
Plenty of comparison pages claim JSM is cloud-only. It is not. Data Center exists, it runs on your own hardware, and it is a supported product. Any vendor telling you otherwise is hoping you will not check.
The accurate objection is about who it is built for. Data Center is priced and sized for large enterprises: a high annual licence floor, an expectation that you run a cluster, and a decade of product direction pointing new customers at Cloud. If you are a twenty-person operations team subject to a data-residency rule, self-hosting is technically available to you and practically out of reach. That is the gap this product sits in, and it is a narrower claim than "they do not do on-prem".
Three things change when the ticket ends in an action
Both products handle intake, ticket routing, SLA management, and an escalation policy. The divergence starts at the point where a ticket stops being a record of a conversation and starts being the trigger for something that moves money or changes an account.
The approval gates the action, not the status
A JSM approval releases a workflow transition. The ticket moves from Pending Approval to Approved, and then a human opens Stripe, the ERP, or an admin console in another tab and does the thing. Nothing checks that the action which ran is the action that was approved.
In Latch the approval gates execution. The refund does not run until a reviewer with the right role approves it, and on sensitive work the reviewer cannot be the operator who prepared the ticket.
Execution evidence is structured, not narrated
JSM records the transition and the comment thread. Reconstructing what actually happened downstream means reading prose, opening the other system, and trusting that someone pasted the right reference number.
Latch records the requested action, the reviewer, every denied attempt, the call that went to the external system, and the response that came back — on the ticket. Whether the executed action matched the approved one is a query, not an archaeology project.
The queue sharpens because your operators corrected it
JSM automation rules do exactly what you wrote them to do, and they keep doing it until someone rewrites them. They do not learn. Atlassian Intelligence does learn, and it is a Cloud feature.
Latch treats every triage correction, reject, and approval as training signal. When your team reroutes card-dispute tickets away from the billing queue three times, the suggestion stops. The model runs where you deployed it, so the improvement stays inside your boundary instead of leaving to sharpen a shared product.
Feature comparison
What each product does without custom development. Several rows go to JSM, and they are marked that way because a comparison table you cannot trust is worse than no table.
| Capability | Jira Service Management Cloud and Data Center | Latch Workflow Self-hosted by default |
|---|---|---|
| ITSM process depth | ||
| ITIL incident, problem, and change practices | ✓ Modelled as distinct practices | Incident and request only |
| Change calendar, freeze windows, CAB workflow | ✓ | — |
| Asset management and CMDB | ✓ Assets, on Premium and above | — |
| Native link to engineering issue tracking | ✓ Same data model as Jira Software | Through a plugin or the API |
| Third-party app marketplace | ✓ Thousands of listings | Plugin SDK in TypeScript and Go |
| Service desk basics | ||
| Shared inbox, portal, and email intake | ✓ | ✓ |
| Ticket routing, queues, and assignment | ✓ | ✓ |
| SLA management and escalation policy | ✓ | ✓ |
| Rules-based workflow automation | ✓ Automation for Jira | ✓ |
| Deployment and data boundary | ||
| Self-hosted deployment | Data Center, enterprise pricing and cluster | ✓ On every tier |
| Air-gapped operation | Possible on Data Center | ✓ |
| Data residency under your control | Cloud pinning in selected regions | ✓ Wherever you deploy it |
| AI models run inside your boundary | — Atlassian Intelligence is Cloud | ✓ Your endpoint, your hardware |
| Approvals and evidence | ||
| Approval gates a status transition | ✓ | ✓ |
| Approval gates the downstream action | — | ✓ |
| Two-person review enforced by the system | Convention, or a Marketplace app | ✓ Maker-checker built in |
| Denied attempts kept as evidence | In the comment history | ✓ On the audit trail |
| External system response stored on the ticket | Unstructured, via automation | ✓ Structured request and response |
| Triage that learns from operator corrections | Atlassian Intelligence, Cloud only | ✓ Inside your boundary |
Marks reflect what each product does out of the box as of August 2026. Atlassian ships quickly and packaging changes, so check the current JSM tier before you decide on any single row. Latch pricing is on the pricing page and does not charge per agent.
When Jira Service Management is the answer
- Your service desk exists mainly to feed work into engineering, and the Jira Software link is the reason the tool was chosen.
- You are assessed against ITIL and need change, problem, and CAB records to exist as first-class objects rather than as team habit.
- Asset and licence management is a primary requirement, not a nice-to-have.
- Your tickets end when someone replies. If no ticket in the queue triggers an action on an external system, the approval argument on this page does not apply to you.
When the self-hosted option is worth the move
- Ticket data cannot leave your infrastructure, and Data Center pricing does not fit the size of the team that needs it.
- Tickets end in refunds, vendor bank-detail changes, limit adjustments, or reprocessing runs on another system.
- Someone will eventually ask you to prove that the action which ran is the action that was approved, and by whom.
- You want the triage suggestions to improve from your own operators correcting them, without sending those corrections to a vendor.
Running both is a normal outcome
This is not usually a rip-and-replace decision. Engineering issue tracking stays in Jira, where it belongs. The two or three queues where a ticket moves money — payment exceptions, vendor changes, account adjustments — move to Latch, and a plugin keeps the Jira issue and the Latch ticket linked so the service desk still sees one story.
What teams ask when they compare the two
The questions that come up in an evaluation, answered including the ones where the answer is no.
Is Jira Service Management cloud-only?
No, and any comparison that says so is wrong. Atlassian still sells Data Center, which you run on your own infrastructure. The accurate objection is narrower: Data Center is priced and sized for large enterprises. It carries a high annual licence floor, it assumes a cluster and the people to run one, and Atlassian has spent years steering new customers toward Cloud. A twenty-person operations team under a data-residency rule can technically buy Data Center and practically cannot justify it.
Does Latch Workflow support ITIL change management?
Not in the way JSM does. There is no change calendar, no change advisory board object, and no risk-scoring model for change requests. Latch enforces approvals on the action rather than modelling the ITIL process around it. If your auditors expect ITIL change and problem records as first-class artifacts, JSM is the better fit and this page is not going to argue otherwise.
Does Latch have asset management or a CMDB?
No. JSM Assets gives you a configuration management database with hardware, software, licences, and dependency mapping linked to tickets. Latch has no equivalent. If asset management is the reason the evaluation started, stop here.
Can Latch run alongside Jira Service Management?
Yes, and for a lot of teams that is the sensible arrangement. Engineering issue tracking stays in Jira. The queues where a ticket ends in a refund, a vendor bank-detail change, or a limit adjustment move to Latch. A plugin keeps the Jira issue and the Latch ticket linked in both directions, so the service desk still sees one story.
How does the AI triage stay inside our boundary?
The model runs where you deploy Latch. On-prem, private cloud, or air-gapped, inference happens against an endpoint you control, and the corrections your operators make are stored with your ticket data. Nothing is shipped to a vendor to improve a shared model. Atlassian Intelligence is a Cloud feature, which is the trade you are making if data residency is the constraint.
What does moving a queue off JSM involve?
Export the request types, the SLA targets, and the escalation policy for the one queue you want to move. Map the JSM approval steps onto Latch approval gates, which is usually where the model changes, because a JSM approval releases a status transition and a Latch approval releases the downstream action itself. Run both in parallel for a few weeks, compare the audit trail, then cut over. Moving one queue is a days-to-weeks exercise. Moving an entire ITIL estate is not, and should not be attempted as a first step.
See what a ticket looks like when the approval gates the action
Walk through one queue end to end: intake, triage, the approval step, the plugin action, and the audit trail it leaves behind. Bring the workflow you are least comfortable proving after the fact.