Summary: ◀▼
You can create custom relationship fields to connect data between users, tickets, organizations, and custom objects using one-to-many, parent-child, or many-to-many relationships. These fields help you view related records and use relationships in business rules like triggers and views. Relationship fields support filtering, permissions, and placeholders for dynamic data, enhancing how you manage and automate workflows based on linked records.
In Zendesk, there are a variety of standard relationships between Zendesk objects, such as users and tickets (requester, assignee, followers), tickets and organizations, agents and groups, and so on. These standard relationships can be one-to-many, many-to-many, or hierarchical (parent-child). These three types of relationships can also be defined by admins using custom relationship fields between standard and custom objects within Zendesk to capture their unique data. This article describes the relationships, how the relationship fields can be used, and how to view related records.
Understanding the types of custom relationships
One-to-many relationships (lookup)
source object → related object
A lookup relationship field is a custom field that lets you look up and select from a list of users, organizations, tickets, custom object records, brands, or articles in your Zendesk account. The following example shows a lookup relationship field on a ticket. When a team member clicks the field, an auto-populated list of options is provided as you type in the field. You don't have to define the options yourself, as you do for other dropdown custom fields, although you can filter the available options when defining the field.

After selecting a record in a ticket lookup relationship that points to a custom object, you can preview the record details within the ticket.

After selecting a record in a user, organization, or custom object lookup relationship field, you can view the record details by clicking the field name:

Records of the source object can be related to none, one, or many records of the target object. This relationship is established by adding a lookup field to the first object and selecting the second object as the target of the lookup field.
Custom lookup fields are available on all Zendesk Suite and Support plans. The can be added to tickets, users, organizations, and custom objects.
- Suite Team and Growth plans can have a maximum of 5 lookup relationship fields per object.
- Suite Professional plans and above can have a maximum of 10 lookup relationship fields per object.
- The related object for lookup fields can be a ticket, user, organization, or the name of another custom object. When addint a lookup field to custom objects, the related object can also be articles or brands.
- In most cases, you'll want to define a subset of records for the options in your lookup field. The filter options available vary by object.
- Only lookup fields pointing to custom objects can be visible to end users. Furthermore, end users must be signed in to see lookup fields in ticket forms.
Parent-child relationships
Parent-child relationships are hierarchical one-to-many relationships defined through parent-child fields. Records of the parent object can be related to none, one, or many records of the child object. This relationship is established by adding the parent-child field to the child object and selecting the parent object as the target. Child objects can't exist outside of the context of the parent record. Therefore, the parent record has complete control over the lifecycle for child records, especially as it relates to data deletion.
When creating the parent-child relationship, you can decide whether the child objects inherit the parent object's permissions.
Custom parent-child fields are available on Zendesk Suite Professional plans and above and Zendesk Support Enterprise plans. Parent-child fields can be added to custom objects only.
- Parent-child relationship fields are added to the child objects. Currently, only custom objects are supported as child objects.
- Parent-child relationship fields support tickets, users, organizations, and custom objects as parent objects. Parent-child relationships don't support articles, brands, or groups as the parent object.
- Each object can be configured as the child object for a maximum of two parent relationships.
- There is no limitation to the number of child objects a parent object can have.
- If an object is the child to more than one parent object, only one of the parent object's permissions can be inherited.
- Child objects can't be parents to other objects.
- Parent-child relationship fields can't be added if either object already has records.
- Deleting a parent record also permanently deletes all associated child records.
- Parent-child relationship fields can be deleted from the child object, but this action is permanent and results in the loss of all relationship data.
- Roll-up summary fields are supported for parent-child relationships with a custom object parent only.
- Roll-up summaries can summarize a maximum of 10,000 child records per field. If the parent has more than 10,000 child records, the roll-up summary can't be calculated.
Many-to-many relationships (multi-lookup)
Many-to-many relationships are defined through multi-lookup fields. Records of the first object can be related to none, one, or many records of the second object, and records of the second object can be related to none, one, or many records of the first object. For example, a feedback ticket can be linked to multiple products, and each product can be part of multiple feedback tickets.
Custom multi-lookup fields are available on Zendesk Suite Professional plans and above and Zendesk Support Enterprise plans. Multi-lookup fields can be added to tickets only. However, if you need to create many-to-many relationships for other objects, you can use a custom object with two lookup fields to capture this.
- Multi-lookup field values count towards custom object record and data storage limits.
- Multi-lookup fields can have a maximum of 20 targets.
- Multi-lookup fields are supported in the standard Copenhagen help center and in custom help center themes based on v1 - v3. If you are using a custom v4 theme, you must manually update it before multi-lookup ticket fields can be made visible to end users or used in the service catalog.
- Currently, multi-lookup fields aren't supported in reporting.
- Multi-lookup fields can be referenced in action flows as an array input to a loop step to return all selected values.
- Multi-lookup fields can be used in business rules and referenced in
placeholders using the field ID, similar to any other ticket field:
{{ticket.ticket_field_<field_id>}}. For multi-lookup fields, this placeholder returns a comma-separated list of target records.To retrieve data from a multi-lookup field's target record through a placeholder, you could use Liquid markup similar to the following:{% for t in ticket.ticket_field_<field_id> %} {{ t.name }}: {{ t.id }} {% endfor %}
Viewing related records
Establishing relationships between records is important for building out your complex data model. However, it's equally important to see and interact with those relationships within Zendesk. Each user profile, organization, and custom object record displays a list of related records. For tickets, related records are visible as values within the ticket fields and clicking on a value in a relationship field opens the related record's details in a new tab in Support.
Viewing records related to users and organizations
Each Zendesk Support profile for a team member, end user, or organization includes a Related tab that lists all related source objects. The information is grouped by the type of source object (Tickets, Organizations, Users, or Custom objects) and the specific lookup field.
In the following example of a team member profile, tickets have a lookup relationship field called Driver. If Annie Porter is selected in the Driver field, that ticket appears under the Related tab on her team member profile. It’s grouped by the type of source object, Tickets, and the name of the lookup field, Driver.

The Related tab doesn’t appear on user profiles in your help center.
Viewing records related to tickets
Viewing records related to custom objects
Similar to users and organizations, when you view a custom object record's details, you'll see all values for all of the object's fields on the left and then a list of related records grouped by the source object's type on the right.
| Icon | Source object |
|---|---|
| Custom object | |
| Organization | |
| User | |
| Ticket |
The following example shows the details for record 256 of the
Project custom object. In addition to the specific details about
project 256, you can also see that this project is related to 3 tickets via a
lookup relationship field on the ticket (
) named Project Code that points to the
Project object.

Using relationship fields in business rules
Relationship fields can be used in business rules the same way most custom fields are used. This includes triggers, views, omnichannel routing queues, SLAs, and deletion schedules.
When adding a condition to a trigger or view, any relationship fields also appear in the list options. In the following example, the first condition of a trigger is a user lookup field named Support Manager. The trigger only fires for tickets associated with the support manager named Jennifer Hanson.

You can also use relationship fields in the actions of your triggers. In the following example, the action sets the value of the organization lookup relationship field named Company Organization to Northwest Region when the trigger fires.

In addition to using the record name specified in lookup fields in trigger conditions and actions, you can also reference the related record's fields within your conditions and actions. For example, if you have a ticket lookup relationship field named Software requested that points to a custom object named Software, you could use the Software requested lookup field to create conditions and actions around the record selected within the lookup field—as in a record is or isn't present, or the record's name is or isn't set to a specific value—or you can reference other fields within the record, such as a Approval required checkbox being selected or not within the record related to the ticket. For more information about using lookup relationship fields that target custom objects in triggers, see Using custom objects in triggers.
You can also use placeholders to retrieve information about the target record in a lookup relationship field. This is true for lookup fields pointing to other tickets, users (requester), and organizations. The ID can then be used in API requests, such as to assign the ticket to the user specified in a lookup field or notify the manager of the user specified in a lookup field that their approval is required.