The Lookup Relationship Field in Zendesk
A lookup relationship field in Zendesk stores a pointer, not a copy. That difference is why it beats a text field for anything that might change next Tuesday.
What a lookup relationship field in Zendesk stores
A lookup relationship field holds the id of another record. Not its name, not a snapshot of its details. The id.
When an agent picks "Acme Manufacturing" in a lookup field, Zendesk saves the organization id. Rename the organization tomorrow and the ticket follows along. Do the same thing with a text field and you have a thousand tickets carrying a name that stopped being true.
You can add lookup fields to tickets, users and organizations, and point them at users, organizations or a custom object type. The target is set when you create the field, and it is not something to change casually once records reference it.
Filters are the whole game
An unfiltered lookup on a busy account is unusable. Twelve thousand organizations in one dropdown helps nobody.
So every lookup field takes an optional filter, expressed as conditions on the target record. A field pointing at users can be limited to users in the ticket organization. A field pointing at devices can be limited to records whose owner matches the requester, or whose status is active.
Two habits worth forming. First, filter on something structural, such as an organization or a status, rather than something an agent types. Second, test the filter with a real end user account and not just your admin login, because visibility rules and filters interact and the result isn't always what you expected.
If the filter returns nothing, the field looks broken to the agent. There is no helpful message explaining that a filter excluded everything, just an empty list and a support person who assumes the feature is down.
In triggers, views and macros
Here is where expectations need managing. A lookup field is a first class field, so it shows up in trigger conditions, view conditions and reporting. What it gives you is the relationship itself, not a free join across everything on the far side of it.
Practically, that means you can act on whether the field is set, or on which record it points at. Chaining several relationships deep, or filtering a view by an attribute of the related record, is where teams hit the wall.
The reliable pattern: when you need to route on an attribute of the related record, copy that attribute onto the ticket at creation time, through the integration that sets the lookup in the first place. Denormalising one value is unglamorous and it keeps your triggers simple.
Capabilities here have expanded over several releases. Check the current Zendesk docs for what your account supports before designing a workflow around a deep relationship.
Setting one over the API
A lookup field is a custom field like any other, so it travels in the custom_fields array. The value is the id of the target record.
{
"ticket": {
"custom_fields": [
{ "id": 4501234567, "value": "01HZ8Q3M2VN4XK" }
]
}
}For a user or organization target the value is that numeric id. For a custom object target it is the record id, which isn't a plain integer. Send the wrong shape and the field silently ends up empty rather than erroring in a way you would notice, which is a nasty half hour. Confirm the expected format in the current API docs for your target type.
You will need the field id too, and that is its own small problem. See custom ticket fields for a way to look ids up rather than pasting them into your code.
Where they go wrong
None of these are exotic. All four have cost me an afternoon at some point.
The broader point is that a lookup field is a promise about another dataset. It is only as good as whatever keeps that dataset current, and it fails silently rather than loudly when the promise breaks. Before you add one, name the job or the person responsible for the records on the other end. If the answer is nobody, add a plain field and move on.
Frequently asked questions
Can a lookup field be used in a trigger?
Yes. A Zendesk lookup field trigger can read the related record's attributes, and the Zendesk relationship filter on the field is what stops agents seeing every record in the account when they search.
What's a lookup relationship field in Zendesk?
A field that stores a reference to another record: a user, an organization or a custom object record. It holds the id, so the ticket always reflects the current state of the target.
Can I filter which records a lookup field offers?
Yes. Each lookup field takes conditions on the target record, so you can limit it to active records or to records belonging to the ticket organization.
Can triggers use lookup fields?
They can act on the field and which record it points at. Filtering on attributes of the related record is where limits appear, so copy the attribute you need onto the ticket instead.
What value does the API expect for a lookup field?
The id of the target record, sent inside the custom_fields array. Numeric for users and organizations, a record id for custom objects. Check the current docs for the exact format.
Relationships help, duplicates still happen
Two tickets can point at the same device and still be the same request more than once. Ticket Merger finds those.
Start free trial14-day free trial. No credit card required.