How to bulk update Zendesk users with external data

Written by
Jude Kriwald
Zendesk Consultant
March 21, 2023
min read

Table of Contents

View all guides


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

This is some text inside of a div block.

In this two-part article, we’ll explore why and how updating your Zendesk users en masse unlocks so many time-saving processes for you and your agents.

Experience the Ease & Confidence of NetSuite Customizations with Salto

Get Started with Salto

What if Zendesk was 4x less work?

Request a Demo ≥

Tips & tricks from Zendesk masters

Subscribe to our newsletter to learn how to customize Zendesk and keep your agents happy

This is a monthly email with educational content. No spam (we promise).


Imagine you’ve been administering a Zendesk instance for a few months. By then, depending on the scale of the organisation of course, you’ve probably received tickets from hundreds, if not thousands, of end-users (typically customers).

Each time a new end-user requests a ticket in Zendesk, a new user profile is made.

Whilst each end-user’s specific issue can normally be dealt with entirely within the confounds of a ticket, there are many instances where Zendesk administrators will want to make changes or create rules that are based on numerous end-users simultaneously, rather than the typical process of an agent responding to one end-user within one ticket.

For example, your business might have two tiers of customers; standard and VIP. The list of who is a standard customer versus VIP exists on your own database or spreadsheet separate to Zendesk.

Without getting this information into Zendesk, the opportunity to create separate processes or SLAs for VIPs, for example, is missed. Wouldn’t it be neat to build views specifically for VIPS, set stricter SLAs for them, or even create a unique CSAT process dependent on customer tier?

Our challenge then, is to find a way to tell Zendesk who is a VIP and who is not, and all in just a few clicks, rather than updating each end-user manually. Of course, we are using customer tier (standard versus VIP) simply as an example. Your customer data points (known as “User Fields” in Zendesk) can contain any type of data we want; location, language preference, associated account manager, phone number, free trial expiry date and so forth.

Getting Familiar with User Fields

Zendesk has, by default, several User Fields associated with each user. A user field is a data point connected to each user profile. Unlike the more commonly used Ticket Fields, which vary with each ticket, User Fields do not normally change based on ticket data, unless you create a separate process to do so.

Thus they are useful for storing information about, unsurprisingly, the user!

Whilst these default User Fields can be very useful, and can also be updated in bulk using the process described below, we might also find ourselves wanting to add our own custom User Fields to store information that Zendesk doesn’t naturally have a field for.

To continue with our example, we want to find a place to record whether each customer is a standard customer or a VIP customer.

We could easily do this using Tags but, as I discussed in more detail in my previous article, How to Construct Bullet-Proof Zendesk Views, asking agents to play with tags is asking for trouble down the line. Thus, we’re going to want to create our own user field with two simple options: Standard or VIP.

Creating a new user field

Within Zendesk, navigate to Admin Centre > People > Configuration > User fields, or https://YOURDOMAIN.zendesk.com/admin/people/configuration/user_fields . Click Add Field.

You’ll then see several options as to what type of User Field you can add.

Our use case is simple enough, we only have two options to choose from (standard or VIP), so we’ll go for a drop-down. We could of course go for a checkbox entitled “VIP” that is either ticket or unticked, but what if in the future we want to add a third membership tier? In that case, our binary checkbox would no longer be usable. A dropdown, however, can easily have another value added to it, so is more future proof.

We only need to fill in the Display name, Description (optional), and Values. The other fields are auto-filled based on those former fields. It’s worth taking note now of the Field key (“tier”, in our case), as we’ll need this later.

Note that, if you have many User Fields to add, you can use the Upload CSV option on the right.

Now, looking at any user within Zendesk, we can see our new customer tier field has been added below the default User Fields.

Now we have the space to indicate to Zendesk whether each customer is a Standard customer or a VIP customer.

An agent or admin can edit this field simply by visiting any users’ profile and selecting Standard or VIP. Like all User Fields, this data will remain associated with the user, rather than any tickets on which they are the requester. 

Get Started with Salto

Stop manually copying changes from sandbox to live instance

Request a Demo ≥

Tips & tricks from Zendesk masters

Subscribe to our newsletter to learn how to customize Zendesk and keep your agents happy

This is a monthly email with educational content. No spam (we promise).

In Part 2, we’ll cover how to update this field for all of our customers in one go, saving your team hours or even days of manual updating.

Written by
Jude Kriwald

Jude Kriwald first learned to administer Zendesk in 2015 and has been helping businesses improve their customer operations as a freelance consultant since 2018. Offline, he can be found making maps, paragliding or exploring remote places.

Written by