Planning your custom objects workflow

Important: This article doesn't apply to legacy custom objects.

Admins can create custom objects to capture data that doesn't fit into the standard
objects in Zendesk. Extending the Zendesk data model with custom objects enables you to
seamlessly integrate your custom data with tickets, triggers, and Explore analytics.
However, deciding when and how to use custom objects to best meet your needs can be
challenging. This article guides you through questions you can use to inform this
decision.
This article contains the following topics:
Identifying your custom data goals
Understanding your data
Planning your data model
Leveraging your custom data model




Identifying your custom data goals

To resolve a ticket, agents usually pivot between Zendesk and external systems to get
the necessary information. Custom objects let you include data from external systems
in Zendesk, reducing the need to bounce between systems. To provide your agents with
this streamlined experience, you first need to identify the information they are
seeking in external systems and when they need it.
The best way to approach using custom data in your Zendesk workflow is to identify
your goals and let that guide which custom data you start with. For example, are you
trying to:
Reduce the time agents spend on tickets?
Improve customer satisfaction?
Upsell products?
Save costs by consolidating system licenses?
Something else?


After you identify your top priorities and goals, work with your agents and team
leads to understand what data they need to work toward each goal. The following
questions are a good starting point:
What systems currently house the data?
At what point in their current process do they reference the data in the
external system?
How do they use the data after they retrieve it?
Are there any data gaps that could be filled to further assist in meeting
your goals?
Do they want to use this data in reporting or business rules? (Custom
objects are an option regardless of the answer, but if you don't plan to use
custom data in reporting and business rules, a custom sidebar app might also meet
your needs.)





Understanding your data

If you've determined that custom objects are the right solution for you, it's
important to understand plan-based limitations on the number of
custom objects you can create and lookup relationships fields you can define. You
should also consider your data model before creating custom objects. Sketching out a
plan before you start will save you time in the long-run.
A good way to start visualizing your data model is to create a simple spreadsheet for
each custom object. Start with a type or category of data you think might work well as an
object. All records have a Name field, which is text-based, so start with
that as the label for the first column. Then, continue labeling the columns with the
other data you need. These will become your custom object's fields. For example, if
your custom object is Rental property, your spreadsheet might look similar to
the following:














Rental property


Name
Street address
City state
Zip code
Property manager
Renter
Lease start




Royal Heights - 203
203 Herrick Lane
Richmond, VA
23059
John Doe
Christopher Garvey
January 17, 2023





Continuing with this example, you might also want an Appliance custom object,
which is related to your rental property object. So you'd create a second
spreadsheet similar to this:











Appliance


Appliance ID
Type
Apartment
Last Maintenance




RF12345
Refrigerator
Royal Heights - 203
21 December 2022





Continue to create spreadsheets for each custom object you want to create and
populate them with your data and how the data is related to other objects in
Zendesk.



Planning your data model

After determining which custom objects you want to create and the data those objects
need to capture, you're ready to figure out how it will work in Zendesk. You've
already identified the names of the objects and the data you want to capture, but
now you need to create the objects and add each field within Zendesk. Consider the
following:
Decisions you'll make when creating your custom objects
Seeding your initial data




Decisions you'll make when creating your custom objects

When you create a custom object, you're
defining a new schema. The object has unique characteristics and relationships
to other objects and data within Zendesk. As such, you need to be intentional
when defining an object's
fields and relationships.


Determining field types

Next, decide what field types to use. For example, when creating the Rental
property object in Zendesk, the Street address and City state
might be text or drop-down fields. Zipcode could be a number field,
and Lease start would be a date field. The Property manager
and Renter fields would be lookup fields that define the object's
relationship to users. However, these lookup fields could be defined on the
custom object or as a user field. See Defining relationships.
Something else to consider when deciding which field types to use is
discoverability of the data. When agents search for custom data in Zendesk,
only text-based fields are checked for matches.




Defining relationships

Lookup fields are how you build
relationships in Zendesk. They are the cornerstone of how your data from
standard and custom objects work together to create your data model. They're
most useful when used to define many-to-one (Many:1) relationships. For
example, each rental property will have at least one Renter, but you
need to decide if that relationship should be defined as the custom object's
field or as a user field. If you define the relationship as one of the
Rental property object's fields, you can only relate each rental property
record to a single user, designated as the renter. However, if you add the
lookup field to users and specify the rental property object as the related
object, you open up the possibility of defining multiple renters associated
with a single property record. Typically defining the lookup field on the
"many" side of the relationship gives you the most flexibility.
Another example would be appliances. Each rental property probably has
multiple appliances—refrigerator, stove, dishwasher. Therefore, it makes
sense to define the lookup field as one of the Appliance object's
fields.

In both cases above, the lookup field is defined on one object and points to
the Rental property object. In this case, each Rental property record will
display lists of renters and appliances under the Related tab.

You'll also need to think about how your objects are related to tickets and
can be used to meet your custom data goals.




Seeding your initial data

Bulk importing records enables you to move data from an external system into
Zendesk to reflect your data at that point in time, but it won't stay
synchronized. If you continue to store and update the data externally, the
records in Zendesk will become outdated; likewise, any updates agents make to
the records in Zendesk won't be reflected on the external system. After you
create the object and import your initial data, we recommend maintaining the
data (records) in Zendesk going forward. However, if it will continue to be
maintained in an external system, you should define a plan for periodic bulk
imports.
To make it easier to get up and running with custom objects, you can perform bulk
imports to seed the initial records after you create your custom objects. If you
already compiled all of an object's records into a spreadsheet and mapped it to
the fields you defined when creating the object in Zendesk, you can probably
download or export the data into a comma-separated value (.CSV) file. Most
spreadsheet software has this option, as do many other systems that might
currently house your data. See Bulk uploading custom object
records.

Note: If your spreadsheet included data that you defined as a lookup on another
object, remove that data from your spreadsheet before importing the data. After
you've imported the custom object records, you can perform separate bulk uploads
to seed data into the lookup fields on other objects.




Leveraging your custom data model

After you create your custom objects and seed your record data, it's time to use that
data to meet your goals. Usually, this involves adding custom fields to your tickets and support request
forms. As with other relationships you might have identified and created earlier,
you'll also use lookup relationship fields to do this. By surfacing
custom objects in tickets, agents can set and view relevant data without leaving the
ticket interface. Keeping the data up-to-date and accessible without
context-switching to different systems means your agents can work faster and more
effectively to meet your customers' needs.