Plan requirement
| Subscription | Any plan |
| Access | Admin |
The API, some apps and a few integrations need a field's ID or key rather than its name. Here is where both live.
Find the field ID
- Open Admin Center, then Objects and rules, then Tickets, then Fields.
- Click the field.
- The ID is the long number in the browser address bar, and is also shown on the field itself.
That number is what the API uses and what most integrations ask for.
Field key versus field ID
- The ID is a number Zendesk assigns. Every custom field has one, and for a custom ticket field it is the only handle there is.
- The key is a readable short name, and it exists on custom user and organisation fields.
That split is the thing to remember, because it decides what your placeholders look like. A user field can be written as a name you recognise; a ticket field cannot.
Using it in a placeholder
A custom ticket field is addressed by its ID: {{ticket.ticket_field_123}}, or {{ticket.ticket_field_option_title_456}} for the chosen option of a drop-down. A user field uses its key instead, as in {{ticket.requester.custom_fields.my_field}}.
That is why a macro or email template referring to a ticket field looks cryptic, and why moving a configuration between a sandbox and production needs care: the IDs differ between accounts.
Sandbox IDs are not production IDs. Anything built in a sandbox that refers to a field by number has to be checked when you deploy it. Skip that check and the rule works in testing and does nothing live.
Comments
0 comments
Article is closed for comments.