| Announced on | Rollout starts | Rollout ends |
|---|---|---|
|
April 27, 2022 |
July 11, 2022 |
August 1, 2022 |
Zendesk is adding a new custom field type that allows you to define custom relationships between tickets, users, and organizations in Zendesk Support.
What's changing?
A new custom field type called Lookup relationship is being added for tickets, users, and organizations. This new custom field type enables admins to build custom relationships between these Support objects that are unique to their business.
Additionally, lookup relationship fields can be used in triggers and views. Admins also have the ability to filter which values can be included in lookup relationship fields.
To learn more, see Using lookup relationship fields.
Why is Zendesk making this change?
Each Zendesk customer has unique business needs. Not all of these needs can be met with the native relationships built into Support. Adding new types of custom fields, such as lookup relationship fields, increases the flexibility of Support to meet the unique needs for storing and associating different types of data about tickets, users, and organizations.
What do I need to do?
Custom lookup relationship fields are being rolled out to all accounts automatically. Before using lookup relationship fields, work with your development team to determine whether you are using any custom code or applications to retrieve ticket, user, or organization fields. If not, you can begin using lookup relationship fields immediately.
If you are using custom code to retrieve user, ticket, or organization fields, work with your development team before you begin using lookup relationship fields to ensure that your integrations continue to function as expected. Do the following:
- Identify the way your custom code handles unknown field types. This could be to crash, exclude and ignore, or fallback to a more generic type like the text field type.
- Update your custom code to avoid unexpected behavior. We recommend falling back to a text field type when an unknown field type is encountered. This is usually the least disruptive approach, and it will future-proof your code for any new field types that may be mandatory.
After you start using lookup relationship fields, we recommend updating any custom code you may be using to recognize the lookup relationship field type.
65 Comments
Hi Ashwin Raju,
This sounds very interesting, I don't yet see it in my account, so I don't have a good feel for what is possible here.
Could you maybe outline some sample use cases to concretize this feature a bit?
Relationships between users, org, and tickets, and also how business rules can use this sounds very promising, but I can't really visualize what is possible from this - hope you can help.
+1 to Jacob Christensen's comment. I would like to see some use cases of how it could effectively be used and why it could be a value to us. Thanks.
Same. This seems cool, but I am not sure how to actually use it or what to use it for.
Great news!
Thinking of workflows similar to what's possible in JIRA with linked issues for dependencies, or otherwise linking users in revision or approval workflows.
With that in mind, will this be added to the JIRA<>Zendesk app so that we can sync these on both ends?
For the questions above, this can be used for the following, among many opportunities:
Where I see the power of this capability is using integration tools to keep User records up to date -- in CRM fashion -- and then using Ticket lookup fields to easily view and store the User data in Tickets.
As a product manager, it makes me super happy that you are as excited about this feature as I am. Lookup relationships will come up as a new field type when you try to add a field in Users, Tickets or Organizations. I have included a screenshot for the same. In a nutshell you can use this field to create custom associations of any of {User, Ticket, Organization} record to another {User, Ticket, Organization} record
Common Use Cases :
1) Associating multiple defined parties to a ticket - Let's say you are a trucking company you might want to associate a Ticket with your Shipper (Organization), Driver (User), Third Party (Organization) etc. This field type enables you to build these associations
2) Defining Organization relationships : Let's say you are in the B2B business and work with multiple organizations, who have relationships built across each other (it could be like an organization hierarchy), you can use Lookup fields to define those relationships
3) Defining Org to User relationships or User to User relationships: Let's say I am still in the B2B business example and I have a key stakeholder who is associated with that Organization(Org->User). And let's say, the key stakeholder is associated with a Relationship manager within your company(User->User). You can build this using Lookup fields.
I'd love to hear more use cases specific to your organization that can be solved using Lookup fields. We feel that this is the foundational blocks for much more use cases to come, once we integrate this with Custom Objects, enabling you to associate your business specific data to your Tickets, Users and Orgs.
We don't have this available to our customers yet. We are planning an Early Access program in May for our customers who might be interested. Be on the lookout for the enrollment form in this community next week. Best case scenario, we will start making it generally available by June end.
Pretty soon, I will be posting more details about some of the cool capabilities we have with this and some of the current limitations of this capability.
PS: In case you are wondering about the new layout for adding fields - that is also coming up pretty soon.
Hi Ashwin, thanks for the examples it really helps us come up with our own internal use cases. Quick question once the relationships are created then what? Will we be able to pull this into explore to report out?
For the first release we will not have reporting with Explore. Reporting is definitely in the top of our list for enhancements. However, you will be able to expose this information through APIs, in case you have your own reporting capabilities..
Hi,
This really sounds incredible - very exciting feature.
Can you share any details about the types of Triggers we can define with these fields?
One use case we have in my company, is that we assign each Organisation an Account Manager and Technical Resource - at present, we create a Trigger for each Organisation, so when they create a ticket, it will cc the two assigned users.
With the Lookup Relationship fields, could we potentially add those users and cc them via a Trigger? I am hoping this could mean a reduction in the number of Triggers we need to maintain.
Ashwin Raju, in context with Stephen's question, will we be able to have Trigger & Automation actions to Email users linked to a ticket? Or similarly, opening side-conversations with them as target?
Stephen on your question:
This should be possible the same way you can already add users to CC and as Followers, via the API
Will this affect the ZD/Jira integration if we are just using all OOB functionality?
Ashwin Raju will this encompass Custom Objects? That's the highest value on our end for things like associating tickets to Rooms, Locations, Productions, Projects?
Ashwin Raju This does sound like an interesting feature, depending on how automatic its functionality is. I have a few questions in regards to this feature:
How exactly does the association work? In your examples you mention big orgs or users. Would this also work to define a relationship for all users with their respective Tickets? This could help to sync Ticket fields for a user with one another (i.e. syncing certain ticket fields when a ticket is associated to a user). Or is it possible to associate based on triggers? Also, could you define 'associate'?
If what I mentioned above would be possible, there is a lot of potential to alleviate a lot of manual programming that would need to be done to sync ticket fields. (at the moment we can use the API and webhooks in conjunction with triggers to achieve that).
Matt Owens thanks for raising that, and +1 on the need.
My assumption from the article's description and the comment above is that that the lookup relationship field is limited to the objects zen:ticket, zen:user, and zen:organization as source and target objects in this initial release.
Ashwin Raju when can we expect more to be included?
Also, will we be able to define if the fields are 1:Many, 1:1 or Many:1?
For example users A, B, and C could be linked to user D per a 1:1 relationship, though having a field of 1:Many in user D listing all other linked users.
Stephen, Rafael Santos - For the first release, you will be able to use the Lookup field as a condition in a Trigger - There are 4 possible conditions available - "Has a value", "does not have a value", "value is" and "value is not" .. But we are looking at expanding Lookup fields' usage into Actions as well. I will be adding this to our backlog.
bill cicchetti - It should not affect any Zendesk OOTB integrations like JIRA.
Matt Owens - The value of Lookup fields will exponentially improve once Custom Objects are brought into the fold. My team is currently building a new and improved Custom Objects experience and making it much more Admin friendly. Lookup field will play a key role in helping Admins build relationships across objects, once the new version is in place.
Rafael Santos - We have already started our work on Custom Objects and are targeting the first half of next year. This will not just have Lookup fields, but a whole host of capabilities/ admin-driven integrations..
If this behaves like lookup fields in Salesforce, you'd be able to link a ticket to say, an internal user who is not the ticket owner or requester. Why?
Say you want to create a TAM (technical account manager) field on the ticket that will define who is the TAM responsible for overseeing that ticket.
Without lookup fields, you'd have to create a text field and manually type in the TAM's name or email.
A lookup field is a pointer to a pre-existing record in another table in Zendesk (like the users table). So when you edit the ticket, the lookup field will be like a pre-populated dropdown with your users' names. You won't be able to manually type something else in.
Once you save the ticket, the value of the lookup would be the selected user's name, and clicking on it will take you to that user's page.
So, this type of field is used to create relationships between Zendesk records.
Rafael Santos - We will not be able to define specific relationship types(1:1 or 1:Many or Many:1)
In the example you mentioned A,B,C are all connected to D. When I go to A, I will see only D. Same applies to B and C. When I go to D, I will be able to see all A, B and C in a tabular format (not associated with one field).. And we will have API endpoints to retrieve these 'Reverse indexes'.
Thank you Pablo Gonzalez.. You are absolutely correct. This is a field type to create relationships between Zendesk Internal records (Tickets, Users and Org records)..
We are in the processing of launching ZD Support so this may be off but we are in need of a way to link end-users that may be in the same household or related through various other fields. it helps us control the conversation - would these new fields be a way to do that?
hey Cathy Guidi-Scherm,
Following off the back of @...'s comment, I've recently done this type of relationship with one of my clients in the real estate space. I thought it might help for you to see an example of how we did this with our client.
In its very simple form, we have the Address set as the organization name, and then in this example, we have 18 users who are associated with that address linked to this organization. This way, when anyone of these 18 users submits a request, it will be automatically linked to the organization and you can then further report on this from there. e.g the number of requests submitted by all users for a particular organization.
I hope this helps with your setup. You could of course expend on this setup from here with lookup fields etc :)
Best,
Amie
Good news !! We have launched an Early Access Program for this feature.. Feel free to visit this page to know more and register for this feature.
Would this feature allow me to link tickets from the same person who has used multiple emails (creating separate user-profiles) in Zendesk? We cannot merge the profiles because zendesk will only reply to the primary email regardless of the email the user used to send the request. If we can use this to link to their other profiles that might be a good workaround.
Hey Teri Hines,
You could use the standard organization feature to link all user profiles for one person under. This would then effectively group all tickets together under the org which are submitted from any of the user's email addresses that are linked to the org.
Teri Hines - In case you are using your Organizations for another purpose, you can add a ticket lookup field, let's say, called Alias and point the field to a user type. This will enable you to associate the ticket to that second user profile. That way, the ticket will be associated with both profiles (although through different relationships)..
Thanks Amie Brennan and Ashwin Raju. Unfortunately we are not using the organization feature in this case. We are a graduate school and students are issued a student email address but they may also email from a personal or work email account when applying to us and as alumni. Plus, work emails can change over time. Any thoughts on how this new feature could help us with that use-case?
How will this affect the Zendesk APIs and data structure for Support? We're very interested in this feature and joining early access, but want to make sure it won't break our Data Warehouse integration with Domo.
Hi PAUL STRAUSS, You can find the API documentation for Lookup fields in this link. To ensure that your integrations are not affected, you might want to ensure that it is handling new field types in the right way. One non-impactful way of finding out if your integrations are correctly configured is to create a Lookup field in your Sandbox and testing your integrations out there.
Please sign in to leave a comment.