> ## 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.

# Leveraging Custom Ticket Fields in Action Builder
- URL: https://internalnote.com/leveraging-custom-ticket-fields-in-action-builder/
- Published: 2025-05-20T08:00:14.000Z
- Updated: 2025-09-08T06:40:29.000Z
- Description: 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.
- Author: Thomas Verschoren
- Tags: Platform

Zendesk’s new Action Builder brings modular, logic-based automation to support teams. This guide builds on last week’s introduction and shows how to enrich your flows with ticket field data via the API.

[From Triggers to Flows: How Action Builder Automates the Support ProcessZendesk’s Action Builder introduces visual, logic-driven automation flows to replace complex trigger setups. This article explores how Action Builder simplifies business rules, integrates with external platforms, and signals a shift from reactive to process-oriented CX in Zendesk.![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/icon/internalnote_social_eggshell@2x-97.png)Internal NoteThomas Verschoren![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/thumbnail/fb-deviceinfo-1-11.png)](https://internalnote.com/preview-action-builder/)

Action Builder is currently in EAP meaning that, although feature rich, it's still in development and some features and capabilities are still missing.

Zendesk has outlined a rough roadmap of planned improvements in the article below. One of the most important additions will be native access to custom ticket fields.

[Planned improvements to the Action Builder EAPDuring the Action Builder EAP we will roll out additional features that address product limitations and enable more complex and diverse automation use cases.To smooth out updates we intend to relea…![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/icon/zendesk-favicon-24.svg)Zendesk 도움말![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/thumbnail/01JKBNJZDSSJ475MR1VM37VWT8-9)](https://support.zendesk.com/hc/ko/community/posts/9149896126490-Planned-improvements-to-the-Action-Builder-EAP?page=1&ref=internalnote.com)

In my article I described an example flow that leveraged a value stored in a ticket field to retrieve data in an external API. I purposefully glanced over the details of that step since I thought that concept would be better positioned in a dedicated article.

So that's exactly what we're going to do here.

# Available action types

Action flows have three kinds of steps. 

1. **Native ticket actions** (update status, add comments, etc.)
2. **Prebuilt integrations** (Slack, Google Sheets, Jira)
3. **Custom actions** (HTTP requests with parameters and output)

Custom Actions use the same engine that powers [Agent Copilot](https://internalnote.com/deep-dive-into-zendesk-agent-copilot-actions-and-procedures/). They can call any HTTP API, with input parameters and mapped outputs.

While native steps don’t expose custom fields yet, you can access them through custom actions that call the Zendesk API. This unlocks dynamic branching, ticket enrichment, and more contextual automation — all without code.

# Creating a Custom API Action

## Authentication

The first thing we need to set up is an API connection to store our credentials. 

[Creating connections to integrate with external servicesWhat’s my plan? Suite Team, Growth, Professional, Enterprise, or Enterprise Plus Quick Look: Admin Center > Apps and integrations > Connections >…![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/icon/zendesk-favicon-25.svg)Zendesk help![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/thumbnail/01JKBNJZDSSJ475MR1VM37VWT8-10)](https://support.zendesk.com/hc/en-us/articles/5040378297626-Creating-connections-to-integrate-with-external-services?ref=internalnote.com)

Start by creating a new API token under *Admin Center | Apps and Integrations | Zendesk API*. I always prefer a dedicated API Token per integration to keep a good oversight and to be able to revoke a token with minimal impact.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/Action-Builder-API-Connection.png)

Next, we can add that token to an API Connection. To do this, go to *Admin Center | Apps and Integrations | Connections.*

We need to add a new connection of type *Basic authentication*.  
The *username* is any admin account in your Zendesk instance, formatted as such: `admin@domain.com/token` and the *password* field is the API token you just copied.

As for the *Allowed domain*, enter `*.zendesk.com` or `your domain.zendesk.com` . I use a wildcard version so it works for all my brands.

## Creating and testing a custom action

### Creating the Custom Action

We'll create a new action under *Admin Center | Apps and Integrations | Actions*.

Under input we use a special variable called `zendesk_ticket_id` which retrieves the ID of our ticket.

The Request method is `GET` and the URL is formatted as `https://yourdomain.zendesk.com/api/v2/tickets/zendesk_ticket_id` with the latter part being the `zendesk_ticket_id` you add via the {+} variable button. 

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-1.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-2-1.png)

Remember to set the Authentication to the *API connection* you just added. You can leave the rest of the settings blank.

### Testing our custom action

Once we've set up the API connection, we can test it out. Make sure to have a Ticket ID at hand that contains example data in the ticket fields you want to retrieve.

Enter a Ticket ID and you'll get a list of all the ticket metadata. Expand the available elements and look for the *value* of the custom field you want to store. Click ‘Add’ to save the field as a named variable.

In this example, I mapped my Movie Title field as `movietitle` . I'd recommend mapping as many custom fields as possible though so you can reuse this one action across *all* your Action Flows. This avoids having to build a separate action for each custom field.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-3-1.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-4-1.png)

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-5-1.png)

# Adding our action to an Action Flow

Once your action is working and the output is mapped, you can start putting it to work in a real flow.

Do this by selecting our custom action as the next step. You'll need to add a value for our `zendesk_ticket_id` input variable we created earlier. Click the *add variable* button and select the `id` variable. This will pass the Ticket ID of the current ticket to our Action

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-10.png)

Once executed the output now feeds into subsequent steps. In this example, `movietitle` feeds into a step that fetches movie information.

Or to recap: our Action flow is triggered by a ticket creation. When the flow is triggered, we pass the ticket ID to a custom API call. This retrieves the full ticket object and stores relevant custom fields as output variables, such as `movietitle`. You can now use that data in branching, external API calls, or comments. 

Our next action uses that `Movie Title` to get info on the movie, which we can then use to add to a ticket comment, for example.

![](https://storage.ghost.io/c/ca/c0/cac0c82b-bc4d-4404-9eb4-9cc75e8d045e/content/images/2025/05/4-Action-Ticket-ID-7-2.png)

However, we can also use that *Get Ticket Fields* action in other places. If we use our action *before* we branch our flow, we can use the value of our ticket fields to decide if we *should branch or not*. In our flow we can only branch if there's a title present. Branches can also work with ticket intents an order number or any other custom ticket field.

# Conclusion

Now that your flows can access full ticket context, you can build far more dynamic and personalized automations.

You can extend this technique to other use cases. Instead of creating an action that does a `GET` on the Zendesk API, we could also create a specific action that does a `POST` request that stores a previous step’s output in a ticket field, such as the requester’s email or order number..

You can also use these actions to enrich what’s available as variables. Currently the *Lookup Ticket* step retrieves the organization, assignee and requester but only returns the `id` of these users. We could create three Actions that call the Zendesk API to `GET` the full organization or assignee/requester object via their respective `organizations/{{id}}` and `users/{{id}}` endpoints. Once we have that object we can set their name, email or custom fields as output parameters and use them in our flows.

We could branch based on the VIP state of an organization. Or we can use the Assignee email in our "Send a message via Slack" step. Now that we have all that data available, Action Flows become significantly more capable.