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.
- The key is a short name you can set yourself on some field types. It is readable, which makes integrations easier to maintain.
Where a key exists, prefer it. A configuration referring to a key still makes sense in a year; one referring to a fifteen-digit number does not.
Using it in a placeholder
Custom fields are addressed by ID in placeholders. That is why a macro or email template referring to a custom 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. This is the single most common cause of a rule that worked in testing and does nothing live.
Comments
0 comments
Article is closed for comments.