One platform for cases, workflows, and compliance-grade proof.
Your team probably handles sensitive actions across a mix of email, Slack, spreadsheets, and admin consoles. Approvals happen in chat. Execution happens in a separate tool. Three months later, nobody can reconstruct the decision trail. Latch is a case management platform that puts the governed workflow, the execution, and the immutable audit record on one case.
This page walks through what that actually looks like: one case scenario, start to finish. Then it shows the difference between the old way and the new way, and explains how plugins and the intelligence layer extend Latch without custom code.
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 custom integrations for every tool, you connect them through the plugin SDK. Each plugin receives case context, shows the available actions, and runs them with governed permissions and immutable logging built in.
The plugin sees the case type, the customer, the amount, and the context. It returns only the actions that apply to this specific case.
The operator sees the available actions on the case. 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 case 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 AI models — with governed approval workflows, role checks, and immutable audit logging already built in. Your team gets the integration without the integration debt.
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.
Ticketing tool
Ticketing tools handle intake and routing. They do not control which operators can trigger which downstream actions, do not enforce approval steps on sensitive work, and do not capture structured evidence of what Stripe or your ERP returned. Latch adds the approval steps and the audit trail to the workflow that ticketing already started.
Cases still arrive through the same channels. The difference is that sensitive actions run through approval steps and plugins instead of happening in a separate admin tool with a ticket note added later.
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 a single case record 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. There is no structured record of what was recommended versus what was actually done versus what was blocked.
The AI still recommends. Latch adds the control boundary: the operator sees the suggestion inside the case, decides whether to act, and the system records the recommendation, the decision, and the outcome on the same record.
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 into the case. 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.
Five capabilities in one case platform
You do not need all five on day one. Most teams start with a case queue and one governed workflow, then add more as they grow.
Intelligent case intake
Email, forms, alerts, and system events land in one case queue. Built-in intelligence classifies and routes automatically. Your team stops jumping between inboxes.
See intelligent triage →Governed approval workflows
Require a reviewer before a refund runs, a vendor change 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 case cannot approve it. Latch enforces role separation at the system level — no forwarded emails or Slack threads needed.
See dual approval →Immutable audit log on every case
Who approved, what changed, every denied attempt, what the external system returned — recorded in an immutable log. Compliance-grade by default. No more 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, custom ML models — connect them through plugins written in TypeScript or Go. Each plugin gets governed permissions, immutable logging, and approval gates automatically.
See developer SDK →Questions teams ask before they start
The most common questions from teams evaluating whether Latch fits their workflow.
Is this just a ticketing system?
No. Latch is a case management and workflow platform. It tracks cases and controls what happens next — governed approvals, plugin-driven execution, and an immutable audit log. It can replace a ticketing system, sit alongside one, or serve as the operational backbone for regulated workflows.
Can I deploy this on-prem?
Yes. Latch is designed to run inside your own environment — on-prem, private cloud, or air-gapped — so case data, AI models, and identity stay under your control. You can also start managed and self-host later.
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 ML models. Write them in TypeScript or Go. Each plugin receives case context, returns the available actions, and runs them with governed permissions and immutable logging built in.
What is a "case" in Latch?
A case is the unit of work. It holds the original issue, evidence, operator notes, AI-generated intelligence, approval decisions, plugin execution results, and the full immutable history. One record from intake to resolution.
What does a governed approval workflow look like?
The action cannot run until someone with the right role reviews and approves it. For sensitive actions, maker-checker controls require the approver to be a different person than the one who prepared the case. Both the approval and any denied attempts are recorded in the immutable audit log.
How does the intelligence layer work?
Built-in intelligence handles triage, classification, and context surfacing. Bring your own AI model or use the default. Operators review intelligence suggestions and make the final decision. Both the suggestion and the decision are recorded on the case.
How hard is it to set up?
Most teams go live with their first case workflow in days. Pick one thing — refund approvals, vendor exception handling, regulatory case management — connect the relevant plugin, and start using it.
Pick one case workflow and see how it works
Start with one thing — refund approvals, vendor exception handling, regulatory case management — and see how Latch manages the case, enforces the workflow, and keeps the immutable audit trail.