The weak comparison says Zendesk cannot handle approvals. It can. The useful question is whether the team needs a recorded ticket decision or a control that also blocks an external action and preserves what that system returned.
Use native Zendesk approvals for straightforward ticket-level review. Evaluate a dedicated control path when the approval must govern a downstream action, enforce the same boundary for human and MCP callers, run on-premises, or retain execution evidence on the ticket.
Product details and sources reviewed 20 August 2026.
Zendesk can create approval requests on tickets, assign approvers, track approved or denied outcomes, prevent closure while a request is pending, and expose approval status for reporting.
Latch Workflow places the approval around a plugin action. The action is discovered inside the ticket, cannot run until the control passes, and returns the external response to the same audit trail.
Each row starts with the job a team is trying to complete. The final column states what that difference means in practice.
Tracks the request, approver, status, comments, and decision on the ticket and in ticket events.
Tracks the request, maker-checker decision, denied attempts, and linked plugin action on the ticket.
Both products can keep a real approval record. The distinction is not whether an approve button exists.
A pending approval request prevents the ticket from being closed until it is answered or withdrawn.
The plugin action itself does not execute until the required approval exists.
Choose based on the controlled object: ticket closure or the downstream action that changes another system.
Action flows can send approval requests. Waiting for the outcome and branching is currently documented as early access.
Eligibility, inputs, approval, execution, and returned outcome belong to the plugin lifecycle.
Confirm the exact Zendesk feature stage and plan before designing a process around it.
Action flows and custom actions can reach external systems; retained result evidence depends on the configured flow and action.
The plugin writes the downstream result and failure state back to the ticket as part of execution.
If an auditor needs the processor or ERP response, test that evidence path end to end rather than assuming the approval record proves execution.
Runs as part of the hosted Zendesk service.
Can run on-premises, in a private cloud, or air-gapped with models and plugin credentials inside that boundary.
This becomes decisive when policy requires the ticket text and execution path to remain on infrastructure the organisation controls.
Zendesk approvals are the shorter path when a named approver, tracked status, comments, notifications, and reporting satisfy the requirement.
Evaluate Latch Workflow when a refund or system update must remain blocked until approval and the downstream response must return to the ticket.
Zendesk can remain the high-volume customer-support workspace while Latch Workflow runs the regulated or back-office queue where execution evidence matters.
Latch Workflow does not treat the approval request as an isolated form. The same plugin covers action discovery, contextual inputs, review, execution, and the returned outcome, with AI and MCP using the same control path.
A plugin can decide when an action is eligible, collect its inputs, route it for approval, execute it, and return the downstream outcome to the ticket.
Models classify, extract, and suggest inside the same workflow. Operators accept or correct the suggestion, and the correction stays useful to that deployment.
An MCP client sees bounded tools and tickets. Its calls pass through the same role, policy, approval, and audit checks as a human action.
Tickets, models, plugin credentials, and action execution can stay on your own infrastructure, including private-cloud and air-gapped environments.
The ticket keeps the request, reviewer decision, denied attempt, execution timing, and external response instead of relying on a summary written afterwards.
Eligible actions and their inputs appear in the ticket itself, so contextual hooks can use the ticket state without sending the operator to another admin tool.
Does every Zendesk approval workflow need Latch Workflow? No. If the required outcome is a recorded ticket decision and the hosted deployment is acceptable, native Zendesk approvals are likely the better fit.
Product scope changes. These official pages supported the comparison on 20 August 2026.
Start with the native fit, then identify the point where approval must control an external action.
See reviewer gates, threshold rules, denied attempts, and execution history in Latch Workflow.
Understand why the ticket and approval record should stay together.
Separate the person preparing an action from the person approving it.
Compare the wider products across channels, deployment, migration, and plugins.
The useful answer depends on the operating job, the systems already in place, and the evidence the workflow must retain.
Yes. Zendesk approval requests are attached to tickets, sent to an agent or end-user approver, tracked through a decision, and exposed for reporting. A pending request also prevents the associated ticket from being closed until the approver responds or the request is withdrawn.
Yes. Zendesk announced in April 2026 that action flows can create approval requests with the Send approval request action. The separate step that waits for the outcome and branches the process is still documented as an early-access capability.
Zendesk currently documents one active approval request per ticket, up to 50 inactive requests, and creation only while the ticket is New, Open, Pending, or On-hold. Availability also depends on the Zendesk suite and plan.
It is often enough when the requirement is one ticket-level decision, a named approver, visible status, comments, and reporting. Adding another system would create more work without improving the control.
Latch Workflow becomes relevant when the approval must block a plugin action, apply the same authority path to human and MCP callers, run on-premises, and keep the downstream system response on the ticket as audit evidence.
See intake, AI-assisted triage, an in-page plugin action, approval, MCP access controls, execution, and the audit record in one walkthrough.