Zendesk provides many types of native data objects for storing and managing your customer data, including tickets, users, organizations, and more. We call these standard objects. However, standard objects can't provide every possible type of data object that your organization might want. With the custom objects, admins can create custom objects to capture data that doesn't fit into those standard objects. Extending the Zendesk data model with custom objects enables you to seamlessly integrate your custom data with tickets, triggers, and Explore analytics. All of this functionality is built directly into Zendesk, so these features can be configured and used in Admin Center and the Zendesk Agent Workspace. No coding is required.
About custom objects and records
A custom object is a user-defined object with unique fields and permissions. Custom objects can be almost anything, including a product, contract, delivery driver, asset, or event. Think of a custom object as a data table. Each of the custom object's fields is a column in the table. After the table is created and the columns are added, agents can add data to the table. Each row of data in the table represents a custom object record. Another way to think of a custom object is as a schema or model, which is created and made available to users to add data, such as in a ticket or form. Every time an agent uses the custom object to add data to Zendesk or an admin bulk uploads data for an object, new records are created. These records can then interact with business rules, such as triggers and lookup relationship fields.
Here's an example. Let's say you're a car rental company. A Zendesk admin at your company created two custom objects to track vehicles and reservations: vehicles and rental agreements. Using these custom objects, every vehicle and reservation can be tracked within Zendesk. Now, when a customer contacts the company to rent a car, a ticket is created for them. The standard ticket and user objects hold information about the customer and their request. In your account, an admin defined lookup relationship fields connecting the rental agreements and vehicles to tickets and users, so everything the agents need to resolve the request is now available in the ticket. They're able to search records of available cars in the requested location and date, create a rental agreement, and relate the rental agreement to the vehicle and user.
Later, the customer has an issue with their rental car, and they contact your company again. Again, a ticket is created for them and is associated with the user, the vehicle, and the rental agreement. Because each of these custom objects has been added to the ticket form, agents can see details about both the vehicle and the rental agreement within the ticket while they assist the customer.
How does it work?
Watch the demo below to see Custom Objects in action, or read on for information about the feature.
The following video shows a basic workflow for getting started with custom objects.
"How to use custom objects (3:20)"
Requirements and limitations of custom objects
There are a few requirements for using custom objects and some limitations you should consider before turning on the feature.
Requirements
- You must have a Zendesk Suite or Support Enterprise plan.
- The Agent Workspace must be activated for your account.
Limitations
Custom objects are a powerful tool for gathering more data in Zendesk, but the following limits exist to avoid performance issues.
Custom object and field limitations
- Your maximum number of custom objects depends on your plan:
- Suite Team: 3 custom objects
- Suite Growth: 5 custom objects
- Suite Professional, Support Enterprise: 30 custom objects
- Suite Enterprise and Enterprise Plus: 50 custom objects
- The following limits exist for fields on custom objects:
- Each custom object can have a maximum of 100 fields.
- Suite Team and Growth plans can have a maximum of 5 lookup relationship fields per object.
- Support Enterprise and Suite Professional and above can have a maximum of 10 lookup relationship fields per custom object.
- Only admins can create custom objects. Admins and agents in custom roles with permission can view, edit, add, and delete custom object records.
- Premium sandboxes don't copy custom objects, or lookup fields and triggers that reference custom objects.
Custom object record limitations
- Each record has a maximum size of 32 KB.
- Custom object records are counted toward your account's storage.
- Regardless of the storage capacity, accounts can't exceed 50 million custom object records.
- Light agents and contributors have view-only access to custom object records.
Modeling your data
There are two aspects to defining your data model: individual custom objects and how custom objects are related to other objects in your Zendesk account.
Each object has its own schema, defined by custom fields. These fields represent the properties of the custom object and are used by agents when creating records. You can use many types of custom fields to capture the data exactly how you want to.
Then, you must connect the custom object to other standard and custom objects within Zendesk. This network of relationships completes the data model. To define a custom object's relationship to standard Zendesk objects (tickets, users, and organizations) and other custom objects, use lookup relationship fields. Lookup fields are a special type of custom field used to describe single-direction relationships as source object → related object. The source object is the object that contains the lookup relationship field (among other fields). The related object is the object specified by the lookup relationship field.
It's important to understand that relating objects doesn't automatically create an association between two specific records. Instead, it describes the possible relationship and enables agents to associate records this way.
- another custom object
- a standard object
If you want the custom object to contain the lookup relationship field, see Adding object relationships to a custom object. Alternatively, if you'd like a different object to include the custom object as a lookup relationship field, see Adding custom fields to your tickets, Adding custom fields to users, or Adding custom fields to organizations.
Putting it altogether
You can use your custom objects and relationships to solve real-world problems or improve existing processes. When you add lookup relationship fields to your ticket forms that point to custom objects, you gain the ability for agents to capture more customized data in Zendesk and enable agents to view more relevant data within the ticket interface. By eliminating the need for agents to move back and forth between external systems and Zendesk, they can deliver faster and more complete support to your customers.
Custom data captured in object records can also be used in business rules, such as routing and triggers. Additionally, you can integrate your custom data into Explore analytics and reports. Reporting on custom data can provide a better picture of your customers and business as a whole.
32 comments
Daniil Teplov
Hi 1902738075884 ,
the availability of the custom objects in the ticket forms for our end-users to select from would be a great help for our organization as well.
Would appreciate a lot if you could share the latest status of the development around it :)
Thanks and best,
Daniil
2
Max
Hi 1902738075884
is it still on track for q3 for the custom objects available in Guide / ticket forms ?
That would be awesome !
0
Zach Brak
1902738075884 Heya! I was hoping to get your thoughts on using custom objects to emulate some of ServiceNow functionality.
For example in service now, you have devices tied to users, and those can be referenced and marked within the ticket.
What I'm trying to achieve:
- Load all of my devices for my users as custom objects (similar to demo video)
- When a user opens a ticket - have their device (or multiple devices) visible within the agent workspace.
My ideal situation would be adding custom object context to the agent workspace. Imagine a list similar to the customer context, where a list of select fields from the custom object is displayed here.
Was hoping you might have ideas or suggestions on how to display as much stateful custom object information on the agent layout as possible.
Specifically - would look to have specific important fields directly on the layout without having to navigate away:
- Remote access connection link
- device name
- device serial
- device model
Any help you can give is much appreciated, and thank you for your work in developing this product.
0
Ashwin Raju
1) June is going to have a lot of capabilities launched. One of them is the Filtering APIs for custom objects
2) As we go GA on Object triggers, you will see powerful actions on object triggers showing up. This includes notifications and webhooks. We feel that is going to open up a lot more powerful workflows with custom objects, especially around case management and proactive notifications..
3) Webhooks can create the proactive tickets that you are looking to create and automatically assign them to the right team based on the license details.
I think we can avoid the step of the agent creating a ticket and filtering the license object with object triggers. But you'd know your business better. Would love to connect and see how we can make it happen.
Drill down reporting on tickets is also in our roadmp for the second half of 2024 CC: 1901689631684
0
Shayan Moussawi
1) Yea I think the search API could help us build an out of Zendesk workaround.
2) I have read about Object Triggers, though I still struggle to find actual use cases for them. As far as I understand they only allow changing values of the custom object itself, and are triggered by a value change from the custom object. Meaning at best, it saves the agent a click or two, as he doesn’t have to change 2 values instead of 1. I do so the potential for them if they had more advanced action statements though: Things like creating a Ticket when a custom object value changes would be valueable for us for example.
3) About my use case for filtering/sorting:
Basically the licenses we sell are connected to work that our Agents have to do. Each license belongs to a country. Some agents are specialized in specific countries. And there is a hand off after the user buys a license:
Flow is as follows:
1) User asks for contract / to buy licenses for a country within a Ticket
2) Agent assists the user and help them make their contract. For example user might want to buy a license for 3 countries.
3) Then Agent would create 3 license objects with those countries and associate them with the customer.
4) These license objects have an active „to-do“ they have to be setup by a specialized agent from our Team
5) So as these are work items, right now the first Agent would in addition to creating 3 license objects also have to create 3 Tickets, one for each license and assign them to the right team.
6) Instead I would like the respective specialized agents to filter the license objects by status - so they are able to create their own Tickets themselves once they start working on the licenses.
For the reporting capabilities- I believe our use case would be pretty standard:
Just being able to see counts/averages of custom objects, similar to Tickets, and to use them in reports.
Also being able to drill down into reports and jump from custom object records straight into Zendesk by clicking on an associated user/ticket/org/object.
1
Ashwin Raju
Hi Shayan.. Long time. I am so glad you find the custom objects feature super useful.
We have 2 capabilities coming up this quarter (in June) that might of interest to you
1) Search API that supports filtering capabilities.
2) Object triggers with some enhanced actions. (Object trigger = trigger which gets evaluated when a custom object record changes)
We are also looking at native sorting and filtering on List view for custom object records mostly in the second half of this year.. Would love to connect and discuss about your use case better. CC: 1263082320929
We are also in early stages of reporting on custom objects directly.. CC: 1901689631684 .. What kind of reports are you looking to build on your Licenses?
0
Shayan Moussawi
1902738075884 Hey Ashwin,
Glad to see how far Custom Objects have come this year. I already suspected the potential when you first launched them in Beta.
I do have a few questions for out advanced use case though:
Is it in any way possible to see a full list of custom object records and filter by status or other attributes?
Use case:
We are thinking of having “Licenses” as custom objects.
So once a “License” is created it would be in the status of “open to provide”.
Now there is no way for an agent to filter all license records that are “open to provide” so he can start working on them: i.e. creating Tickets from them to assign etc.
Having explore capabilities for custom objects would also fix this I believe - as we would then be able to get a list of all custom object records with specific filters applied and the agents could work from there.
Explore as far as I understand only provides an option to report on lookup relationship fields on Tickets which reference custom objects - but for my use case the Tickets would not have been created yet.
0
Ashwin Raju
hi Adam.. We are still tracking this for a Q3 release.
As I mentioned above, we will be offering filtering capabilities on Lookup relationships. And we will also offer filtering capabilities on the Search API to build custom solutions if you'd want to.. But, the permissions will be at an Object level.
0
Adam
Hi 1902738075884 - I was just wondering if there was any update on enabling custom objects visibilty - is this still planned for Q3? The new dynamic filtering is working really well, we just need to be able to present this to end users now rather than limiting to agents!
Thanks,
Adam
0
Adam
Hi Ashwin,
1. There is not necessarily for us a requirement to see the details of the contract, just that they can see the reference associated to that contract, or the ID, it does not necessarily matter.
2. This would be of concern to us - if we were to use a reference for the contract (essentially the end customer name) - we would not want other customers being able to access this data of what other customers are doing if that makes sense. We could make this non-friendly by using a unique reference number which would not mean anything to another user, but it is far from ideal and would prefer not to do this.
Regarding the dynamic filtering - I have seen we have it live on our account and have tested it and it works exactly as required (I can now select from my list of contracts for the users organisation) - all we need now is the ability to include that field on the guide help center forms and we will have everything we need!
0
Sign in to leave a comment.