An approval comparison can lead a team to replace a system that already supports the review it needs. Start with the required workflow and check the current product behavior.
Zendesk has approval requests and action flows that can wait for a decision. It also supports sequential approvals. The choice should account for those capabilities before asking whether customer-controlled deployment or a custom action changes the requirement.
This article reviews Zendesk's official documentation on 3 October 2026. Product access, configuration and the exact connected action still need verification in your account.
Native requests keep the review on the ticket
Zendesk lets agents request approval from another agent or an end user. The request and response stay associated with the ticket, and approval status is available for reporting. A pending request prevents ticket closure until it receives a response or is withdrawn. Zendesk's approval overview.
That can fit a support request needing a lead's decision. Check the review information and available permissions before adding another system.
Action flows can wait and branch on the response
Zendesk's release announced on 31 August 2026, with rollout through 9 September, lets action flows pause for approval and continue according to the response. It also supports multiple sequential approval requests, including automated steps that wait for each response. Access requires action flows and approval requests. Zendesk's release announcement.
Configuration matters: existing approval steps default to continuing immediately; they need editing to wait. New approval steps default to waiting. A flow that continues early may therefore be a configuration issue rather than a missing product capability. Zendesk's step defaults.
A categorical claim that Zendesk only records approval after the work has run is inaccurate. Test the configured flow and its downstream operation.
Check access and limits against the real process
Zendesk documents up to 50 inactive approval requests per ticket. Requests can be created on new, open, pending or on-hold tickets, with role and help-center requirements affecting who can request or respond. Validate suite/plan availability and those permissions for your team. Zendesk's considerations and permissions.
For a refund example, identify the review step, the payment connector, the values passed and what happens after a denial or timeout. Several sequential reviews may fit Zendesk's current flows; do not assume a different product is required merely because more than one person must approve.
Where Latch may fit
Latch ticketing with approvals puts a maker-checker gate around a sensitive plugin action. The operator submits action fields, another eligible operator reviews them, and approved execution occurs as a separate step. The action requester cannot approve, reject or execute that same request.
The reviewer may also execute if permitted. Current settings provide no gate or maker-checker, with plugin defaults and per-action overrides, expiry and optional ticket-change invalidation. They do not provide an arbitrary sequential chain, quorum or monetary rule builder. Amount conditions need connected business logic.
A customer-built plugin connects the action to the downstream service and returns its reported result. Latch checks current permissions and action availability before execution and retains uncertain approved attempts for reconciliation. Approval remains distinct from successful completion of the external operation.
The feature guide shows these controls with synthetic product screenshots. Those are interface examples, not evidence of a live refund or a maintained connector for every payment service.
Deployment and extension can change the decision
Some teams need to operate the application within an agreed network or data-location design. Self-hosted Latch offers a customer-deployed option, with source access on Enterprise under commercial terms. The licence and support agreement determine permitted changes and their maintenance responsibilities.
Map configured mail, identity, storage, model and integration destinations before claiming the installation keeps every data path local. A disconnected production requirement needs a tested dependency and operating design. Customer-managed API keys do not make an external service part of your local installation.
These are reasons to evaluate deployment and extension choices. They do not establish that either product automatically meets a regulatory requirement.
Ask both products to demonstrate the same request
Use a synthetic refund and a test service. Record the configured product version and workflow, then inspect:
- The proposed values and the information available to the reviewer.
- The accounts allowed to request, review and execute.
- Whether rejection stops the intended downstream operation.
- The effect of changed permissions or changed work after approval.
- The operation sent to the test service and the result it returns.
- The investigation path after a lost response, including whether another dispatch is blocked or permitted.
- The deployment, extension and maintenance responsibilities your team must accept.
This is a vendor acceptance exercise, not a claim that both products implement those checks identically. Some evidence may live in the ticket, connector logs or downstream service; record where it is and who can retrieve it.
If Zendesk's configured workflow fits and its hosted model is acceptable, keeping the review there may be the simpler choice. Evaluate Latch when its supported ticket action controls, customer deployment and extension path address requirements your current setup does not meet.
See the full Zendesk approval comparison or use the deployment evaluation checklist to prepare the decision.