Approval workflow software for decisions you need to prove
A refund approved in chat leaves the decision separate from the work. Latch keeps the request, independent review, and execution result on one ticket, with maker-checker controls for sensitive plugin actions. Run it on your infrastructure and trace who approved what.
Request → review → execute → record
AI suggests, the reviewer decides
AI can suggest a next step, but a suggestion does not satisfy a maker-checker gate. An eligible person reviews the saved action request before it can proceed to execution.
Maker-checker enforced at the system level
For actions that require independent review, the person who submitted the action request cannot approve or execute that request. The server enforces this separation. See how maker-checker works →
The result goes back on the record
The ticket connects the submitted request and reviewer decision to the execution record. The result returned by the plugin shows the reported outcome; an uncertain result still needs investigation. See the audit trail →
Put the review rule on the action that needs it
A refund action can require independent review while a routine lookup remains available without a gate. Administrators set a plugin default and per-action overrides, then choose the request lifetime and whether ticket changes require a fresh request.
Your plugin supplies the refund operation and its business rules. Latch applies the configured gate, roles, and permissions around that action. A self-hosted installation lets your team operate this workflow on its own infrastructure.
See how plugin actions connect to the ticket →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 →Review the refund that will actually run
A reviewer needs more than an approve button beside a ticket title. The approval must identify the action, the submitted details, and the person asking to run it.
- 01 · Prepare the request
Save the action details for review
The operator selects a plugin action and submits its form from the ticket. Latch saves the submitted fields with the action, requester, request time, and ticket version.
- 02 · Inspect and decide
Check the saved fields before approving
Another eligible operator opens the review dialog and sees the action, requester, and submitted values. They can approve or reject the request and include an optional rejection reason.
- 03 · Run the approved action
Recheck permission at execution time
Approval does not automatically send the refund. An eligible operator chooses to run the approved action. Latch checks the request state, expiry, roles, permissions, and current action availability, then uses the saved request fields.
- 04 · Verify the result
Keep the decision and outcome together
The ticket retains the approval history and execution record. Review the result returned by the plugin to establish what happened after approval, including a failed or uncertain outcome that needs investigation.
Old approval must not authorize new work
A refund request may be wrong, become stale, or reach the external system without a clear response. Each situation needs a visible state and a deliberate next step.
Reject or cancel a pending request
The reviewer can reject a pending request and explain why. The requester can cancel their own pending request. Corrected details require a new request, so the review stays tied to what was submitted.
Expire or supersede stale requests
A configured lifetime limits how long a request can be used. Ticket-change invalidation can also supersede pending or approved requests before execution, requiring review of a fresh request.
Investigate uncertain execution
An executing or uncertain request does not become available for another click to run it again. Check the execution record and the connected system before deciding how to recover a refund with an unclear result.
Find the requests behind the approval count
Use approval-request reports to count requests created in a selected period and group them by status, action, requester, approver, or plugin. Open the underlying tickets to review the decisions and execution evidence.
Evaluate one refund from start to finish
Check that the requester cannot approve it, the reviewer can inspect the saved fields, and stale approval cannot be used. Then verify the execution result on the ticket. This tests the control your operators will use each day.
See how ticket audit trails support review →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. The claims use case shows the controls assembled end to end.
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.
See the controls assembled for claims work: checklist-driven file reviews, maker-checker, and upstream execution proof.
What an auditor needs to see after a high-risk approval
The request, reviewer boundary, denied paths, execution result, and policy context must remain attached to the case.
Roll out AI-assisted resolution behind a measurable approval boundary
Start with suggestions, define the actions that require review, and keep failure and override evidence from the first release.
Log the action request, the gate, and the returned outcome
Connect the reviewer decision to the execution attempt and the outcome reported by the downstream system.
An immutable payment record still needs workflow context
See why the payment file alone cannot explain who approved the exception, what was blocked, or why execution was allowed.
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 selected plugin action and its configured gate. Administrators can require maker-checker review by default for a plugin, then override the gate for individual actions. A refund amount threshold must be implemented in the connected action logic; the gate settings do not provide an amount-based rule builder.
How are high-risk actions approved?
An operator submits a request from the ticket. An eligible reviewer inspects the saved fields, then approves or rejects it. Approval and execution are separate steps. Latch checks roles, action permissions, and current action availability again before execution.
How is role separation enforced?
For maker-checker requests, the person who submits the action request cannot approve, reject, or execute that same request. Another eligible operator must review it. The separation follows the action requester, who may be different from the person who originally created the ticket.
What happens if an approval expires or the ticket changes?
Administrators set the request lifetime in minutes. An expired request cannot be approved or executed. With ticket-change invalidation enabled, a change to the ticket supersedes pending or approved requests before execution, so the operator must submit a fresh request.
Can a reviewer change the request while approving it?
The review dialog shows the saved request fields. Approval and execution use those submitted values. If the request needs different values, reject or cancel the pending request and prepare a new one for review.
How are plugin actions reflected back into the ticket?
Latch records the execution attempt and the result returned by the plugin. Supported plugin responses can also add comments or update the ticket. An approval records the decision; the execution record shows the reported outcome.
What about maker-checker and four-eyes workflows?
Latch supports maker-checker as an independent review gate on a plugin action. It is a fit for a refund or another sensitive action that needs a second person before it runs. Treat requirements for several sequential approvers or a quorum as separate workflow requirements to evaluate.
Who can change the approval rules?
Administrators configure plugin gates, request expiry, ticket-change invalidation, and execution roles. The action permissions determine which eligible operators can use an action. In a self-hosted installation, your team also operates the surrounding infrastructure.
Does every ticket need an approval step?
No. Apply the gate to actions that need independent review. Routine actions can use the no-gate setting while still passing the configured role and permission checks.
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.