The First Human Approved It. The Agent Was Still Not Authorized to Finish.

A workflow can now ask two different people two different questions before it is allowed to reach the same effect, and neither person's yes covers what the other one is being asked. That is the whole development, and it is worth being precise about it before reading anything larger into it.

What actually shipped, and what shipped earlier

Three Zendesk announcements have to be read together, in order, because each one only means what it means in light of the one before it.

On 6 April 2026 Zendesk began rolling out a Send approval request step for action flows: an admin could add a step to an automated flow that created an approval request, the same object a person could already create by hand on a ticket. That step fired the request and the flow kept running. Nothing paused.

On 13 May 2026 Zendesk integrated the action builder with AI agents. A configured agent gained the ability to invoke resources built in the action builder: custom actions directly, and action flows, which can themselves reach external actions and MCP connector tools. Zendesk scoped this narrowly even at launch. Only an action flow built with a Run on demand trigger can be invoked by an agent, and the capability initially belonged to customers on the AI agents Advanced plan as of 10 March 2026. An agent could now start a flow. It could not, on that announcement alone, be made to wait for anyone.

On 31 August 2026 Zendesk announced human in the loop and multi step sequential approvals. The Send approval request step can now be configured to wait for a response before the flow continues, rather than only creating the request and moving on, and a flow can carry more than one such step so that a later stage depends on an approval that has not yet happened.

The default did not move for every flow that already existed

Zendesk's own account of this change carries a distinction that is easy to miss and important not to. Every newly created Send approval request step defaults to waiting for a response. A step that was already sitting in a published, working action flow before this release keeps its prior behavior, continuing immediately, unless an admin opens that flow and edits the step to turn waiting on.

That is a meaningfully weaker claim than every action flow got a blocking gate on 31 August 2026, and this record is not going to make the stronger claim. The gate is real, and Zendesk made the safer choice the default for new work. Whether a given flow built before this release actually pauses for anyone depends on whether somebody went back and turned it on, and nothing in what Zendesk has published states how many existing deployments have done that.

Four outcomes, and timeout is not the same thing as no

A waiting Send approval request step resolves into one of four branches an admin can build separate paths for: approved, denied, withdrawn, or timeout. Zendesk's approval mechanism has, since before this release, described a bounded wait, documented at up to 30 days, after which an unanswered request times out. This record treats that ceiling as Zendesk's own prior documented figure rather than as independently reconfirmed for the general availability release, because the source describing it could not be directly refetched in the environment this record was written in.

The distinction that matters is that timeout is its own branch, not a synonym for denied. A flow author has to build what happens when nobody answers in time, separately from what happens when somebody answers no. That is a stronger design than silent approval, an unanswered request does not let the flow through by default, but it is a different claim from automatic denial, and this record is not going to collapse the two. An admin who wires the timeout branch to the same outcome as approval would recreate exactly the silent approval failure the blocking option exists to prevent, and nothing in the mechanism itself prevents that authoring mistake.

Sequential means each checkpoint answers only for itself

Because an action flow is an ordered sequence of steps, more than one Send approval request step can appear in the same flow, each one gating a different point along it. Zendesk's own example is a request that needs a manager's approval before it needs a separate, later approval from Finance or IT: hardware requests, or spend above a threshold, are the natural cases. The manager's yes and the Finance yes are two distinct authorization decisions, made by two people who may never see each other's response, and the flow's own branching structure is what determines when the second request is created at all.

Moona Intelligence's own reading of that structure, not a claim Zendesk states directly, is that a later Send approval request step is only reached, and its request only created, once execution actually arrives there along the branch the earlier approval opened. Two requests belonging to the same flow run do not sit open simultaneously waiting on two people at once, in the way a fan out to parallel approvers would; they arrive one after another because the flow itself is a sequence, not a set. This follows from how action flows are already built rather than from anything new in the 31 August announcement, and it is stated here as an inference from that architecture, not as a separately confirmed fact.

That is the durable point this record exists to make. Authority, here, is not a single yes that covers a whole workflow. It is a sequence of distinct yeses, each one legitimate only for the transition it sits in front of, with a later, separate authority decision still required before the final effect is allowed to run.

Who gets asked is configurable, and the configuration is not new

An approver at a given step can be an explicitly named person, or a value Zendesk resolves dynamically from the workflow's own context, the clearest example being a manager field looked up from the requester's user record. That dynamic resolution mechanism is not new to this release; it is the same approach the original, single step version of approvals already used for routing a request to someone specified in a custom field. What is new is only that this mechanism can now sit at more than one point in the same flow.

Whether a group, rather than a single named or resolved individual, can be set as the approver at one of these sequential steps is not established by what this record could verify. The older, manually created approval system supports group approval; nothing corroborated here confirms that the automated, sequential Send approval request step inherits that same option, and this record does not assume it does.

What the approver actually sees, and what remains unknown

Zendesk's own framing of a Send approval request step ties it to the ticket the flow is operating on: the approver reviews an approval request in the context of that ticket, the same surface a manually created request already uses. What is not established, and is publication critical to say plainly, is whether the person approving a checkpoint that gates a later external action or MCP tool call sees the specific action, its target and its arguments that will eventually run once every remaining checkpoint clears, or only the ticket and the fact that the flow wants to proceed past this point.

That gap matters because it decides which of two claims this record is entitled to make. The stronger claim, exact action authority, would be that a human authorized this specific operation, on this specific target, with these specific arguments. The claim the evidence available here actually supports is narrower: a human authorized progression from one checkpoint in the workflow to the next. Call the first exact action authority and the second workflow transition authority. Zendesk's sequential approvals are, on the evidence available, workforce transition authority stacked more than once in the same flow, not proven exact action authority, and this record is not going to promote one into the other without a source that binds an approval to the literal downstream call.

Several further questions stay open for the same reason. Nothing in what is available here states whether an admin editing the containing action flow while a request sits pending resumes the paused execution into the edited version, keeps it on the version it started under, invalidates the pending approval outright, or fails; nothing states whether a variable feeding a later external action can change while an earlier step's approval is still pending; and nothing states whether the audit trail that logs an approval's creation, approver, response and timing also links forward to the specific external action or MCP tool call that ran because of it, as opposed to recording the two as separate events an investigator would have to correlate by hand. Each of these is marked unknown rather than answered by assumption.

The agent side of this, held to its own boundary

None of this reaches every action a Zendesk AI agent takes. The 13 May 2026 integration is explicit that an agent can invoke custom actions directly and action flows, and reach external actions and MCP connector tools only through those flows, and only flows built with a Run on demand trigger. An agent action that never touches a configured action flow does not acquire an approval checkpoint because this release exists, and this record makes no claim that it does. What changed on 31 August is what a flow the agent does reach is now capable of containing: not one gate, but an ordered sequence of them, each requiring its own distinct human decision.

This is the same distinction Moona Intelligence has drawn before between an agent holding the technical reach to call something and an agent holding the authority to execute the approval step itself. Zendesk has not made an agent capable of approving its own request; a human still has to be the one who answers. What it has made possible is a workflow where an agent's own progress depends on more than one human, at more than one point, agreeing separately.

Where this sits next to Sequence Authority and next to a single switch

Two existing Moona Intelligence records sit close to this one, and neither owns the thesis here.

Sequence Authority, as this desk has used the term over AWS's temporal policies and the Bounded Agents research, is about whether a machine evaluated policy holds state across a trajectory of actions an agent itself chose at runtime, checking a later call against what already happened in the same session. Zendesk's sequential approvals are a different mechanism entirely: the steps and their order are authored by an admin in advance, not discovered by the agent, and what carries state across the sequence is a person's decision, not a policy engine's session memory. The two are siblings in the same larger pattern, that a single action's legitimacy can depend on what came before it, but they are not the same claim, and this record does not fold one into the other.

DataHub's Ask DataHub raised a different, narrower question: who is authorized to flip the single switch that decides whether any write gets a human's yes at all. Zendesk's sequential approvals do not answer that governance question either way; nothing here establishes who may add, remove or reconfigure an approval step in a published flow, and this record does not claim that gap is closed.

What is genuinely new here is a third distinction, sequential organizational authority: not one approver over one action, and not a policy administrator's single switch over whether approval applies at all, but more than one independent human grantor, each answering for a different transition, whose separate decisions have to accumulate in order before a later effect is allowed to run.

Authority Provenance, held to what the evidence actually supports

The immediate grantor at any one checkpoint is the named or dynamically resolved approver Zendesk presents the request to. What establishes that this particular person is the correct authority for that checkpoint is the admin who authored the action flow and chose that approver or that lookup field; nothing in what Zendesk documents verifies that the resolved person actually holds the organizational standing the flow assumes they hold; a manager field pointing at the wrong person routes the request to the wrong authority just as easily as to the right one. The operational mandate an approver sees is the ticket and the request in front of them, not a separately signed statement of why they are entitled to decide it. Delegated scope is real and concrete at the level this record can verify: an approval clears the one transition its step gates. It is not established to extend to the specific downstream external action, target or arguments that a later, unchecked step might carry out once the last approval clears.

Revocation exists asymmetrically. A pending request can be withdrawn by an admin or a permitted agent, and Zendesk's approval requests are immutable once created, a change means withdrawing the original and creating a new one rather than editing it in place. Whether a later approval in the same sequence can override or supersede an earlier one, and whether steps already executed before a later denial remain committed rather than rolled back, is not established here; the pattern elsewhere in this corpus, that stopping a sequence before its next step does not undo what already ran, is the working assumption until Zendesk's own material says otherwise. Challenge authority is present in a narrow, real form: a workflow that reaches a blocking checkpoint has, by construction, paused for an external human decision it cannot make for itself, and a sequence with more than one such checkpoint has more than one independent point where that challenge can occur. Recovery from a denial, a withdrawal or a timeout is whatever branch the flow's own author built for that outcome; there is no generic rollback of whatever the flow already did before it reached the gate that stopped it.

What this record is not saying

This is not a claim that every Zendesk AI agent action now waits for a human. It reaches only flows built with a Run on demand trigger that an agent is configured to invoke, and only the steps inside those flows an admin has actually built as Send approval request steps. It is not a claim that every action flow already in production acquired blocking approval on 31 August 2026; the safer default applies to newly created steps, and an existing step keeps continuing immediately until someone edits it. It is not a claim that a timeout is a denial; Zendesk's own architecture treats it as a separate branch an author has to handle deliberately. It is not a claim that an approver at one checkpoint sees the exact downstream action their approval will eventually permit; the evidence available supports workflow transition authority, not proven exact action authority. And it is not a claim that this record independently reconfirmed every mechanical detail of the 31 August announcement by direct means: the announcement itself could not be refetched in the environment this record was written in, and its specific mechanics are carried here as Zendesk's own stated claim, corroborated by its documented consistency with the two adjacent, independently verifiable announcements either side of it, rather than by an independent second reading of the same page.

The question that is left

An approval used to mean one thing: somebody looked at this and said yes. A workflow that requires more than one of them, in order, changes what a single yes is worth. It no longer certifies the outcome. It certifies that the process may take its next step, and that a separate person, later, still has to certify the one after that.

The question worth asking of any workflow built this way is not whether it has an approval step. It is whether anyone has written down what each approval in the chain actually covers, and whether the last one in the sequence is the one that was supposed to matter most.