> ## Content Index
> Fetch the complete content index at: https://internalnote.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Prompting Action Flows with Admin Copilot
- URL: https://internalnote.com/prompting-action-flows-with-admin-copilot/
- Published: 2026-09-04T08:04:57.000Z
- Updated: 2026-09-04T08:04:57.000Z
- Description: Admin Copilot now supports Action Flows. Instead of building your flows by hand you can now describe what you need, and Zendesk's AI will build your flows for you!
- Author: Thomas Verschoren
- Tags: Action Platform, Admin Copilot

Customers want resolutions. Admins want to shape the knowledge, procedures and workflows that deliver them. Zendesk automates these two connected jobs.

The first is the resolution loop. A customer asks a question, and Zendesk uses knowledge, procedures and actions to work out what needs to happen. An AI Agent can retrieve information, follow a procedure, call an Action Flow and take action across Zendesk or a connected system.

The second is the learning loop. Admins inspect how those resolutions perform, identify gaps and improve the configuration behind them. They update knowledge, refine procedures, adjust routing, change automations or create new Action Flows.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Resolution-Learning-Loop.png)

For a long time, humans sat at the centre of both loops. Agents handled tickets from start to finish. Knowledge managers wrote and maintained the articles that supported those conversations. Admins built the triggers, routing rules and workflows. Analysts reviewed reports and turned them into recommendations.

That model is changing. AI Agents take on more of the resolution work. Agent Copilot works alongside agents while they handle tickets. Knowledge Copilot detects gaps and helps create new content. Analytics Copilot will help analytics teams find and understand insights. Admin Copilot already helps admins understand their setup, identify opportunities and improve the configuration behind it.

New this month is Admin Copilot’s ability to work with Action Flows. Admins can now describe a process in writing, and Admin Copilot will generate an Action Flow for them.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Roles2.png)

Humans owning the process is quickly shifting towards humans assisted by AI

# The Action Platform

## Resolve the question

Knowledge can answer a question, procedures can structure the interaction and actions can perform the work. A complete resolution often needs all three.

A customer asking whether an order can be returned may need an explanation of the refund policy. But Zendesk may also need to identify the customer, retrieve the order, check its age and payment method, confirm eligibility, issue the refund, update the ticket and explain the result.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/core-elements.png)

That process needs more than a reply. Procedures can define the conversation logic, but Zendesk also needs to gather context, apply business rules and process the refund.

Action Flows provide a way to execute those actions. They connect individual steps into a defined process that can run as part of a procedure handling a customer conversation, support a human agent or execute automatically when something changes in Zendesk. A flow can retrieve information from another system, check a business rule, transform data, update a ticket or custom object, create a task, request an approval or notify another team.

I explored these changes in previous articles, showcasing how Zendesk is moving from isolated triggers and hand-crafted integrations towards reusable processes that teams can call wherever a resolution needs them.

[Action Platform. The new way of automating ZendeskA guide to Zendesk’s shift toward the Action Platform, showing how defaults stay in triggers while routing, integrations, and workflow logic move into Action Builder and Custom Actions.![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/icon/internalnote_color@2x-19d8db1c-aab0-4b82-a234-5f7afdded201.png)Internal NoteThomas Verschoren![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/thumbnail/Banner---2026-01-Agentic-3-0d704a3f-b3b1-49d1-b438-17d2292262ec.png)](https://internalnote.com/automating-with-action-platform/)

[Building more powerful and connected Action FlowsNew Action Flow capabilities and connectors give AI Agents, Agent Copilot and background automations more ways to execute work across your business.![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/icon/internalnote_color@2x-e9d00102-de25-4a76-9ea0-9aa71d370c83.png)Internal NoteThomas Verschoren![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/thumbnail/Banner---2026-01-Agentic-861cee64-f089-4627-b597-0f3ec95be33a.png)](https://internalnote.com/more-powerful-action-flows/)

## Use the platform first

The breadth of the Action Platform does not mean that every problem needs an Action Flow. The first question should always be whether Zendesk already has a native capability for the job. Admin Copilot can help with that assessment. An admin may ask for an Action Flow or Custom Agent, but the better answer might be a trigger, an automation, Omnichannel Routing or another existing setting.

Action Flows and Custom Agents are not replacements for native Zendesk functionality. Use them to fill gaps, automate processes that span several parts of the platform and combine conditions that would otherwise become a wall of overlapping triggers.

Take ticket priority and routing. A simple rule such as “if a ticket comes from a Gold customer, set the priority to Urgent” may belong in triggers. But the process becomes more useful when Zendesk needs to look up the requester’s support plan, check whether it is active and then branch across several customer tiers. That’s where Action Flows come into focus.

An admin could ask Admin Copilot to build the following process:

> When a ticket is created, look up the requester’s support plan in our CRM. If the customer is Gold and the support plan is active, set the ticket priority to Urgent. If the customer is Silver and the support plan is active, set the ticket priority to High. For all other customers, set the priority to Normal. If the support plan is inactive, add an internal note to the ticket to alert the agent, and set the priority to Low.

The Action Flow handles the lookup and conditional logic. Once it sets the priority, it should stop. Omnichannel Routing already handles assignment through queues, skills, availability, capacity and priority. The flow should return the information the routing system needs and let the native routing capability take over.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Routing.png)

The same principle applies to Custom Agents. Use them when the product gap is reasoning: interpreting an unclear request, working through a non-linear process or deciding what to do based on information discovered during execution. Do not build a Custom Agent to recreate a native queue, trigger or routing rule simply because you can describe it in a prompt.

The Action Platform becomes more useful when it extends Zendesk instead of replacing it. Use triggers for simple updates, Omnichannel Routing for assignment, and Knowledge and procedures for answers and guided processes. Use Action Flows for multi-step logic, external actions, reusable business processes and the gaps that do not fit neatly into the native tools.

# From build to prompt

Building an Action Flow has always involved two different kinds of knowledge. An admin needs to understand the process the business wants to run, but they also need to understand how to express that process in Zendesk.

Knowing the business process is usually the more familiar part. Admins understand the customer, the team, the policy and the outcome the business needs. They know that a hand-off is inefficient or that a repetitive task should be automated.

The activation barrier comes from the second part. To build an Action Flow, an admin needs to understand how to configure its triggers, actions, conditions, branches and connections, then translate the business process into those individual components. They need to know how the platform works before they can use it to improve the way the business works.

This also creates a discovery problem. Customers cannot always answer the question “what can I automate today?” They know where the process is slow, where a team is doing manual work or where information is being copied between systems. They do not necessarily know which Zendesk feature belongs in the solution, or whether the process should use a trigger, a routing rule, an Action Flow or a Custom Agent.

Admin Copilot changes the starting point. The admin brings the business process, the goal and the context. They can ask what is possible, explore different ways to implement the idea and use written instructions to move from a requirement to a deployable configuration.

With the new [AI-powered Action Flow creation capability](https://support.zendesk.com/hc/en-us/articles/8855601898266-Creating-action-flows-to-automate-processes-across-Zendesk-and-external-systems?ref=internalnote.com), an admin can choose one of six starter prompts or write a request from scratch. Admin Copilot interprets the request and generates a full Action Flow, including the triggers, actions, conditions and connections needed to run the process.

The admin remains in control of the result. They can review the generated steps, change the logic or swap a connector before they confirm and let Admin Copilot build the flow. Once built, they can test the flow and activate it. If the process needs a data transformation, Admin Copilot can generate the JavaScript for a custom code step. If the flow requires a third-party connection that is not set up yet, Copilot can prompt the admin to complete the authentication step.

> This prompt-to-flow capability is available as an early access feature that eligible customers can activate in their instance.

This new capability changes the emphasis of the admin’s role. Admins are not giving up control of the configuration, but they are spending less time translating a known process into the construction language of a tool and more time exploring the options, checking the outcome and refining the experience. The admin defines what should happen, and Copilot helps build how it should happen.

That is a shift towards admins becoming Service Architects who design and improve the experience, rather than Technicians who need to manually assemble every technical component.

TWO DIFFERENT TYPES OF AI INSTRUCTIONS 

Zendesk uses written instructions in two different ways. Agentic procedures, including those used by Custom Agents, instruct the system how to reason over a situation. The AI Agent can interpret the input, analyse what it finds, write or summarise information and adapt its path while it works towards a goal.  
  
Admin Copilot uses written instructions to understand what an admin wants to build. It turns that request into a deterministic Action Flow with defined triggers, actions, conditions and connections. Custom Agents use prompts to reason at runtime. Admin Copilot uses prompts to create configuration.  
  
This distinction helps explain the products as prompting becomes more common across Zendesk. It is not a choice between the two approaches. A deterministic Action Flow can handle the fixed parts of a process and invoke a Custom Agent where the process needs interpretation or flexible reasoning. For a deeper look at the difference, read [Agentic versus deterministic approaches in Zendesk](https://internalnote.com/agentic-vs-deterministic-approaches-in-zendesk/).

## Prompt-built Action Flows

The six starter prompts give admins a concrete place to begin when they know they want to automate something but have not yet decided what to build. The current examples cover several common patterns: escalating urgent tickets, logging negative CSAT, merging duplicate tickets, detecting ticket spikes, extracting order details and provisioning hardware with manager approval.

An admin can also describe a process from scratch. Admin Copilot turns that written request into a draft Action Flow. The admin can review how the process has been interpreted, change the configuration where needed and continue refining the flow.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Action-Flow-Init.png)

The six starter flows Action Copilot prompts offer you.

Once the process matches the requirement, the admin can approve the flow and activate it. The result is still a visible, fully deterministic Action Flow. Prompting removes much of the manual setup work, but the admin can still inspect and edit the logic in the same way as any other flow.

# Examples

## Set the priority

The first example is a familiar one. It uses user-field data and conditional logic to set a ticket priority, while leaving assignment to the native routing system.

Imagine an account that stores customer support plans in a user field. That field contains the customer tier and whether the support plan is active. The admin wants to set ticket priority based on those values, but does not want to resort to a long list of triggers for every possible combination.

You can prompt Admin Copilot:

> When a ticket is created, look up the requester’s support plan in the user field Support Plan.  
> \- If the customer is Gold and the support plan is active, set the ticket priority to Urgent.   
> \- If the customer is Silver and the support plan is active, set the ticket priority to High.   
> \- If the support plan is inactive, add an internal note to the ticket to alert the agent, and set the priority to Normal.   
> \- For all other customers, set the priority to Low.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-A-2.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-A-3.png)

Admin Copilot can generate a flow that looks up the requester, retrieves the relevant support plan, checks whether it is active and branches according to the customer tier. It then sets the ticket priority and adds an internal note where required.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-A-5.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-A-4-1.png)

That’s the flow. It does not assign the ticket. Omnichannel Routing uses the new priority together with its queues, skills, availability and capacity rules to handle assignment.

This is where Action Flows builds on and expands the product and improves the admin experience. The basic priority logic could be handled by triggers, but the requester lookup, user-field check and several conditional branches make the process more involved. Instead of scattering those conditions across a long list of triggers, the Action Flow keeps the decision tree in one place and passes the result back into the native routing process.

## Run it on a schedule

Action Flows can also run on time-based triggers. Earlier versions could only run once a day. Hourly schedules now make it possible to check for changes throughout the day and act while the information remains relevant.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Schedule.png)

Consider a travel company with a Custom Object that stores its bookings. The object stores flight details, customer information and online check-in status. The admin wants to contact customers who are approaching departure but have not completed check-in.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Object-1.png)

For this demo I needed to create that Custom Object. Luckily, Admin Copilot now supports generating these too, so building the object took a single prompt.

Now, to build this automation, we can prompt Admin Copilot again:

> Every hour, search the Bookings custom object for customers with a flight departing within the next four hours who have not completed online check-in. Create a proactive ticket for each customer with the booking details.

Admin Copilot can generate a flow that runs every hour, searches the Bookings custom object, finds bookings with a departure time within the next four hours, checks whether online check-in remains incomplete and creates a proactive ticket for each matching customer.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-B-1.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-B-2.png)

The hourly schedule matters because the relevant window moves throughout the day. A daily run could miss a customer whose flight enters the four-hour window after the automation has already completed. An hourly run can find that customer while there is still time to help.

🐝

I ran into a bug where the entire flow gets build correctly, but I manually had to select the **bookings* object in the **search objects* step. A small annoyance, but easily fixed.

### Improving my flow

There is one operational detail to address before activating the flow. Running every hour against a four-hour window could create the same ticket more than once. After realising this issue, the admin can ask Admin Copilot to update the flow and check whether a ticket for that booking ID already exists before creating a new one.

That is part of the value of prompt-based editing. The first version of the process gets the team started, and the flow can continue to adapt as the team finds edge cases and the company’s processes change. What's cool here is that Admin Copilot even created a Custom Action in order to execute the search efficiently.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-B-3.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-B-4.png)

This same scheduling pattern could support upcoming appointments, delivery windows or other time-sensitive processes. A flow could search a custom object for appointments starting soon, identify customers who have not completed a required step and create a proactive ticket before the appointment becomes a problem.

## Act across systems

Action Flows are useful when a process needs to cross the boundary between Zendesk and another system. The external action does not always belong at the end of the flow. A connector can provide information in the middle of a process, helping Zendesk decide what should happen next.

For example, an admin could build a customer context enrichment flow that looks up the user and organisation, then updates the ticket with the relevant context. That information might feed a later condition, change the priority or give an agent more useful information. The connector is part of the decision, not just an escalation after it.

A different process might send feature requests to a development team. The process can start when Intelligent Triage identifies the topic, rather than waiting for an agent to add a tag manually.

The admin can prompt Admin Copilot:

> When a ticket is updated and its Intelligent Triage topic is New feature request, summarise the conversation and extract the customer’s feature request. Create a GitHub issue with the summary, extracted request and ticket link, then notify the development team in Slack.

Admin Copilot can generate a flow that checks for the Intelligent Triage topic `New feature request`, passes the conversation to an OpenAI step, summarises the conversation and extracts the feature request before creating the GitHub issue and notifying the development team in Slack.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-C-1.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2026/09/Demo-C-3.png)

The flow combines several types of work. Intelligent Triage provides the signal. The OpenAI step turns a long conversation into structured information. Jira receives the feature request, while Slack alerts the team that needs to act on it.

Admin Copilot also detects the need for the integrations. If GitHub or Slack is not connected, it can prompt the admin to complete the setup in the newly generated flow. For some types of integrations it might even show the Connect button right inline in the conversation.

# The promptable Zendesk

Generating Action Flows is part of a broader change in how admins work with Zendesk. 

As described earlier, Admin Copilot already helps admins inspect their setup and decide which changes to make. It can identify unused or overlapping triggers, show when they last ran and explain why they may need review. The admin can open the related configuration, edit or deactivate the rule and save the change. Copilot can recommend changes to the admin, but the admin remains in control of what changes.

Prompt-built Action Flows extend this interaction to more complex building blocks in Zendesk. This is the practical value of a more promptable Zendesk. Admin Copilot helps admins understand the current setup, identify what is missing and move from an operational problem to a configuration change. It does not optimise the account by itself today. But it makes the work of inspecting, designing and implementing improvements easier.

The prompt is therefore more than a faster way to build and configure Zendesk. It gives admins a way to explore the platform starting from the problem they are trying to solve. The relevant solution might involve triggers and automations, Omnichannel Routing, Knowledge, procedures, actions, connectors, Action Flows, Custom Agents or analytics.

The future vision goes beyond Action Flows, Custom Objects or the rest of the existing set of capabilities Admin Copilot has. Admins should be able to describe *anything* they want to improve and let Admin Copilot help them explore the relevant paths across Zendesk.

## Sign up for Internal Note

Turning Zendesk into practice. – A weekly newsletter written by Thomas Verschoren.

Subscribe 

Email sent! Check your inbox to complete your signup. 

No spam. Unsubscribe anytime.