Skip to content
Latch
See how it works
Product walkthrough

Follow one ticket from intake to proof

Latch Workflow is a self-hosted ticketing system. Intake, triage, approval, plugin execution, and the audit trail all run inside your own boundary — on-prem, in your private cloud, or air-gapped — and the queue gets sharper as your operators correct it.

Work arrives as a ticket — or a case, if you work in a regulated function. The screens below are the real product, in the order an operator meets them.

Talk to us See where it runs
Operations & Compliance Banks & Regulated Industries Platform Teams
The problem

The risky work
happens off the record

Your team approves refunds in Slack, updates vendors in the ERP, and tracks exceptions in a spreadsheet. Approval happened in email. The execution happened in another admin tool. Nobody can show the reviewer path without rebuilding it.

Approval happened in email — not on the ticket
Exception notes live in chat where nobody can find them later
The execution happened in another admin tool
Nobody can show the denied attempts or the exact reviewer path

That is not a control model. That is a coordination habit.

How it works

Six stages.
One record.

Intake
Email, forms, tickets, and system alerts all land in the same queue.
Triage
A model you choose classifies, prioritises, and proposes ticket routing.
Approve
Require a second person to review before a high-risk action executes.
Execute
Plugin actions run with role checks, permissions, and immutable logging.
Prove
Immutable audit trail — who approved, what changed, every denied attempt.
Learn
Every correction is training signal. The next suggestion reflects it, inside your boundary.

Latch is a ticketing and workflow system with triage, approvals, plugin actions, and an immutable audit trail built in. Nothing in that list requires a vendor cloud: it deploys on-prem, in your private cloud, or air-gapped, and the data residency answer is whichever environment you deployed into.

Operator view

One dashboard.
Full operational picture.

Summary cards, work distribution, model readiness status, and issue-type volume. The operator sees what needs attention without switching between tools.

Open tickets and triage counts
Work distribution by status and priority
Issue type volume trends
Suggestion readiness per category

Readiness is the honest part: a category only starts producing suggestions once operators have corrected enough of them for the model to have signal. Until then the system stays quiet.

Latch dashboard showing open ticket counts, work distribution, suggestion readiness, and issue type volume
Unified triage queue showing incoming tickets from every channel with inline ticket detail
Unified triage

One queue.
Every channel.

Email, forms, operator-created tickets, and system alerts all land in the same queue. A shared inbox centralises the messages; unified triage also decides ownership, priority, and ticket routing before anyone starts typing.

Select a ticket to see the full context — description, settings, activity, and email origin — inline without leaving the queue.

Routing rules, SLA management, and the escalation policy hang off this screen. When an operator overrides a suggested route, the override is the signal the next suggestion is built from.

The ticket record

Everything about
the ticket.
One record.

Editable description, status controls, linked assets, issue data fields, plugin actions, activity timeline, and suggestions — all on one record. When someone asks "what happened?" the answer is already there.

Context
Description, data fields, tags, and linked assets
Actions
Plugin actions with role checks and logging
History
Full activity timeline with comments and status changes
Model
Suggested routing and next steps, which the operator accepts or overrides
Ticket record showing description, status controls, plugin actions, activity timeline, and linked assets
Asset inventory showing tracked equipment with status, site assignment, and operational condition
Assets and sites

Anchor work
to what it
touches.

Assets carry operational state, physical condition, site assignment, and linked work history. Sites group assets, tickets, and local context into one view.

Maintenance schedules turn asset classes into recurring work automatically — so preventive tasks do not depend on someone remembering to create a ticket.

Not every team needs this. A support desk with no field estate can ignore assets entirely and lose nothing.

Plugins

Connect your
systems as
actions.

Plugins connect the systems your team already uses — Stripe, your ERP, Slack, internal APIs. Each action runs from the ticket with permissions, role checks, and logging built in.

The model is a plugin on the same interface. Point triage at a commercial API with your own key, at an open-weights model on your own hardware, or at an in-house endpoint your team already runs. Swapping models is a configuration change, not a migration.

Named providers with explicit configuration
HMAC authentication and secret management
Enrichment triggers that fire on ticket actions
Discovery and execution endpoints per provider

Plugins are written in TypeScript or Go against a documented interface. The developer path covers the SDK, webhooks, and the permission model.

Plugin management screen showing configured providers with their endpoints and authentication
Request dialog showing transaction ID and action details submitted for second-person review
Two-person review · Step 1

One person
requests.

The first operator packages the action request — transaction ID, action type, target system — and submits it for review. The action stays locked until a different authorized user approves it.

Many teams say they have four-eyes control when what they actually have is a forwarded email. Two-person review (also called four-eyes control or maker-checker) is the enforced version: the system, not the etiquette, keeps the two people apart.

Two-person review · Step 2

Another person
reviews.

The approving user sees the full request payload — the action, the submitted fields, the requesting user. They approve, reject with a reason, or close without acting.

Separation
Requester and approver must be different users
Payload
Reviewer sees the exact request that will execute
Rejection
Denied attempts are recorded, not silently hidden

This is also where the gate earns its keep on model-proposed work. A suggested refund is still a proposal until a named person approves it, which is what makes it safe to let a model near the action at all. See approval workflows for threshold and reviewer configuration.

Review dialog showing the submitted request payload with approve and reject options
Ticket record after two-person approval showing the executed action and its audit trail
Two-person review · Complete

Action runs.
Proof stays.

After approval, the action executes and the result lands on the ticket. Who requested, who approved, what executed, and what the downstream system returned — all on one record.

The ticket now carries the complete control story: request, review, execution, and outcome. In a regulated function this is the case file, and it did not have to be assembled after the fact.

Audit · Execution history

Every action.
Every outcome.
Inspectable.

Every plugin execution is captured with its upstream request, downstream response, timestamps, acting user, and failure diagnostics. Operators debug live. Auditors review later.

Full request and response payloads preserved
Timestamps and acting user on every execution
Failure diagnostics for debugging and reprocessing
Successes and failures in the same ledger

The ledger is written to your database and exported by your team, on your schedule. Auditability covers retention, export formats, and what an evidence request actually needs.

Plugin execution history showing request details, response body, and failure diagnostics
What you would be running

Your queue.
Your model.
Your infrastructure.

Most systems that learn from your tickets require you to hand the tickets over, and to use the vendor's model to do it. That is the trade this one does not ask for.

Bring your own model
A commercial API with your own key, an open-weights model on your own hardware, or an in-house endpoint. Different models for different jobs is a configuration choice.
Runs on your infrastructure
On-prem, private cloud, or air-gapped. Ticket data, models, and identity stay inside the boundary, and data residency follows the environment you deployed into.
Learns from corrections
Every triage call, approval, reject, and correction is training signal. The queue sharpens where your operators corrected it, and the improvement stays where the data is.
Human review where it matters
Require a second pair of eyes before a refund runs or a vendor bank detail changes. Leave the low-risk actions ungated.
One queue, every channel
Email, forms, and system alerts into one help desk queue, with ticket routing, SLA management, and the escalation policy attached to it.
An audit trail that answers questions
Who approved, what changed, what was denied, and what the downstream system returned — on the record, not reassembled later.
Where this does not fit

Does every ticket need two-person review? No. Most queues need it on a handful of actions — refunds over a threshold, vendor bank-detail changes, production access — and nowhere else. And a small team with nobody to administer Postgres should probably run a cloud service desk instead. Self-hosting earns its cost when a residency rule, a regulator, or a customer contract forces the boundary.

Start with one workflow

Refund approvals, vendor changes, payment exceptions — pick one, run it end to end, and judge the model on that queue before moving the rest. Pricing is not per agent, so the second queue does not cost more to move.

Next step

Bring one queue and get a fit answer

You have seen the walkthrough. Bring the triggering issue, the downstream system, and the control requirement, and get a fit or no-fit answer on that one workflow.

Talk to us See pricing