Building an action flow

An action flow chains actions and decisions into a sequence, so a whole task runs rather than a single step.

An action flow chains actions and decisions into a sequence, so a whole task runs rather than a single step.

Build a flow

1. Open Admin Center, then Apps and integrations > Actions > Action flows, and click Create flow. You can describe what you want and have it drafted, or build it by hand.
2. Choose what starts it. Every flow has exactly one trigger, and this is the decision the rest hangs off. A ticket event, a user event, a custom object or IT asset event, a Slack message, a schedule, an HTTP request from outside, or run on demand for an AI agent or auto assist.
3. Add the first step, usually an action that fetches something.
4. Add a Branch based on what came back, and the steps for each side of it.
5. Define what happens when a step fails. Under Error handling you can turn on Retry on error, and choose what happens if the retries also fail: Stop flow, Continue to next step or Follow error branch.
6. Test each branch.

Beside actions, the steps you can place are Branch, Repeat while condition is met, Repeat for each, Update custom variable, Custom code and Send outputs to copilot. The actions themselves come from three places: Zendesk's own, the external systems Zendesk integrates with, and the custom ones you built yourself.

A new flow is switched off

Flows are created inactive, and you activate them yourself. Check this before you go looking for the reason a finished flow never runs.

Design the branches first

On paper, before touching the builder. What are the possible outcomes, and what should happen in each? A flow built step by step in the interface tends to handle the path you were thinking of and nothing else.

The branches that get forgotten are the empty result, the error, and the case where the customer is not who you assumed.

Keep flows short

Three or four steps is readable. Twelve with nested branches is a program, maintained in a visual editor, that somebody else will have to understand under pressure. The ceiling is 60 steps a flow, raised from 50 on 3 September 2026; you will still find the old 50 in Zendesk's own documentation, which has not caught up everywhere. How many flows you may have is documented twice and differently, as 25 or as 100, and that one is unresolved. None of it matters much in practice, because the line where readable ends sits an order of magnitude earlier.

Where a flow is getting long, that is usually a sign the task is not a good candidate for automation, or that it should be split.

One condition per branch

A branch step evaluates a single condition, so a decision that needs two tests needs two branches in sequence. Take that into account while you are still drawing the flow on paper, because it changes the shape rather than the wording.

Two more constraints belong to the same planning moment. You can connect only one instance of each external system. And Zendesk's own actions do not count against your API rate limit while custom actions do, which is what decides whether a busy flow competes with your integrations.

Be careful with the writing steps

A flow that reads is easy to reason about. A flow that changes something, especially one an AI agent can start on its own, deserves an explicit decision about what it may and may not do without a person.

Test the unhappy paths

Every branch, including the failure ones. The happy path is the one you built and the one that works; the others are what customers will meet.

See also

• Advanced action flows
• Testing actions in the action builder
• Approval requests in action flows