Parent-child relationships and roll-up summary fields

Objects can relate to each other, and a roll-up field summarises the children on the parent. Powerful, and easy to overbuild.

Objects can relate to each other, and a roll-up field summarises the children on the parent. Powerful, and easy to overbuild.

Parent and child

One object can point at another. A subscription belongs to a contract; a device belongs to a location. That is a parent-child relationship, built with a lookup field on the child.

Roll-up summary fields

A field on the parent that summarises its children: how many there are, the sum of a value, the earliest date. Calculated for you and kept current.

So a contract can show how many subscriptions it covers without anyone maintaining that number.

Where this genuinely helps

• A count that agents need at a glance, such as devices on a site.
• A total that would otherwise be worked out by hand.
• The next date coming up across a set of children.

Where it goes too far

Three levels of objects with roll-ups at each level is a data model, and Zendesk is a support tool. Once you are designing schemas, ask whether this data belongs in the system that owns your business data, with Zendesk holding a reference.

The honest test: could a new admin understand your object structure in ten minutes? If not, it will be maintained badly.

Reporting does not follow the chain

Explore reaches related records through the ticket, and does so more simply for one hop than two. Design assuming one hop, and copy anything you need to report on onto the ticket.

See also

• Reporting on custom objects
• Building a product catalogue with custom objects
• When to use a custom object and when a ticket field