One case. Approvals, actions, and proof in one place.
Your team probably handles sensitive actions across a mix of email, Slack, spreadsheets, and admin consoles. Someone approves in chat. Someone else runs the action in a separate tool. Three months later, nobody can reconstruct what happened. Latch puts the approval, the action, and the record on one case.
This page walks through what that actually looks like: one scenario, start to finish. Then it shows the difference between the old way and the new way, and explains how plugins connect Latch to the systems your team already uses.
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.
Connect the systems you already use. No custom integration code.
Plugins are how Latch talks to external systems. Instead of building custom integrations for every tool your team uses, you connect them through plugins. Each plugin receives case context, shows the available actions, and runs them with permissions and 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. Plugins give you a standard way to connect any system — with approval steps, role checks, and 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 things Latch adds to your workflow
You do not need all five on day one. Most teams start with a queue and one approval workflow, then add more as they grow.
One queue for everything
Email, forms, tickets, and alerts land in one place. AI helps classify and suggest next steps. Your team stops jumping between inboxes.
See unified triage →Approval steps that are actually enforced
Require a reviewer before a refund runs, a vendor change goes live, or a high-risk action executes. The system enforces it — not a process document.
See approvals →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 →Automatic proof of what happened
Who approved, what changed, what the external system returned, whether anyone was blocked — recorded automatically. No more reconstructing the story from screenshots and chat logs.
See audit trail →Connect external systems without custom code
Stripe, Slack, your ERP, internal APIs — connect them through plugins. Each plugin gets permissions, logging, and approval gates for free.
See developers →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. Ticketing systems track issues. Latch tracks issues and controls what happens next — who can approve, what external systems get updated through plugins, and whether the record holds up when someone asks "what happened?" It can replace a ticketing system or sit alongside one.
Do I need a big team to get value?
No. Latch is useful from day one for a 5-person ops team that needs approval steps and an audit trail. Start with one workflow and expand as your team grows.
How do plugins work?
A plugin connects Latch to an external system — Stripe, your ERP, Slack, an internal API. It receives case context, returns the available actions, and runs them when an operator with the right role approves. The request, result, and any failures write back to the case automatically. No custom integration code needed.
What is a "case" in Latch?
A case is the unit of work. It holds the original issue, evidence, operator notes, AI suggestions, approval decisions, the action that ran on the external system, and the full history. One record from start to finish.
What does "approval step" mean in practice?
It means the action cannot run until someone with the right role reviews and approves it. For sensitive actions, you can require that the approver is a different person than the one who prepared the case. Both the approval and any rejected attempts are recorded.
How is AI used?
AI helps with triage, classification, and surfacing context — it does not make decisions. Operators review AI suggestions and decide what actually happens. The suggestion and the decision are both recorded on the case.
How hard is it to set up?
Most teams go live with their first workflow in days. Pick one thing — refund approvals, vendor changes, customer escalations — connect the relevant plugin, and start using it. You do not need to redesign everything at once.
Pick one workflow and see how it works
Start with one thing — refund approvals, vendor changes, customer escalations — and see how Latch adds the approval step, connects the external system, and keeps the audit trail.