What is Latch Workflow?
Most help desks record the request, then leave the approval and downstream action to Slack, email, or an admin tool. Latch Workflow keeps intake, review, plugin actions, and the audit trail on one ticket, with source code available on Enterprise.
Support teams call that record a ticket. Finance and operations teams call it a case. It is the same record: the request, the reviewer's decision, the action that ran, and what the external system returned.
The AI that classifies, routes, and suggests is a plugin, so the model is yours. A commercial API with your own key, an open-weights model on your own hardware, or an endpoint your team already runs. Swapping models is a configuration change, not a migration.
It runs in your environment, private cloud, or a disconnected network, and the model inference, ticket data, identity, and audit trail stay inside your boundary. If the work ends with a simple ticket resolution, a cloud help desk may be enough. Latch fits when the ticket also has to govern what happens next.
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 service desk products 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, issue tracking, 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 someone else's cloud
Copilots summarise, classify, and draft. They are quick to adopt because they change nothing structural. The model is also the vendor's choice, hosted in the vendor's cloud, with your tickets as the input.
In Latch the model still recommends and the operator still decides. You choose and host the model, both decisions are recorded, and the correction is what trains the next suggestion.
See bring your own model →The same boundary defines how Latch compares with each of them. Ticketing with approvals covers the workflow side, and the comparison library states where the overlap is real and where it is not.
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.
The same pattern when a site inspection finds the problem
A cathodic protection survey ends with one test station reading below the accepted range. The reading, the coordinates, the photographs, and the source export leave the field by email, and the integrity work order is created somewhere else three days later. The link between them is a subject line.
In Latch the finding becomes a ticket in the same queue as every other request. The evidence, the reviewer's decision, the approved handoff, and the returned work-order reference stay on one record.
The finding arrives as a record
A configured inspection form or a connected mailbox creates the ticket. The reading, coordinates, photographs, source export, and the original message are preserved as submitted context.
The queue makes it reviewable
The ticket lands in the Triage Queue with the site, asset, issue type, and attachments. Creating the ticket does not mean the engineering assessment or the corrective work is complete.
A reviewer checks the evidence
The reviewer sees the submitted evidence beside the ticket history and, where configured, a recommendation for the next step. Qualified people interpret the inspection; the recommendation is decision support.
Approval gates the handoff
Approval precedes the plugin action that creates the integrity work order. The returned reference lands beside the reading and the review decision, and a failed handoff stays visible for follow-up.
The inspections section covers the full pattern, including automatic ticket creation from a connected mailbox or form, the cathodic protection survey workflow, and the inspection audit trail. The synthetic CP survey walkthrough follows one exception from reading to work-order handoff on real screens.
Extend with plugins. Bring your own model. 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. The model runs 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, a GitHub action, 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 model — with approval steps, role checks, and immutable logging already built in. Your team gets the integration without the integration debt. The plugin model, the bring-your-own-model path, 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, a requirement to deploy in your environment, or a disconnected 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.
Capabilities in one ticketing platform
You do not need all of it on day one. Most teams start with one queue and one approval step, then add the rest as the work justifies it. Pricing is by tier rather than per agent, so a reviewer who only approves does not change the bill.
Bring your own AI model
The model that classifies, routes, and suggests is a plugin. A commercial API with your own key, an open-weights model on your own hardware, or an in-house endpoint. Swapping models is a configuration change, not a migration.
See bring your own model →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 →Reporting and operations dashboards
Ticket workload, active backlog, status and priority mix, intake sources, unclassified work, plugin health, and AI readiness on one dashboard. Saved reports cover queue and SLA performance.
See the operations dashboard →SLA management and escalation
Response and resolution targets attach to tickets with working-hours calendars, and tags can carry their own policy. An escalation policy routes work before a deadline passes.
See the operations workflow →Plugin actions and integrations
Connect Stripe, GitHub, your ERP, and internal APIs. Each action runs from the ticket with role checks, approval gates, and immutable logging, and linked resources such as pull requests and branches stay on the record.
See plugins and integrations →Runs on infrastructure you control
In your environment, private cloud, or a disconnected network, with identity through your own OIDC provider. Ticket data, model inference, and audit records stay in the jurisdiction your data-residency rules name.
Also on the platform
Beyond the headline capabilities, the same platform covers email and form intake with attachments, sites and asset records, maintenance schedules, sub-issues and linked resources, notifications, and field-service access with cached tickets and durable drafts.
The REST API, TypeScript and Go SDKs, and native MCP support let your own services and agents drive workflow automation on the same queue under the same permissions. The guided walkthroughs cover the surface end to end.
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 modern ticketing and case management platform with source code available on Enterprise. It runs inside your environment, private cloud, or a disconnected network with the AI model you choose. It handles intake, routing, approvals, plugin actions, and 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 in our environment or on a disconnected network?
Yes. Latch installs in your environment, private cloud, or a disconnected network. 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 it into your environment 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, GitHub, 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.
Does Latch Workflow include reporting and dashboards?
Yes. The operations dashboard shows active backlog, status and priority mix, intake sources, unclassified work, plugin health, and AI readiness. Saved reports cover queue and SLA performance, and both run inside your deployment.
How does Latch Workflow manage SLAs and escalation?
Response and resolution targets attach to tickets with working-hours calendars, and tags can carry their own SLA policy. Escalation rules route work when a deadline approaches, and the SLA report tracks performance without a spreadsheet.
Can Latch Workflow connect to GitHub and our internal tools?
Yes. Plugins and action providers connect Latch to GitHub, Stripe, your ERP, and internal APIs. Provider actions can attach linked resources such as pull requests, commits, and branches to the ticket, and signed webhooks can create or update tickets from external events.
Can an AI agent or MCP client use Latch Workflow?
Yes. Agents authenticate with scoped bearer tokens and reach only the tools and tickets those permissions allow. Every request passes the same role and ticket checks as a human session, and the record shows which actor proposed or executed what.
What does Latch Workflow cost?
Latch starts at $30 per month for teams of up to 20 users and scales to Enterprise deployments in your environment. Pricing is by tier rather than per agent, so adding a reviewer who only approves does not change the bill.
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.