
Deep dive into Zendesk Agent Copilot actions and procedures
This article walks through building a Zendesk Agent Copilot flow from scratch, using ticket fields, actions, and external APIs. It showcases a movie streaming lookup service, illustrating how to structure procedures, handle customer input, and automate workflows for a seamless support experience.
At the core of every customer and employee service process are instructions on how to handle specific use cases. They define which team of agents should pick up a specific use case, they provide logical steps for agents to go from inquiry to resolution, and they define specific milestones in the process that moves a ticket from customer to agent and back.
Where these processes used to be solely driven by human agents interacting with customers and tools, with the arrival of AI we've seen a shift from people doing a 100% of the work towards AI assisting human agents and taking over a lot, if not all, of the heavy lifting.

Where Zendesk AI Agents are the frontline that allow you to fully automate customer interactions and deflect a lot of inquiries, Agent Copilot sits alongside your human team. Auto-assist is there to provide suggested replies to agents based on a conversations' context, with actions interacting with external platforms and updating ticket metadata for the agent.
Thanks to Agent Copilot Zendesk has seen customer care teams triple their ticket efficiency, while improving CSAT at the same time.
But while we've seen plenty of marketing talk and high level examples of how Agent Copilot works, there's not a lot of simple examples available online on how to actually set this up in your Zendesk instance.
I've collaborated with Next Matter previously to link their platform to Agent Copilot and show you how Actions and Procedures can assist in complex financial and hr flows.

In this article I'll take a step back and build out an entire Agent Copilot flow from scratch. We'll interact with ticket fields, write a full Procedure and interact with multiple APIs via Actions, leveraging some of the new capabilities of Agent Copilot announced at Zendesk Relate 2025.
Let's dive in!
Flow
In this article we'll go over a full Agent Copilot procedure for a service that helps customers finding streaming options for movies they want to see.
The flow starts with asking the customer for their favorite movie. We then lookup information about that movie so we can be sure it's indeed that movie they are interested in.
Once the customer confirms it's indeed the right movie, we can lookup available streaming solutions for their movie of choice. Since the streaming ecosystem is fragmented across the world, we'll need to also ask the customer for their country of residence. This allows us to retrieve streaming options available in their country.
If we take this process and turn it into steps we'll get a flow like this:
- We ask the customer for a movie and country
- We lookup the movie and reply to the customer with some additional context about the movie
- If the customer confirms it's the right movie, we store that movie for future reference.
- We look up streaming options for that movie and send it to them.

Setup
Forms and Fields
In order for our flow to work we need to collect a couple of pieces of information from the end-user, namely their movie of preference and their country of residence.
If we just define these elements in our procedure, auto-assist will check if the information is available in the conversation, and if not, ask the customer to provide the information.
Since customers won't always provide the full context when submitting a ticket, we can speed up this process by leveraging ticket fields to ask the customer for this information. This way we can be sure we get the movie title and country immediately and can skip the step of asking the customer for this information.
In the scenario where the customer doesn't use our AI Agent or webform and just emails us, we'll have to fallback to asking for this information via a reply.



For this example article we'll use a webform, but we can also add these fields to an Ask for Details step in an AI Agent.

Actions
Now that we've taken care of the input, we can start setting up our Actions. Actions are the part of Agent Copilot that allow you to interact with external APIs to get and set information in other platforms in your company.
In our scenario we need to setup two actions. The first one makes an API call to retrieve information about the movie the customer requested info about. We can use their title to search for a matching movie, and then return the full details of the movie so we can be sure we're talking about the right movie.
Once we know it's the right movie, we can leverage a second action to retrieve the full streaming details for that movie based on the information we pulled from that first action.
Daisy chaining actions is a useful trick in Agent Copilot. You can for example first check if the provider order number and email of a customer matches, before you then use a second action to retrieve all items on an order to start a return process.
Retrieve movie information
Our first action takes the provided Title of a movie, and calls the OMDb API to retrieve movie information.

When setting up our action we need to provide an input. We define the input as "title: the title of the movie as provided by the customer". Agent Copilot is smart enough to understand that this can be the custom field with a matching title, or just text in the email. No need to link it to a ticket field or provide a ticket field id!
We can then enter the Endpoint URL of the API and provide some URL parameters to make our search query work.


Once we entered all the information, we can click the Get Output button to make a sample API call and retrieve movie information.
The OMDb API returns the following information:
{
"Title": "Blade Runner",
"Year": "1982",
"Rated": "R",
"Released": "25 Jun 1982",
"Runtime": "117 min",
"Genre": "Action, Drama, Sci-Fi",
"Director": "Ridley Scott",
"Writer": "Hampton Fancher, David Webb Peoples, Philip K. Dick",
"Actors": "Harrison Ford, Rutger Hauer, Sean Young",
"Plot": "A blade runner must pursue and terminate four replicants who stole a ship in space and have returned to Earth to find their creator.",
"Country": "United States, United Kingdom",
"Awards": "Nominated for 2 Oscars. 13 wins & 22 nominations total",
"Poster": "https://m.media-amazon.com/images/M/MV5BOWQ4YTBmNTQtMDYxMC00NGFjLTkwOGQtNzdhNmY1Nzc1MzUxXkEyXkFqcGc@._V1_SX300.jpg",
"imdbID": "tt0083658",
"Type": "movie",
}
http://www.omdbapi.com/?apikey=[yourkey]&t=blade%20runner



For our use case we need the following info:
Name | Description | |
---|---|---|
We can create these outputs by clicking the Add button in the Output pop-up that appears after testing our API. For each element we need we can provide a name, and a description. This description is used by our procedures to make sure it returns the right elements to the customer, or are used by subsequent actions to make sure they gather the right input.
The first outputs we define are used to provide the customer with the right context, like the full movie title, plot, release date and genre. The imdbid
is used as a fixed reference to the movie we can use in further API calls.
Retrieve streaming options
Once a customer confirms that "yes, this is the right movie" our procedure will call a second API to retrieve all available streaming options. This is done by leveraging the Movie of the Night API platform, which provided a free service to retrieve streaming options for a given movie.

What's nice is that even though we are using two different API platforms, our agents are none the wiser. That complexity is hidden from them.
Secondly, we can use output from our first API call, namely the imdbid
as an input for our second API action. We don't even need to use the exact same naming across the two Actions. As long as we describe the inputs clearly, Copilot will understand we're talking about the same pieces of data. We also need the value of our Country custom field we added at the start of this article.


Once we've setup our API we can once again use the Get Output option to test our Action. The Movie of the Night API returns the following data for our request:
{
"itemType": "show",
"showType": "movie",
"id": "290",
"imdbId": "tt0083658",
"tmdbId": "movie/78",
"title": "Blade Runner",
"streamingOptions": {
"us": [
{
"service": {
"id": "prime",
"name": "Prime Video",
"homePage": "https://www.amazon.com/gp/video/storefront/",
},
"type": "buy",
"link": "https://www.amazon.com/gp/video/detail/B0012PDVQ2/ref=atv_dp",
},
{
"service": {
"id": "netflix",
"name": "Netflix",
"homePage": "https://www.netflix.com/",
"themeColorCode": "#E50914",
},
"type": "subscription",
"link": "https://www.netflix.com/title/70082907/",
]
}
}
https://streaming-availability.p.rapidapi.com/shows/tt0083658?country=us
In our flow we are interested in streamingOptions
. You can add that entire element as an output. No need to dive into each underlying value and store it. Agent Copilot can read the array and parse it!


Procedure
Now that we've got our webform and fields to collect customer data, and actions to process that data, we need to write out a procedure to connect all the moving pieces.
Writing a procedure is very similar to how you would instruct your agents. You define the flow, you list the elements that are required, and you define the steps to take once you've got your input.

Our procedure
This process explains the steps to take to inform a customer on available streaming options for the movie they're interested in.
Movie
We look for the movie title the customer provided either in text or a custom field
If no movie is provided we should ask for one
Country
The customer also provided the country they live in text or custom field.
Eg United States or Belgium. It's always converted to a two character lower case country code, eg: us, be
If this is missing, ask for the country.
Provide movie info
Once we have this information useACTION Retrieve movie information
to get the movie information.
We reply to the customer with
Title (year - genre)
plot
We also store the IMDB ID in the ticket field.
We send this info to the customer and ask them to confirm it's this movie they want info for.
Provide streaming info
If they confirm it's correct, we can use theACTION Return available platforms
to reply with a list of streaming-options as returned by the API.
We can then solve the ticket
A few things to highlight:
- Even though I guide Agent Copilot to look for a movie title in a custom field, I don't need to define that fields ID explicitly.
- The same is true for storing the IMDB ID. We don't need to specify the exact output of our action, and we don't need to specify the ticket field id.
- "reply with a list of streaming-options" will make our array of streaming options and ✨magically✨ turn it into readable text for the customer
Result
Imagine my surprise to see Agent Copilot work from the first time. The customer flow you see below is the first time I run my procedure and it worked flawlessly 🤯!
Which says a lot more about the quality of Zendesk's product than my own skills. It. Just. Works.
Now that the entire setup has been configured, let's test this flow!
Our customer fills in a webform and inquires about Blade Runner.

A ticket arrived in Agent Workspace and Auto assist immediately proposes to retrieve information about the customers' provided movie.
The agent clicks approve and we get a Suggested reply with information about Blade Runner. Auto assist also proposed to fill in the IMDB ID field with the movies' id.


In my procedure I wrote the movie title as bold text and the comment the customer sees also retains that same formatting.
Once the customer confirms that yes, it's indeed this Blade Runner (and not the newer 2049 edition), our Agent can approve a second action that retrieves available streaming options for this movie in the United States.


Now, remember that streamingoptions
array I was so amazed about?
This was the input we gave our procedure:
{
"streamingOptions": {
"us": [
{
"service": {
"id": "prime",
"name": "Prime Video",
"homePage": "https://www.amazon.com/gp/video/storefront/"
},
"type": "buy",
"link": "https://www.amazon.com/gp/video/detail/B0012PDVQ2/ref=atv_dp"
},
{
"service": {
"id": "netflix",
"name": "Netflix",
"homePage": "https://www.netflix.com/"
},
"type": "subscription",
"link": "https://www.netflix.com/title/70082907/"
}
]
}
}
And this is the output: A cleanly formatted list of streaming options with pricing and links. Not bad for a one line instruction in a procedure right?

Conclusion
So, there you have it, a fully built-out Agent Copilot procedure that combines ticket fields, Actions with external APIs, daisy chained actions that pass output and input, and rich formatting of returned API data to the customer, while also updating ticket metadata.
We can take this further by not only looking at custom fields, but also using elements like the ticket id, customer information or tags in our procedure and actions. We could improve our procedure by setting the status of our ticket to Pending while we wait for the customer to confirm our movie choice. You name it.
But aside from the technical side of this setup, the most important part to remember is the process. We need to understand the order of steps first, we need to define where our data lives, and need to understand what defines "a movie" across different tools, before we can start building this.
The same goes for "real" procedures for actual use cases. If you want to build a Procedure that handles an order for a customer I suggest you take the following high level approach:
- Identify the Use Case: Clearly define the specific scenario or problem the procedure aims to address.
- Outline High-Level Steps: Break down the process into major steps.
- Identify the customer and their order.
- Validate the provided information.
- Execute the necessary actions (e.g., process payment, update inventory).
- Define when you want to communicate back to your customer to ask for confirmation or inform them.
- Define Key Entities: Establish clear definitions for critical components:
- Order: Determine what constitutes an order. Which identifier will you use (e.g., order ID)?
- Customer: Decide how to identify a customer (e.g., email, name, customer ID).
- Make sure you have a way to collect this information. Either as user fields, ticket fields, or decide to just ask the customer for it.
- Enumerate Possible Scenarios and Errors: Anticipate different situations that might occur, including potential errors, and plan appropriate responses for each.
- Map Required Platform Interactions
- Identify all platforms and systems the procedure will interact with.
- Determine whether you can retrieve and update data in these platforms using the chosen identifiers for orders and customers.
- If not, reconsider and redefine your identifiers to ensure compatibility.
- Develop API Calls and Workflows: With a clear understanding of the process and system interactions, begin constructing the necessary API calls and workflows to implement the procedure.
- Write the procedure: Take steps 1-5 and turn them into a written procedure, making sure to link to your Actions where applicable.
So, what are procedure are you building next?