When to use a custom object and when a ticket field

The question that decides your data model. One test answers it: does this thing exist independently of the ticket?

The question that decides your data model. One test answers it: does this thing exist independently of the ticket?

The test

Does it exist when there is no ticket, and can it be the subject of several tickets over time?

• Yes: a custom object. A contract exists whether or not anyone has a problem with it, and will be referenced by many tickets across years.
• No: a ticket field. The reason someone is calling exists only in the context of that call.

Worked examples

The middle case

An order number is a reference to something in another system. A field holding the number is usually right and enough. It becomes an object when you need Zendesk to know things about the order, such as its status or value, and to report on them.

Ask what you would do with the extra data. If the answer is nothing, a field is the cheaper answer by a long way.

Getting it wrong costs

A field where an object belonged means repeating the same data on every ticket, with no single place to correct it. An object where a field belonged means maintaining records nobody reads.

There is also a ceiling that rewards deciding carefully. An object is connected to a ticket by a lookup relationship field, and the plan gives you five of those on Suite Team and Growth, ten on Professional and above. Enough for a considered handful of objects, not enough for one per idea.

On tickets that number has moved. Since 27 August 2026 it is what each ticket form may carry rather than what the account may hold, and you may create up to 40 lookup relationship fields on the ticket fields page. So on a plan with several forms, the limit that used to force a choice between objects now only forces it per form.

See also

• Creating a custom object
• What IT asset management in Zendesk does
• The field types and when to pick which
• Custom fields for users and organisations