When I talk to customers about deploying Zendesk one of the elements I always note is that, out of the box, Zendesk works from the get go.

If you forward email, enable the web widget or link a social channel and add a few agents you basically have a working environment with zero code and in a matter of minutes.

Naturally even though you're able to receive and respond to customer conversations, that setup is far from productive. It lacks a configuration that is tuned to your business processes. To get the most out of your Zendesk setup you should, at least:

• Import your knowledge content to the Help Center
• Enable Intents (or add a category field) and setup Service Level Agreements
• Define your business rules via triggers and automations to categorize and prioritize tickets
• Setup agents, groups and routing via queues or triggers
• Train agents how to work in Agent Home and explain ticket statuses
• Setup CSAT

Zooming in on these core setup steps, one of the most tricky to setup is your business rules. They reflect your business processes and make sure that tickets are tagged correctly, that actions happen based on ticket updates and they can be used to automate a big part of the ticket lifecycle.

Traditionally setting up business rules meant diving into the world of triggers and automations. Condition based flows that take an input (ticket creation, ticket update), and execute actions like adding a comment, executing a webhook or changing ticket fields or statuses.
You can further tweak these triggers with conditions so they'll only run for specific ticket categories, forms or customer types.

Triggers (and automations) work great but any seasoned Zendesk admin knows the terror of opening an existing Zendesk environment and peaking into the triggers list. You're often greeted with dozens and dozens of triggers without any logic to them. Within those triggers you'll find complex conditions to include (or exclude) certain tickets without any obvious rhyme or reason.

Leveraging a structured category approach to your triggers is one way to see the forest through the trees. As I described in my article, I prefer a categorized approach that follows a normal ticket life cycle, starting with categorization, deflection, routing and notification triggers nicely grouped per type.

My approach to Zendesk Triggers

This article offers a deep-dive on how to structure and sort your Zendesk triggers starting from the concept of “one trigger does one job”

Internal NoteThomas Verschoren

But even though Trigger Categories create some structure, a crucial issue remains. Since triggers are rule based with linear conditions, and don't support nested or complex conditions, you often end up with multiple triggers to handle variants of the same use case.

For example if you want to set a low priority to bronze customers, normal priority for silver customers and a high priority for gold customers you currently need to create three triggers. Or four, if you also want to account for customers without any service contract applied to them.

The above is a simple example, but for each scenario where we want to apply a similar logic with different output to a set of tickets, we need to create multiple triggers. In scenarios where you want to make changes to those flows (eg sometimes you want to raise the priority for silver customers if they raise tickets about specific topics) you need to further branch out your triggers, and make sure to apply those changes to all triggers related to this rule set.

Action Builder

This is where Action Builder with its flows comes into play. Flows are similar to how Zendesk Bot and AI Agent Advanced have their dialogue builders to handle use cases.

They allow you to built a graphical representation of your business logic and combine all variations within a use case in one flow chart.

If we take our earlier trigger example and migrate it to Action Builder we can reimagine this flow as:

• Ticket is created
• We branch based on the customer type
• We have four branches for bronze, silver, gold and anything else
• Each branch contains a step to change the priority
• The silver branch has a further split based on ticket categories to set a different priority

One Action flow replaces five triggers and all our prioritization logic is combined in one readable flowchart.

What's key to note here is that Action Builder introduces logic-driven flows, where process is the priority. Where you could get away with dozens of triggers that all handle specific edge cases (and often you keep adding triggers to handle edge cases), Action Builder requires you to understand how things run today in your company, and build a flow based on that process.

Action Builder's setup clearly shows you all edge cases. If you built a branch for a certain condition, you automatically get a second branch for the else of that condition, forcing you to consider how you handle (or don't handle) those tickets.

If you don't know your processes, Action Builder won’t help—you’ll just automate chaos faster.

What is Zendesk Action Builder?

Zendesk Action Builder is a visual flow builder that allows you to create flows to update tickets and execute actions in external platforms based on changes on those tickets.

Currently we can trigger a flow when ticket is created or updated and when an Agent approves a suggestion Action with Agent Copilot's auto-assist feature.

Updates include any change to ticket fields, comments, customer satisfaction ratings, SLA schedules or Omnichannel Routing assignments.

Once a flow is triggered we can execute actions on our ticket. We can retrieve the full ticket context, we can update a ticket or create an entirely new ticket. This last one is especially useful for escalation scenarios to e.g. another team.

Updating tickets allows us to change system fields like assignee, priority, forms or status. We can add (internal) comments or change assignment of our ticket. It's (currently) not yet possible to update or read custom ticket fields, but that's on the roadmap.

Aside from native actions on Zendesk objects, we can also leverage prebuilt external actions. These can be steps that integrate with Google Sheets (add a row to a sheet), Jira (create or retrieve an issue), Salesforce or Slack (post a message).
More prebuilt integrations are coming, like e.g. Shopify or OpenAI.

Where the prebuilt integrations are an easy way to get started, the custom actions steps allow us to integrate with any platform that has an API. If these actions sound familiar, well, they are the exact same actions we use in Agent Copilot procedures. Nice to see how Zendesk is expanding the platform while reusing elements across multiple new features.

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.

Internal NoteThomas Verschoren

Anatomy of an Action Flow

An Action Flow contains a series of steps all linked together in a flowchart. A ticket enters the top of our flow and passes a series of steps and branches which update, create or execute elements until we reach the end of the flow.

Branches allow us to branch flows and split logic based on conditions. Once our flow reaches a branch it'll follow one of two sides of our flow. There's no looping back, there's no multiple branches (yet) and we can't merge our branches back together.

This also implies that we sometimes need to duplicate steps across branches (e.g. notify Slack) if these steps require info that's unique to our specific branch.

But even with this limited set of operations, Action flows allow you to simplify a lot of complex trigger logic and reduce the amount of triggers you would need to get your business rules into Zendesk.

Building an Action Flow

Creating an Action Flow is quite similar to how you would approach creating a Flow Builder flow in the classic Zendesk Bot. You start with giving your Action Flow a name and description.

This name is only used so you can identify your flows as an admin. Where Procedures or Actions in Agent Copilot use these elements to infer when they should be used, Action Flows rely on a trigger step to run.

When building a new Action Flow you can choose from two types of triggers. Ticket based triggers – which react to the aforementioned lifecycle, ticket field, SLA or other changes – or an Agent Copilot trigger which reacts to an agent approving a suggested action. In the future we'll also be able to react to user, organization or (maybe) webhook triggers.

The Agent Copilot step is a bit of a mystery to me. We can't pick which action, it seems to be any action. Bit weird, but I assume once we actually start using this in production environments the use case will become clear quickly.

Once you choose your trigger, we can add branches and steps to our flow to built out the logic. You can add new steps in between of other steps, but there's no rearranging or duplicating flows across branches.

Once you've built out your flow with your steps and branches, you can save, and activate your Action Flow. This immediately puts it live and your Action Flow will run for any applicable trigger.

Action Flow Examples

So far, we've spoken about the benefits of Action Flows and how you can use them. In this next section I'll highlight a couple of example flows that make use of a combination of Zendesk steps and external steps. I hope these give you some insight on how to use Action Builder!

Urgent Ticket Escalation

This first flow is a basic example of an Action Flow that reacts to tickets where the priority changes. If we detect an urgent priority we want to notify our team in Slack to take a look at the ticket.

You should not rely on agents solely using external notifications to work on tickets. In a healthy support environment your team lives in e.g. Zendesk and we make sure that's they see work to be done in Agent Home and we give them all the context and awareness within Agent Workspace. But in environments where the ticket queue and backlog is quiet, like e.g. a third line technical queue, or an escalation group for team leads, having these kind of external alerts can be useful.

In our flow we start with a Trigger that reacts to Ticket priority changed.

We then branch on ticket priority and if the priority is High, we act, otherwise we ignore the ticket.

For the high priority branch we then need to look up ticket details. We do this by passing a parameter id to the Look up ticket step. This will give us full ticket details like subject, description, status e.a.

We can then select the Slack action and choose the Post Direct Message step. In this step we can select a submitter (an email address), and fill in a message with a combination of text and placeholders.

It would be nice if we could select the email address of the current ticket assignee or current user, but for now these values are not (yet?) available, so we have to make due with a hardcoded email. I'd recommend creating a specific user in Slack that posts these updates.

Once we save and submit out trigger, we get the following result in Slack:

React to Incidents

A similar flow can be setup to react to IT related incidents. When a ticket type is changed to Incident, we can react to this change and fire an Action Flow that alerts our IT team in Jira via an Issue.

Setting up the flow starts with the Ticket Properties > Ticket Type changed trigger. We can then lookup all ticket information and add a branch. This branch can make sure our ticket type is incident before we move forward.

Once we know it's an incident, we can use the Jira action to create a new Jira issue for our ticket. Similar to the Slack action earlier, we can once again use a combination of text and parameters to fill in the issue title and description, while preselecting the right Project and issue type. Here too I'd like to use more detailed context like the current user email, but for now we, once again, have to hardcode an agent name.

After adding our Jira step we can then wrap up the flow with an Update ticket step. In this step we can add an internal note to the ticket that lets our agents know an Issue was created for this ticket and it adds the issue number to the comment for future reference. And to wrap it all up we can also put our ticket on hold until the IT team reacts.

Linking to the sidebar app

The current Jira integration does not actually link the ticket to the Jira issue yet. It just raised a ticket. To complete our Action we need to dive into the Zendesk API.

There's a POST endpoint to {{baseUrl}}/api/services/jira/links which accepts the following payload:

{
  "link": {
    "issue_id": "<string>",
    "issue_key": "<string>",
    "ticket_id": "<string>"
  }
}

Once Actions allow updating custom fields, we could store these three values we retrieve from the external action in custom fields and use a combination of trigger and webhook to create the link! But as of yet, this is not possible, an agent should manually link up the issue and ticket.

Ticket Tracker: Daily Sheet Entry

Aside from Slack and Jira we can also integrate with Google Sheets. This integration makes it possible to log specific ticket actions for reporting purposes in a Google Sheet.

In the example below I log every new ticket in a Google sheet with its id, creation date and assignee id.

Which results in the following spreadsheet:

The hidden secret of this Google Sheet action however is its capability of being a trigger for more powerful external automations. Since Google Sheets can also be integrated with tools like Zapier or Make, updates to a specific spreadsheet could serve as a trigger for flows in those programs.

For example, a user marked as spam could trigger a deletion of that user in your mailing list. Or a positive csat rating on a ticket could trigger you sending the customer an email with a discount voucher to thank them.

Leveraging Actions in your flows

Google Sheets in combination with Zapier is not the only way to trigger actions in external tools. We can leverage Actions (also used in Agent Copilot procedures) as an easy way to execute API calls in platforms and automate or retrieve data from those tools.

In this Action Flow below I'll use a combination of Actions to automatically send a customer information about a movie they're interested in by leveraging an Action that talks to IMDB, the Internet Movie Database.

To start our flow we will first add a trigger to react to a newly created ticket. We then branch our flow to check if our ticket is using the Movie Form by checking its id. If we are talking about movies, we can move forward, otherwise we do nothing.

The next step is retrieving some ticket information. Users submit their requests via a webform or AI Agent and we store their chosen movie in a ticket field. Action Flows do not currently allow us to retrieve ticket field values, but by leveraging Actions we can easily circumvent this.

We retrieve the movie title via our first custom action, and then pass the movietitle as a parameter to our Retrieve Movie Information action.

And to wrap up we add an Update ticket comment step to share the movie title, release data, summary and genre to our customer as a public comment.

READ MORE

Interested in learning more about how to interact with Custom Fields and Action Builder? Keep an eye out for next weeks' article!

If you're not yet a (free) subscriber: click the button below, you won't regret it!

Subscribe to the newsletter

Things to Watch Out For

As you've seen in the examples above, Action Builder is already quite capable of automating simple workflows.

This being an EAP in full development, there are however some limitations we should take into account in this early version of the product.

• Branches currently only support a single true/false split, and the conditions within that branch can only check for a single condition.
• There's no user information. No names, emails, organization names or other elements. You only get the ID
• There's no custom fields or tag logic. You can't set, get or delete these elements.
• External systems are limited to one instance each. So you can't share to multiple Slack channels or Jira environments.
• There's no access to side conversations of any kind
• You can't react or interact to custom objects
• You can only react to ticket changes or auto-pilot. There's no user, organization, custom object or external triggers that can fire a flow.
• There's no way to mark a flow as "run only once"

Leveraging Custom Ticket Fields in Action Builder

This article shows how to enhance Zendesk Action Builder flows by using custom API Actions to retrieve ticket and user data, including custom fields. It outlines how to connect, authenticate, and use this data to build smarter, more contextual flows—even before native support is available.

Internal NoteThomas Verschoren

But for me, currently, the biggest missing feature is the fact that we have no insights at all if and when an action flow ran. It's not visible in a ticket event timeline and there's no activity log on Action Flows. This makes it tricky to troubleshoot failing flows, and also gives you no insight in if and when they run.

Final Thoughts

Action Builder can be seen as both a big and small shift in Zendesk automation world.

It's small if you see it as a better way to setup the same flows we currently handle in triggers. It delivers a nice UI and more easy to understand flow chart to handle actions on tickets. If we look at Actions Flows as an iteration of triggers, we can see a clear path forward where triggers will gradually disappear from Zendesk.
Queues and Omnichannel routing removed a big part of their assignment job already. Intelligent Triage with its intent and entity detected do a similar job removing a lot of classification triggers. What's left are notifications, ticket lifecycle and automation actions. And I see the combination of Agent Copilot and Action Flows take over a big part of that job too.

However, If we take a step backwards you can already see that Action Builder is the beginning of a much bigger change in Zendesk world. When setting up complex flows becomes easier, it leaves room to actually think about why you setup an environment a certain way. And as the setup becomes easier to grasp (or change), it also becomes faster and easier to modify its behavior and tweak the environment as your needs evolve without risking a cascading set of conflicting triggers and changes.

AI Agents with their adaptive reasoning and procedures, Agent Copilot with its processes and actions, and now Action Builder with its flows, steps and actions are three examples of the same shift in mindset: Zendesk is evolving from reacting to events in small and isolated actions, towards designing processes that span Zendesk and beyond.

Setting up a successful CX environment no longer means looking at a ticket in isolation. It's about the entire process on how you handle a specific use case starting from the customer that reaches out via a channel. Our AI Agent detects the use case and deflects or escalates based on your defined process. Agent Copilot automates and assist Agents to resolve the ticket, again following your process. And Action Builder's flows are there to automate and escalate as much as possible, again via your predefined steps and conditions.