What is Latch Workflow?
Latch Workflow is a self-hosted ticketing and case management platform. It runs inside your own infrastructure — on-prem, private cloud, or air-gapped — so ticket data, AI models, and identity never leave your boundary. It also learns from the work: every triage call, approval, rejection, and correction an operator makes is training signal, and the queue gets sharper without that signal leaving your network.
The unit of work is a ticket — or a case, if you work in KYC, AML, reconciliation, or another regulated function. Latch does the things a help desk does: intake from every channel, ticket routing, SLA management, escalation policy. Then it adds the part most help desks leave out, which is an approval step before a sensitive action runs and a record of who approved it.
This page defines the product and places it against the categories you are probably comparing it to. If you arrived looking for deployment specifics, the self-hosted ticketing page covers on-prem, air-gapped, and data-residency detail instead.
Where Latch sits, and what it is not
Most teams do not buy a category. They buy a way out of one specific failure: the refund approved in a Slack thread, executed in the Stripe dashboard, and impossible to reconstruct three months later when someone asks who signed off.
Two kinds of system already bracket that failure. Above it sit governance and policy platforms that hold the rule but never touch the work. Below it sit the execution systems — Stripe, the ERP, the internal API — that run the action but do not know who was allowed to ask for it. Latch is the runtime control layer between them: the ticket is where the decision is made, the action runs from inside the ticket, and the audit trail is a by-product of doing the work rather than a reporting exercise afterwards.
That places Latch next to four categories buyers usually shortlist alongside it. Each of them does something Latch does not.
Zendesk, Freshdesk, Intercom
These are stronger than Latch at high-volume consumer support: mature agent tooling, a large app marketplace, and a decade of shared inbox refinement. They also run in the vendor's cloud, which is the part that stops the conversation in a bank, a hospital, or a defence supplier.
Latch keeps the queue, the routing, and the SLA clock, and puts them on infrastructure you control.
Compare with Zendesk →Jira Service Management, ServiceNow
ITSM suites carry process depth Latch does not attempt: change advisory boards, a CMDB, asset management, and the full ITIL catalogue. If your requirement list reads like ITIL, buy one of those.
Latch is narrower on process and stricter on execution. The action on the external system runs through a role check and an approval gate, and the result is written back to the ticket.
Compare with Jira Service Management →Policy registers and control libraries
GRC platforms are built to hold the control description, the owner, and the test evidence. They are good at that. They sit outside the queue, so the evidence they hold is assembled after the work, usually by hand.
Latch records the control as it executes, which is why the audit trail does not need to be rebuilt from screenshots.
See the audit trail →Assistants bolted onto the inbox
Copilots summarise, classify, and draft. They are quick to adopt because they change nothing structural. That is also the limit: there is no gate between the suggestion and the action, and no record of what was proposed versus what was done versus what was blocked.
In Latch the model still recommends and the operator still decides. The difference is that both are recorded, and the decision is what trains the next suggestion.
See triage and routing →Follow a refund approval from intake to proof
This is what happens inside one case. Every step, every decision, and every result stays on the same record.
Customer refund request arrives
A customer asks for a refund above the standard threshold. Latch creates a case with the original request, order details, and any supporting context.
AI classifies and flags the approval requirement
The model identifies the case type, suggests a priority, and surfaces the rule: refunds above the threshold require a second reviewer before the Stripe payout runs.
First operator reviews the case and confirms
The operator sees the request, the AI classification, and the order history together. They verify the refund reason, add a note, and mark the case ready for approval.
Second reviewer approves independently
A different person in the required role reviews the case. They see the full context, the first reviewer's notes, and the proposed refund amount. The person who prepared the case cannot self-approve — the system enforces role separation.
The Stripe refund runs from inside the case
The plugin triggers the refund in Stripe. The request, the response, and the payout confirmation all write back to the case timeline automatically.
Someone asks "what happened with that refund?"
The team opens one case. The request, classification, reviewer notes, approval, Stripe result, and any denied attempts are all on the same record. No reconstruction needed.
The same workflow, two ways
A refund approval that crosses a threshold. The same triggering event, the same downstream system, the same people involved. The difference is where the work and the record live.
The refund request arrives in email or Slack. Someone copies the details into a ticket. The order context and the request are already in two different places.
The request arrives and becomes a case. The customer message, order details, and any attachments are on one record from the start.
The reviewer opens the ticket, then opens the order in Stripe, then searches Slack for the earlier thread. They reconstruct the context from fragments.
The reviewer opens the case. The request, order details, AI classification, and suggested next step are already there.
Someone messages a manager in Slack. The manager replies "approved." Nobody records who else tried to act, or whether the approver was in the right role.
Two-person review is enforced at the system level. The person who prepared the case cannot approve it. A second reviewer sees the full case context. Denied and blocked attempts are recorded.
An operator logs into Stripe and processes the refund manually. They come back to the ticket and type "done." The payout and the record of the payout are in different places.
The Stripe plugin fires from inside the case. Stripe confirms the refund. The request, the response, and the result write back to the case timeline automatically.
Three months later, someone asks what happened. The team searches email, pulls Slack logs, checks the ticket, and digs through Stripe. The story takes hours to reconstruct.
Three months later, someone asks what happened. The team opens one case. Intake, review, approval, refund, and result are all there. The story takes minutes to read.
The refund request arrives in email or Slack. Someone copies the details into a ticket. The order context and the request are already in two different places.
The request arrives and becomes a case. The customer message, order details, and any attachments are on one record from the start.
The reviewer opens the ticket, then opens the order in Stripe, then searches Slack for the earlier thread. They reconstruct the context from fragments.
The reviewer opens the case. The request, order details, AI classification, and suggested next step are already there.
Someone messages a manager in Slack. The manager replies "approved." Nobody records who else tried to act, or whether the approver was in the right role.
Two-person review is enforced at the system level. The person who prepared the case cannot approve it. A second reviewer sees the full case context. Denied and blocked attempts are recorded.
An operator logs into Stripe and processes the refund manually. They come back to the ticket and type "done." The payout and the record of the payout are in different places.
The Stripe plugin fires from inside the case. Stripe confirms the refund. The request, the response, and the result write back to the case timeline automatically.
Three months later, someone asks what happened. The team searches email, pulls Slack logs, checks the ticket, and digs through Stripe. The story takes hours to reconstruct.
Three months later, someone asks what happened. The team opens one case. Intake, review, approval, refund, and result are all there. The story takes minutes to read.
Extend with plugins. Bring your own models. No custom integration code.
Plugins are how Latch connects to external systems and AI models. Write them in TypeScript or Go. Instead of building a bespoke integration for every tool, you connect them through the plugin SDK. Each plugin receives ticket context, returns the actions that apply, and runs them with role checks, approval gates, and immutable logging built in. Models run the same way, which is how inference stays inside the deployment boundary.
The plugin sees the ticket type, the customer, the amount, and the context. It returns only the actions that apply to this specific ticket.
The operator sees the available actions on the ticket. If the action requires approval, it goes to a reviewer first. If not, the operator runs it directly.
The plugin triggers the action — a Stripe refund, an ERP update, a Slack notification, an internal API call. Latch handles authentication and logging.
What was requested, what the external system returned, whether it succeeded or failed — all recorded on the ticket timeline automatically.
Without plugins, connecting external systems means writing custom code, maintaining webhooks, and building your own permission layer. The plugin SDK gives you a standard way to connect any system — or your own models — with approval steps, role checks, and immutable logging already built in. Your team gets the integration without the integration debt. The plugin model and the developer SDK cover the API surface.
If you already use one of these, here is what changes
Latch is not a replacement for everything. It adds the layer that existing tools leave out: approval steps, role checks, plugin actions, and a case-native audit trail.
Cloud help desk
Latch is a ticketing system too, so the question is not which category it belongs to. It is three things those tools do not do. They run in the vendor cloud, so ticket data and the model reading it sit outside your boundary. They route and escalate, but nothing stops a refund or a bank-detail change from executing without a second person. And when an operator corrects a suggested priority, that correction trains nothing.
Tickets still arrive through email, forms, and the API, and the queue still looks like a queue. The difference is that it runs on your own infrastructure, sensitive actions stop at an approval step instead of happening in a separate admin tool with a note added later, and each correction becomes signal the next suggestion uses.
Cloud vendor with a residency add-on
A regional hosting tier tells you which country the vendor stores your tickets in. It does not change who operates the database, whose model reads the ticket body, or which subprocessors appear on next year's list. Teams under data-residency rules, an on-prem mandate, or an air-gapped network buy the add-on and still write the exception memo.
Latch installs inside your boundary: your servers, your private cloud, or a network with no outbound route. Ticket data, identity, and the model doing the classification stay on your side of the line. You bring the model as a plugin, on your own API key or your own hardware, so the AI does not become the exception to the deployment story.
Slack or email approvals
Many teams run sensitive workflows through Slack messages, email forwards, and spreadsheet tracking because their existing tools do not support real approval steps. The work gets done, but the evidence is scattered and the approval story is reconstructed from memory.
The workflow moves from side-channel coordination to one ticket where the request, review, approval, action, and proof stay together. The team stops depending on someone remembering to update the spreadsheet.
AI copilot
AI copilots generate summaries, classify work, and suggest next steps. They do not have an execution boundary. There is no gate between the recommendation and the action, and no structured record of what was recommended versus what was done versus what was blocked. The model is also the vendor choice, hosted in the vendor cloud, reading your tickets.
The model still recommends and the operator still decides. Latch adds the gate and the record: the suggestion appears on the ticket, the operator acts or declines, and the system keeps the recommendation, the decision, and the outcome together. You pick the model, and the corrections your operators make stay inside your deployment as training signal.
Internal admin tools
Admin tools let operators take action on external systems. They do not enforce who can do what, do not require a second reviewer for sensitive actions, and do not capture the full decision trail. The action and the record live in different places.
Plugins bring those same actions onto the ticket. Role checks, approval steps, and the audit trail wrap around the action automatically, so the team does not need to build that infrastructure into every admin tool.
Six capabilities in one ticketing platform
You do not need all six on day one. Most teams start with one queue and one approval step, then add the rest as the work justifies it.
Ticket intake and routing that learns
Email, forms, alerts, and system events land in one queue rather than a shared inbox. Latch classifies, routes, and proposes the next step, and each correction an operator makes changes what it proposes next time. Nothing runs without the operator.
See triage and routing →Approval steps the system enforces
Require a reviewer before a refund runs, a vendor bank detail goes live, or a high-risk action executes. The platform enforces it — not a process document or a Slack emoji.
See approval workflows →Two-person review for sensitive actions
The person who prepared the ticket cannot approve it. Latch enforces role separation (also called maker-checker, or four-eyes) at the system level, so it does not depend on a forwarded email.
See dual approval →An immutable audit trail on every ticket
Who approved, what changed, every denied attempt, what the external system returned — recorded in an append-only trail and exportable for an audit. No reconstructing the story from screenshots and chat logs.
See audit & compliance →Write your own plugins and bring your own models
Stripe, Slack, your ERP, internal APIs, your own models — connect them through plugins written in TypeScript or Go. Each plugin gets role checks, approval gates, and immutable logging without you building that layer again.
See plugins and integrations →Runs on infrastructure you control
On-prem, private cloud, or air-gapped, with identity through your own OIDC provider. Ticket data, model inference, and audit records stay in the jurisdiction your data-residency rules name.
See self-hosted deployment →Questions teams ask before they start
The most common questions from teams working out whether Latch fits their queue.
What is Latch Workflow?
Latch Workflow is a self-hosted ticketing and case management platform. It runs inside your own infrastructure — on-prem, private cloud, or air-gapped — so ticket data, AI models, and identity stay inside your boundary. It handles intake, ticket routing, approvals, and actions on external systems through plugins, and it records every decision in an immutable audit trail.
Is Latch a ticketing system or a case management system?
Both nouns describe the same record. Support, IT, and operations teams call it a ticket. Finance, KYC, AML, and reconciliation teams call it a case. Latch uses one model for both: intake, owner, evidence, approval state, plugin actions, and full history on a single record.
Can Latch run on-premise or air-gapped?
Yes. Latch installs in your own environment — on-prem, private cloud, or fully air-gapped. Teams under data-residency rules use it to keep ticket data, identity, and model inference inside the network boundary. You can start on a managed instance and move to self-hosted later without changing the workflow.
What does it mean that Latch learns from operator decisions?
Every triage call, approval, rejection, and correction is training signal. If your team reroutes a class of vendor exception to finance three times, the queue starts proposing that route. If reviewers keep denying a category of refund, Latch stops surfacing it as a suggested action. The model improves on your tickets, inside your boundary, and the improvement does not leave with a vendor release.
How do plugins and custom models work?
A plugin connects Latch to an external system — Stripe, your ERP, Slack, an internal API, or your own models. Write them in TypeScript or Go. Each plugin receives ticket context, returns the actions that apply to that ticket, and runs them with role checks, approval gates, and immutable logging already in place.
What does an approval workflow look like in Latch?
The action cannot run until someone with the right role reviews it. For sensitive actions, two-person review (also called four-eyes control or maker-checker) requires the approver to be a different person than the one who prepared the ticket. The approval and every denied attempt are recorded in the audit trail.
Who should not use Latch?
Teams that want a consumer-scale support desk with a large app marketplace and no control requirements are better served by a cloud help desk. Teams that need full ITIL change management, a CMDB, and asset tracking should look at an ITSM suite. Latch is for teams whose tickets trigger actions that need a reviewer, a boundary, and a record.
How long does it take to go live?
Most teams run their first queue within days. Pick one workflow — refund approvals, vendor bank-detail changes, reconciliation cases — connect the relevant plugin, and put real tickets through it before adding the second.
Watch the queue work before you talk to anyone
The walkthrough follows one refund from intake to approval to the Stripe call and the audit record, on real screens. If it looks like your queue, the conversation after it is a fit or no-fit answer on one workflow.