An honest Zendesk approval comparison starts by correcting an old claim: Zendesk has approval workflows.
An agent can create an approval request on a ticket, assign an agent or end-user approver, and track the response. The pending request prevents the ticket from closing. The approval status can be reported. Since April 2026, Zendesk action flows can also create approval requests automatically.
For many teams, that is enough. Adding another control system would create more work without improving the decision.
This article reflects Zendesk's approval documentation and April 2026 action-flow announcement, reviewed on 20 August 2026.
Native approval is enough when the ticket decision is the control
Consider a support refund request. The agent needs a team lead to confirm that the refund is allowed before the ticket closes.
Native Zendesk approval is a good fit when the team needs:
- one active approval request on the ticket;
- a named approver;
- an approved or denied outcome;
- comments and notifications;
- visible status and reporting;
- the ticket to remain open until the decision exists.
That is a real workflow. It is stronger than a Slack message or forwarded email because the request and decision stay attached to the ticket.
The documented limits are design constraints, not gotchas
Zendesk currently documents one active approval request per ticket and up to 50 inactive requests. Approval requests can be opened while a ticket is New, Open, Pending, or On-hold, but not once it is Solved or Closed. Plan and suite availability also matter.
These limits are not evidence that the feature is weak. They define the process it is built to support.
A straightforward refund review can fit inside them. A multi-stage finance change with different thresholds, independent reviewers, retries, and a downstream ERP result may not.
The useful evaluation starts with the real workflow, not the length of the limitation list.
Where Latch Workflow fits: approval controls the action itself
The boundary changes when the approval must govern something outside the ticket.
In Latch Workflow, a plugin exposes the eligible action inside the ticket page. The same lifecycle covers discovery, contextual inputs, maker-checker review, execution, and the result returned by Stripe, the ERP, or an internal API. The plugin action does not run until the required approval exists.
That distinction matters because a recorded approval is not automatically proof that the external action matched the reviewed request. Ticketing with approvals explains why the request, review, execution, and outcome should remain one operating record.
Latch Workflow also applies the same authority path to an MCP client. An AI agent can propose or request an action, but its credential does not bypass role, policy, approval, or audit checks. The agent remains the actor in the record. The MCP and developer path shows how those tools stay bounded.
On-premises deployment changes the approval requirement
Some teams can use hosted ticket approval without qualification. Others cannot send the ticket, model input, plugin credential, or action payload outside infrastructure they control.
Latch Workflow can run on-premises, in a private cloud, or air-gapped. Native AI, plugins, MCP access, and the audit trail stay inside that deployment. A correction to AI triage can improve the local workflow without becoming training data for a vendor's shared service.
That is not a universal advantage. It matters only when the data-residency or operating policy requires it. If hosted Zendesk is acceptable, on-premises deployment should not decide the approval design.
The audit question is what happened after approval
Zendesk keeps the approval decision in the ticket record. That should be credited.
The remaining audit question is whether the record also proves:
- which action was reviewed;
- which inputs the reviewer saw;
- whether an unauthorised attempt was blocked;
- what exact payload reached the downstream system;
- whether the action succeeded, failed, or timed out;
- what the external system returned.
Latch Workflow keeps those events on the audit trail because they are part of the plugin lifecycle. The operator does not write a summary after switching back from another system.
Three decisions settle the fit
Stay with native Zendesk approvals when the required control is a ticket-level review and the hosted boundary is acceptable.
Evaluate a dedicated control path when the approval must block an external action, share authority with MCP clients, run on-premises, or preserve the downstream result as evidence.
Keep both when Zendesk remains the high-volume customer-support workspace and a smaller regulated or back-office queue needs maker-checker controls around plugin actions.
The full Zendesk approval workflow comparison maps those decisions side by side.
The operating rule
Do not add a control layer because native approvals sound ordinary. Add one only when the object being controlled changes.
If the control is the ticket decision, Zendesk may already be enough. If the control is the external action and its evidence, evaluate the whole execution path.