Ticket approval workflows that run on your infrastructure
Most teams already have approvals. The refund was approved in a chat thread, the vendor bank-detail change in a forwarded email, and the account closure by someone saying yes in a standup. Latch Workflow puts the approval step on the ticket (a case, if you work in a regulated function), checks the reviewer's role before the action runs, and records what was approved, what was denied, and what the downstream system returned.
Request → review → execute → record
AI suggests, the reviewer decides
AI can suggest the next step and pre-fill the request, but a person still decides when a sensitive action actually runs. The suggestion, the correction, and the decision are all recorded — and the corrections are what teach the queue.
Maker-checker enforced at the system level
For actions that require independent review, the person who prepared the ticket cannot approve it. Role separation is a hard constraint, not a policy reminder. See how maker-checker works →
The result goes back on the record
After the action runs, the ticket still tells the full story: what was requested, what was approved, what happened. That is what makes control real instead of theoretical. See the audit trail →
An approval gate is only as durable as the system holding it
A hosted help desk enforces approvals until a plan change, a vendor config update, or an admin in another region turns the rule off. The control is real, but it is not yours.
Latch runs inside your boundary: on-premise, private cloud, or air-gapped. Ticket data, identity, and the models that draft suggestions stay on infrastructure you operate, which is usually what makes this workable under data-residency rules. Approval thresholds and reviewer roles are configured by your administrators and changed by nobody else.
Read about self-hosted ticketing →Evaluating the approval step, or replacing the help desk
This page is the detail: how the gate works, what a reviewer sees, what happens on a denial. It assumes you are already looking at Latch and want to know whether the control holds.
If the question is broader — you are replacing a shared inbox or a service desk and approvals are one requirement among intake, ticket routing, SLA management, and escalation policy — start with the system view instead.
See ticketing with approvals built in →Follow the control path from intake to evidence
These pages work together: intake shapes the ticket, approvals gate sensitive actions, maker-checker enforces independence, security controls the deployment boundary, and auditability preserves the proof.
Enforce separation between the person preparing an action and the person approving it.
Keep decisions, blocked attempts, approvals, and action results on the same record.
Deploy where ticket data, identity, and the AI models you choose stay inside your environment.
Bring email, forms, alerts, and system events into one ticket queue before actions begin.
Questions about approval steps
Common questions about how Latch handles ticket approval workflows for sensitive actions.
What triggers an approval step on a ticket?
The action does. A refund above a threshold, a vendor bank-detail change, an account closure, or any action you mark as sensitive requires a reviewer before it runs. Everything below the threshold stays a normal ticket and moves at queue speed.
How are high-risk actions approved?
The system checks the reviewer's role and permissions before the action can run. If the operator is not in the right role, the action is blocked. The approval stays on the ticket instead of moving to email or chat.
How is role separation enforced?
Latch limits who can run each action based on their role. The person who prepares the ticket and the person who executes the action can be required to be different people. Both steps are recorded on the ticket.
What happens if an action is denied or unavailable?
Blocked and unavailable actions show up in the ticket history. The operator can see why it was blocked, and anyone reviewing the ticket later can see what was attempted and why it did not go through.
How are plugin actions reflected back into the ticket?
When a plugin runs an action on an external system, the result comes back to the ticket automatically, including any comments, status changes, or updates. The ticket stays the single source of truth.
What about maker-checker and four-eyes workflows?
Latch supports full maker-checker enforcement: the person who prepares the work cannot approve it. Role separation is enforced at the system level, not through policy. See the maker-checker page for details on how dual control works.
Who can change the approval rules in a self-hosted deployment?
Your administrators, inside your own environment. Latch runs on your infrastructure — on-premise, private cloud, or air-gapped — so approval thresholds and reviewer roles are not subject to a vendor config change, a plan downgrade, or a shared control plane you do not operate.
Does every ticket need an approval step?
No. Most tickets do not. Approvals are worth the friction when the action is hard to reverse, moves money, or has to be provable later. Applying them to routine work slows the queue and trains reviewers to click through.
Pick one sensitive action and see how the approval step works
Start with a refund, a vendor change, an account modification, or a customer escalation, and see how Latch adds the approval step, connects the external system, and keeps the record.