Building a product catalogue with custom objects

A worked example: modelling the products you support as an object, so tickets say what they are actually about.

A worked example: modelling the products you support as an object, so tickets say what they are actually about.

Why not a drop-down field

A drop-down of product names works until you want to know more than the name: which version, which team owns it, whether it is still sold, what the documentation link is.

At that point every ticket carries a name and the knowledge lives in someone's head. An object holds it once.

Build it

1. Create an object called Product.
2. Fields: name, category, owning group, status, a link to its documentation.
3. Set the display name to something an agent recognises.
4. Import your product list.
5. Add a lookup field on the ticket pointing at it, filtered to active products.
6. Add a card so agents see the details in the context panel.

What it then enables

• Routing to the owning group, read from the record rather than a rule listing every product.
• Tickets per product in reporting, from a controlled list rather than free text.
• Retiring a product by changing its status, so it disappears from pickers while history stays readable.
• The right documentation link in front of the agent automatically.

Copy the name onto the ticket

Add a trigger writing the product name into a ticket field as well. Redundant, and it makes reporting straightforward and freezes what the ticket was about even if the product record changes later.

See also

• Using custom objects in triggers and views
• Reporting on custom objects
• Showing cards with extra information
• Using custom objects in action flows