Zendesk User and Organization Fields
Ticket fields describe the request. Zendesk user fields describe who is asking, and they're the ones most teams leave empty.
Zendesk user fields and organization fields
A user field stores something true about one person: their preferred language, their loyalty tier, whether they are a named technical contact.
An organization field stores something true about the whole account: contract tier, renewal date, assigned CSM, region. If the answer is the same for everyone at the company, it belongs on the organization, not copied onto forty user records where it will drift out of sync.
Both use the same field types you already know from tickets, and both are created in admin settings rather than on the record itself. The types are narrower than ticket fields, so check what your account offers before you plan around one.
The key matters more than the name
Every user and organization field has a display name and a key. The key is what placeholders and the API use, and it is effectively permanent.
Use lowercase with underscores, and name the thing rather than the current implementation. plan_tier will outlive salesforce_tier_v2. It sounds pedantic until you migrate CRMs and find the old vendor name embedded in four hundred macros.
Getting data in
Empty fields are worse than no fields, because agents learn to ignore the sidebar. Four ways to populate them, roughly in order of how well they hold up.
Updating a user field over the API is a PUT against the user, with the values keyed by field key.
curl -s -u you@example.com/token:APITOKEN -X PUT \
-H "Content-Type: application/json" \
-d @user.json \
https://acme.zendesk.com/api/v2/users/35436.jsonAnd user.json:
{
"user": {
"user_fields": {
"plan_tier": "enterprise",
"renewal_date": "2027-01-31"
}
}
}Organization fields work the same way against the organizations endpoint, under an organization_fields object. For a bulk backfill, look at the job-based update endpoints rather than firing one request per user, or you will spend the evening watching rate limits.
What to do with them once they are full
Routing
Trigger and automation conditions can read requester and organization fields, so "enterprise plan goes to the senior queue" becomes one rule instead of a tag convention nobody maintains. SLA policies can key off the same values, which is usually a better place to put contract tiers than a ticket field an agent has to remember to set.
One caveat worth knowing: writing back to a user field from a trigger is not the same thing as reading one. Check what your account supports before you design a workflow that depends on it.
Personalisation
Placeholders reach user and organization fields, so macros and email templates can use them.
{{ticket.requester.custom_fields.plan_tier}}
{{ticket.organization.custom_fields.account_manager}}Placeholder syntax around custom fields has more than one accepted form, so confirm the current one in the Zendesk docs and test with a real ticket before you ship a template to customers.
Help centre segmentation
User segments can be built on tags and organization membership, which lets you show partner documentation only to partners. Where you need a field value to drive access, the common pattern is a trigger or sync that mirrors the value into a tag, because tags are what segmentation reads most reliably.
Keeping them honest
Fields that nobody trusts are worse than no fields, because an agent who has been burned once stops reading the sidebar entirely and asks the customer instead. Three rules keep that from happening.
Pick one owner per field. Two systems writing plan_tier isn't redundancy, it is a race, and the winner changes depending on which job finished last.
Put a date on anything time-sensitive. A renewal_date field ages gracefully. A renewing_soon checkbox is a lie within a month.
And review the list annually. A user field nobody has read in a year is clutter in every agent sidebar, all day, forever. Sidebar space is the scarcest real estate in the whole product, and it should hold the four things that change how an agent replies, not everything the CRM happened to have available on the day somebody built the sync.
Frequently asked questions
How do you create and populate custom user fields?
A Zendesk custom user field is defined in Admin Center and filled by an agent, an integration or the Zendesk user field API. Zendesk user attributes set that way are what make routing and segmentation possible.
What's the difference between a user field and an organization field in Zendesk?
A user field describes one person, an organization field describes the whole account. Anything true company-wide belongs on the organization so it stays consistent.
How do I populate Zendesk user fields automatically?
Sync from the system that owns the data, usually your CRM or billing platform, with a scheduled job hitting the users endpoint. CSV import is for the initial backfill only.
Can triggers use user fields?
Trigger and automation conditions can read requester and organization field values for routing. Writing back to a user field from a trigger is a different question, so check the current docs.
Can I show help centre content based on a user field?
User segments read tags and organization membership most reliably. The usual pattern is to mirror the field value into a tag and segment on that.
Know the customer, spot the repeat
When Zendesk knows who's asking, it gets easier to notice the same person asking the same thing again.
Start free trial14-day free trial. No credit card required.