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 customer-deployed installation lets your team operate this workflow on its own infrastructure.
See how plugin actions connect to the ticket →Looking at approval based on total exposure as well as an individual request's score? See the planned value-at-risk policy
Connect the review to the queue and its evidence
Intake, ticket context, assignment, and a connected action give the review its starting point. See ticketing with approvals for the complete workflow and its illustrated transaction-reprocess example.
A customer-deployed installation runs on infrastructure your team operates. Ticket fields and custom actions let you adapt the workflow; Enterprise source access supports inspection and contractually permitted changes. Explore self-hosted ticketing and the configured data flow.
Already using a service desk? Compare current native Zendesk approval workflows against the reviewer and execution requirements you need to test.
Review the action 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 run the operation. An eligible operator other than the requester chooses to execute it; that person may also be the reviewer. Latch checks request state, expiry, roles, permissions, and current action availability, then uses the saved inputs with current ticket context.
- 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.
Inspect one saved request before deciding
In the fictional Northstar example, Maya requests a transaction reprocess and Daniel opens the saved fields beside the case evidence. The transaction reference and retry reason identify the operation being reviewed. The connected plugin supplies those fields and its business rules.
Daniel can approve or reject. Approval makes the request ready for a separate execution step; Maya cannot run her own request. If its submitted values need to change, a new request creates a fresh review point.
See the complete feature guide with product screens
Apply the same current gate to a custom connected action for another operation. Finance controls gives the review context; plugin actions explains how your integration supplies the operation.
Old approval must not authorize new work
An action 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 an operation 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 action 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 →Choose the deployment and control detail you need
Start with self-hosted ticketing or the complete approval workflow. The feature pages explain how independent review, action records and deployment controls fit together.
Evaluate your infrastructure, operating responsibilities and customization path.
Keep the incoming ticket, independent review and external result together.
Prevent the action requester from approving or executing their own request.
Review decision and execution records alongside the controls needed for independent retention.
Inspect identity, storage, integration traffic and operational responsibilities.
Bring email, forms and API requests into one ticket queue.
Apply ticket records, checklist reviews and configured approval actions to claims work.
What an auditor needs to see after a high-risk approval
Define the request, reviewer boundary, decision, and execution evidence a later review needs to inspect.
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.
A payment record still needs workflow context
Separate the payment evidence from the application history and the independent preservation controls your team requires.
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 submitted fields, and execution uses those inputs with current ticket context. Different submitted values require a new request. Enable ticket-change invalidation when a change to the case context should require another 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. Sequential approvers, parallel review groups, and a quorum are separate workflow requirements; the current gate provides one independent review.
Can the reviewer execute the approved action?
Yes, if they remain eligible. Review and execution are separate steps, but the reviewer may perform both. A third person is not required, and the action requester cannot execute their own approved request.
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 customer-deployed 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
Inspect a saved action request, independent review, and separate execution step. Then map the controls to the operation your team needs to connect.
Free workspace · 100 tickets · No card required. See what is included.