Creating a custom object

Defining an object, its fields and how tickets reach it. The naming decisions are the ones that last.

Defining an object, its fields and how tickets reach it. The naming decisions are the ones that last.

Create it

1. Open Admin Center, then Objects and rules > Custom objects > Objects. Check the Templates tab first: Contracts, Orders, Products, Projects and Subscriptions are ready-made, and each can be used once.
2. Add an object and fill in Name, Plural display name and Object key. The description is optional and is cut off in the list past 92 characters, so put the point in the first line.
3. Decide how records get their names. See below, because this is the one decision you cannot revisit.
4. Add its fields. An object holds up to 100.
5. Save.
6. Add a lookup relationship field on tickets pointing at it.

How records get named, and why it is final

On the fields tab, the Name field decides what a record is called, and there are two ways to fill it.

• Name records manually. Somebody types it. Optionally you can require those names to be unique.
• Name records with autonumbering. A prefix of up to 30 characters and a starting number of up to nine digits, beginning at 0001.

You cannot change this once records exist. Not a preference to revisit later: choose it before the first record goes in, or live with it.

Which way round to go follows from who reads the name. It is what agents see in a picker, and a contract shown as CON-0042 is unusable where the customer name plus the contract type is obvious. Autonumbering is right where records are created in bulk by a system and nobody picks them by hand.

Fields: start narrow

Only what you will act on: show to an agent, use in a rule, or report on. Everything else is a field somebody has to populate and keep true.

Objects are easier to extend than to prune, because pruning means deciding what happens to the data already in there.

Connect it to tickets

An object nothing points at is a list. The lookup relationship field on the ticket is what makes it useful, and adding a filter to that field so agents only see relevant records is what makes it usable.

Permissions

Who can see and edit records is configurable, and worth setting deliberately. Contract values and renewal dates are not always something every agent should be able to change.

Two fixed points inside that. Only admins can create the object itself; agents in a custom role with permission can work with the records but not define the schema. And light agents and contributors can only look: their access to custom object records is view-only, whatever else you configure.

See also

• Setting permissions on custom object records
• Lookup relationship fields: pointing at another user, organisation or ticket
• Adding and managing records