A ticketing system where the approval is part of the ticket
Most teams already have both. A ticketing tool for the queue and an approval process for the risky work. They live in different places. The ticket sits in Zendesk or Jira Service Management, the approval happens in a Slack thread or a forwarded email, and months later the story of who approved what is reconstructed from memory.
Latch Workflow puts the approval step on the ticket itself - or the case, if you work in a regulated function. The platform checks the role, applies the threshold, and writes the decision to the same record as the action.
One record, start to finish
A customer asks for a refund of 1,200. The ticket arrives by email, ticket routing assigns it, and the operator selects the refund action.
The amount crosses the configured limit, so the action does not run yet. It waits for an approver in the required role, who reads the ticket rather than a summary of it.
On approval, the refund executes in Stripe. What was requested, who approved it, and what the payment system returned all land on the same ticket.
If the approver rejects it, the rejection and the reason stay in the history. Nothing is quietly retried in a different channel.
Two systems, one process, and no single record of it
The help desk holds the request. The chat tool holds the decision. Neither one holds both, and the gap shows up in predictable ways.
A message in a channel is a comment about the work, not a gate in front of it. The operator can run the action before the answer arrives, or after a rejection, and the ticketing tool has no opinion either way.
The rule that says refunds over 1,000 need a second reviewer sits in a policy page. It is applied when someone remembers it and skipped when the queue is long, which is exactly when it matters.
They saw a paraphrase written by the person asking for approval. The evidence, the customer history, and the earlier attempts stayed in the queue the approver does not open.
A rejected request is asked again in a different thread until someone says yes. There is no record that the first answer was no, so no one can tell the difference between a clean approval and a third attempt.
Anyone in the channel can type "approved". Whether they were authorized to approve that action, at that amount, for that customer, is a question nobody asks until an audit asks it.
Answering "who approved this in March" means exporting chat history, matching timestamps against ticket IDs, and trusting that the export is complete. That is reconstruction, not a record.
The platform holds the action, not the process document
The refund, the entitlement grant, the vendor change: none of them execute until an approver in the required role approves. Attempts by operators outside that role are blocked and recorded. See how approvals work
Review is required by condition, not by habit
Amount, customer tier, action type, data category. Tickets under the threshold close on the operator's own authority so the queue keeps moving. Tickets over it wait, every time, without anyone having to notice.
Maker-checker for the actions that justify it
Two-person review (also called four-eyes control or maker-checker) adds one constraint: the approver cannot be the person who prepared the ticket. Self-approval is blocked by the system. See how maker-checker works
Four requests that should not run on one person's judgment
These arrive through the same intake as everything else: shared inbox, web form, internal service desk request, or a system alert. What changes is what happens between the decision and the execution.
Payment and reconciliation teams run the same pattern with different vocabulary. See the finance controls path for reversals, write-offs, and KYC cases.
The approval evidence never leaves your boundary
Latch is self-hosted. It runs on-premise, in a private cloud, or air-gapped with no outbound connection. Ticket data, approval decisions, identity, and the models that suggest routing all stay where you put them, which is what makes the control workable under data residency rules that rule out cloud help desks.
See the deployment and identity modelThe queue learns from what your approvers do
Every approval, rejection, and correction is training signal. The system learns which refund patterns your reviewers wave through and which ones they send back, and it stops surfacing suggestions your team never accepts. That learning happens on your tickets, inside your boundary, and the improvement does not leave with a vendor model update.
See how triage and routing learnDoes every ticket need an approval step? No.
Most of a help desk queue should close without one. A gate on a password reset adds latency to the SLA and buys nothing. Approval steps belong on the actions that move money, change access, alter customer data, or are hard to reverse. If a team has no such actions, workflow automation, ticket routing, and an escalation policy will do more for them than a review step will.
Holds the action until an authorized approver decides. Applies the threshold every time. Blocks self-approval where maker-checker is required. Records approvals, denials, and blocked attempts.
Make the decision. Guarantee the approver read the evidence. Replace the domain knowledge that tells someone a refund request is fraudulent. The judgment stays with the operator.
AI can classify the request, surface the customer history, and flag what looks unusual. The approver still decides, and the suggestion and the decision are recorded separately. See the audit trail
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.
Route sensitive actions through role checks and approval gates before they run.
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 ticket approval steps
Common questions from teams that run a ticketing tool and an approval process in two different places.
What does an approval step on a ticket actually enforce?
The action does not run until an approver in the required role approves it. The check happens in the platform, not in a process document. If the operator is not in the right role, the attempt is blocked and the block is recorded on the ticket alongside everything else that happened.
How do approval thresholds work?
Each action carries the conditions that require review: an amount, a customer tier, an action type, a data category. A refund under the threshold runs on the operator's own authority. The same refund above it waits for a second person. The threshold lives in the workflow configuration, so it applies every time rather than when someone remembers it.
How is this different from approving in Slack or email?
A Slack approval is a message about a ticket. It does not stop the action from running, it does not check the approver's role, and it lives in a channel that can be archived or deleted. An approval step on the ticket is the gate itself: the action cannot execute without it, and the decision is stored on the same record as the action result.
What happens when a request is denied?
The denial is recorded with the reason and the reviewer identity. The requester can revise and resubmit, and both the denied attempt and the resubmission stay in the ticket history. Denied attempts are usually the most useful evidence a reviewer can produce, because they show the control was doing something.
Is this the same as maker-checker?
Maker-checker (also called four-eyes control) is the stronger form of the same control. A plain approval step asks whether an approver said yes. Maker-checker also requires that the approver is not the person who prepared the ticket. Latch enforces that separation at the system level, so self-approval is blocked rather than discouraged.
Does every ticket need an approval step?
No. Most help desk traffic should close without one. Approval gates belong on the actions that move money, change access, alter customer data, or are hard to reverse. Putting a gate on a password reset adds latency to the SLA and buys nothing.
Can approvals run on a self-hosted deployment?
Yes. Latch is self-hosted by default and runs on-premise, in a private cloud, or air-gapped. Ticket data, approval evidence, identity, and the AI models that suggest routing all stay inside your boundary, which is what makes the control usable under data residency rules.
Follow one approved ticket from intake to executed action
Pick a request your team already gates: a refund over the limit, a vendor bank-detail change, or a production access grant. The walkthrough shows the approval step, the role check, and the record it leaves.