Messaging Metadata uses conversation fields and conversation tags (also known as custom ticket fields and custom ticket tags) to gather more information about the support issue or product or service. You can also use this metadata for better ticket routing in Agent Workspace by creating triggers in Admin Center. You can add Messaging Metadata to your tickets and add them to your Help Center Submit a Request form if you want end users to see the custom fields.
You can also use conversation fields and tags to send your agent Messaging Metadata from Web Widget and Zendesk SDKs via client-side APIs. This enables the automatic transfer of relevant information, such as product SKU, confirmation number, or order ID, to the agent. This additional metadata aids in providing comprehensive context and enhancing the quality of support provided.
- Better agent context. Agents rely on correct contextual information presented in their Agent Workspace view. Missing data or data provided by the end user can be error-prone. By providing relevant information programmatically, you reduce the errors and time spent asking for information.
- Improved routing. Businesses rely on information in ticket fields and tags to route the ticket to the correct agent group quickly. By providing more complete data, routing the ticket to the correct agent group is more efficient.
- Optimal experience for the end user. End users won’t have to re-enter data already available on the client side.
- Improved automation flows. Bot builders can leverage the additional data for a better bot experience.
- Feature parity with the Classic Web Widget Support SDKs, which supports ticket fields and tags.
Messaging Metadata overview
Suppose you have an online store, and an end user is looking at a specific shoe. On this page, there are the product SKU, size, and color options. When the end user has questions about this shoe, it is necessary to know the above information so the agent knows exactly what shoe the end user is interested in. Without custom ticket fields, the agent (or Zendesk bot) must ask the end user for all this information before answering the question.
With Messaging Metadata, you can get this data programmatically from the page or by having the end user fill out a form or a combination. For example, using a custom ticket field, you can use an API to retrieve the product SKU from the product page. Since the end user may or may not have selected the color and size, a Zendesk bot (for example) can query these using custom ticket fields and display their default values. The end user can update the values or leave the default ones.
- End users do not have to manually enter data that exists on the page they are visiting. For example, if an end user is on a return order form and the order id exists on that page, you can programmatically retrieve that number instead of having the end user type it in.
- Extra context can be added automatically to assist the agent. For example, if an end user has their shopping cart open, you can set a conversation field “Active Shopping Cart” to true.
- You can control the path followed by a bot. For example, if an end user is on a page for Brand A, you can set this in a field so that the bot traverses the Brand A path.
Configuring for Messaging Metadata
Conversation fields need to be configured within Admin Center to allow their values to be set by an end user when the fields are created. Conversation tags do not need any prerequisite steps before the metadata API can be used.
The first step to using Messaging Metadata is determining what data you want to collect and how to use it. This is entirely dependent on your use case. You must fully understand the end-user experience when your developer sets the ticket field and tag values programmatically on the Zendesk Web Widget and SDKs.
- A Zendesk admin creates a custom ticket field and passes the field name and ID to a developer, along with the use and desired data to collect.
- A developer codes the call to the metadata API using the field ID to connect the value to that field.
- The data is programmatically set in the metadata API at runtime and is available in the next session.
- Ticket field and tag data are added to the support ticket at the time of ticket creation.
The ticket fields and tags metadata are applied to the ticket on ticket creation. For example, if you configure your widget to instantly chat to an agent (rather than a bot), then opening the widget instantly creates a new ticket and only the ticket fields and tags that have been set prior to the ticket being created are added to it.
Once a ticket is closed, Messaging Metadata in the backend (such as tickets) is reset to an empty null state. Currently, Messaging Metadata persists on the client side and will be addressed in a future release.
Adding a conversation field
Customers on any Support plan can create conversation fields, but you must have messaging configured and be using the Zendesk Web Widget or SDKs for Messaging.
System ticket fields, such as the Priority field, are not supported. They appear in the default contact form (and any other ticket form), when accessed from the help center but do not appear in the Web Widget.
You can verify a conversation field has been set by viewing the ticket information within Zendesk Agent Workspace or with Zendesk APIs. See Using Messaging Metadata for an example.
- In Admin Center, click
Objects and rules in the sidebar, then select Tickets > Fields.
- Click Add field.
- Select a field type, then enter a Display name.
- (Optional) Enter a Description for the custom field. This is visible to admins only.
- Under Permissions, select Customers can edit.Note: Because the values can be set via a public client-side API call, the data should always be treated as if an end user has provided the data. Using these APIs is not recommended for sensitive data.
- Enter a Title shown to customers.
- If the agent must complete the field to solve the ticket, select Required
to solve a ticket. This option is not available on all field
types.Note: When agents merge a ticket, they don't need to fill in the required fields because merged tickets bypass Solved and go directly to Closed. This setting is also bypassed if a business rule changes the ticket to Solved because a system process solves the ticket rather than an agent.
- If the end user must complete this field to submit the ticket, select Required to submit a request.
- Configure any additional options depending on your field type.
- (Optional) Specify a Default value for the custom field.Note: The default value in a drop-down list only applies to new tickets created by agents through the Support interface or created by users wherever the ticket form is displayed. If you change an existing ticket form to one with a drop-down list with a default option, the default option is not displayed and is shown as blank.
- Click Save or, to create another custom field, click the drop-down icon, select Save, and add another.
- Save the Field ID of the field you just created as you'll need it when using the metadata API.
Once created, developers can use the /api/v2/ticket_fields
API to
view conversation field data. Here is an example response:
[
{
url: "https://z3n-lhills.zendesk.com/api/v2/ticket_fields/10093547287955.json",
id: 10093547287955,
type: "integer",
title: "Bike Order id",
raw_title: "Bike Order id",
description:
"An API will populate this bike order id value",
raw_description:
"An API will populate this bike order id value",
position: 9999,
active: true,
required: false,
collapsed_for_agents: false,
regexp_for_validation: "\A[-+]?\d+\z",
title_in_portal: "Bike Order Id",
raw_title_in_portal: "Bike Order Id",
visible_in_portal: true,
editable_in_portal: true,
required_in_portal: false,
tag: null,
created_at: "2022-10-04T04:48:05Z",
updated_at: "2022-10-04T04:48:05Z",
removable: true,
agent_description: "Order id from our bikes catalog",
},
]
Clearing the conversation field
There may be times when you must clear the conversation field values. This depends on your use case and is done when the retrieved data is no longer valid. For example, suppose you are using conversation fields to collect data from an end user’s online cart. If the end user deletes all items in their cart, your collected data is no longer valid, and you can clear those conversation field values.
You clear conversation fields using the clearConversationFields(
)
API.
Adding a conversation tag
Tags are words or combinations of words you can use to add more context to tickets and topics. You can apply tags to tickets, users, and organizations. For example, tag all requests that are actually sales inquiries with a tag like 'sales' or 'about_sales.' You can then create a view or a report to track these requests.
For more information, see About tags.
Using the metadata APIs
See Using Messaging Metadata in the developer documentation for an example of using the metadata APIs.
Setting conversation fields and tags
You set the conversation field values using the
setConversationFields
API. For example, if your custom
ticket field ID is 10093547287955 and you want to set its value to the string '548832222',
then you would call:
zE('messenger:set', 'conversationFields', [{ id: '10093547287955',
value: '548832222'}]);
If you use a custom drop-down field or any field that associates a field value with a tag, setting the custom field value also sets the custom tag value in the resulting ticket.
Here is an example response for setConversationFields
:
conversation: {
...
metadata: {
"zen:ticket_field": "30289064739483",
...
},
}
{field ID}
must be a string. If not, it
will be converted to a string. {value}
must be a string,
number, or boolean.You set conversation tag values with the setConversationTags
API. Similar to the setConversationFields
API, if you set a
custom tag associated with an editable custom field, then the custom field is
set. If the custom tag is associated with a private (non-editable) custom field,
then the custom field is not set.
Client-side API to set conversation tags | |
---|---|
Web Widget | zE('messenger:set',
'conversationTags', ['{tag value}', '{tag
value}']) |
iOS | Zendesk.instance.setConversationTags(["{tag value}",
"{tag value}"]) |
Android | Zendesk.instance.setConversationTags(listOf("{tag
value}", "{tag value}")) |
Unity | ZendeskSdk.Instance.Messaging.SetConversationTags(List<string>
tags) |
Here is an example response using
setConversationTags
:
conversation: {
...
metadata: {
"zen:ticket:tags": "likes-nike-trainers, frequent-shopper",
},
}
Clearing conversation fields and tags
You can clear conversation field values and tags when the client side context changes. For example, the end user moves away from a product page to your main store landing page. Any data you collected from that product page is no longer valid.
To do this, use the ClearConversationFields
and
ClearConversationTags
APIs. These clear all conversation
fields and tags. You cannot clear an individual field or tag.
Client-side API to clear conversation fields and tags | |
---|---|
Android |
Zendesk.instance.clearConversationFields()
Zendesk.instance.removeConversationTags()
|
Unity |
ZendeskSdk.Instance.Messaging.ClearConversationFields()
ZendeskSdk.Instance.Messaging.ClearConversationTags()
|
Bot builder
Fields updated using the metadata APIs will be populated with existing data and can be edited by end users when presented with this step. For more information, see Understanding answer flow step types and Creating custom ticket fields.
22 comments
Allison Sargent
Hello! Quick question, how is this different from the "Ask for details" step that is currently offered in the Flow Builder UI?
0
Vishal Khandate
Is there any way we can update conversation fields when using Web Widget classic?
0
Federico Costa
Can i use metadata to assign the email, so i don't need to ask that information to the end user?
5
Raphaël Péguet - Officers.fr
Federico Costa of course.
Allison Sargent this is different because ask for details asks the questions to the customer whether here you can populate the answer based on information of your website without asking.
@Zendesk Can you certify that others metadata than the 4 about authentication (mail, name, external id, status) can be used as variables in the flowbuilder please??
It would be nice that you add screenshots to reassure people that metadata are shown in the flow builder
0
Oscar Mejias
The answer type "Ask for details" is the flow builder step that allows your end users to interact with conversation fields. Now, these conversation fields could either be filled out manually by the end-user or they can be pre-filled with metadata through clients API.
This is where Using conversation metadata with the Zendesk Web Widget and SDKs comes into play.
I hope that clarifies!
0
Abdulwahab wahab
Hi thanks for this feature but I faced a problem in displaying tags in existance conversation if the conversation is new then tags and custom field is show but on existence conversation tags and custom fields not show
0
Dane
Are you pertaining to the actual bot builder fields or is it a scenario when there is an existing conversation and the tags and field no longer show for your customers? Can you elaborate further?
0
Abdulwahab wahab
Hello @Dane, originally, we incorporated the Zendesk messaging SDK into our application for live customer support. Currently, there is a need to transmit specific custom data, such as the user's city, to Zendesk chat. Fortunately, we identified the Zendesk metadata feature in the SDK and attempted to send the city as a TAG within the conversation using the following code
However, in existing chat conversations, the city tag does not appear in the conversation agent panel. Conversely, when initiating a new conversation with the user, the city tag is displayed in the conversation agent panel.
0
Dane
Based on Messaging Metadata, it will only be added to new conversation or if the end-user have sent a message in existing conversation. Just in case you are experiencing an unexpected behavior, you can contact our support directly for further investigation.
0
Chad Susa (Gravity CX - Zendesk Partner)
I have a scenario where only half of 'our' customers have email addresses. Yes hard to believe but many older folk don't have an email address and prefer to interact over the phone. We are legally bound to provide services via phone.
We would like to offer customers who don't have email a way to submit a 'callback' request and have their phone number identify their profile in Zendesk when they reach out via messaging so requests (tickets) are created under the same profile.
Currently I can't find an easy way that this can be done, if at all. The fields we want them to complete when asking for a 'callback' are Name, Phone Number (at present this is a custom field as the standard identifier user phone number 'field' is not accessible in messaging) and Preferred callback time (custom field).
Funnily enough, if a user exists in Zendesk with ONLY a phone number (direct line), the talk channel correctly ID's the caller with their standard identifier user phone number 'field' each time they call (as long as the caller ID is not blocked), the ticket is created under the same user profile - perfect. Callbacks on the classic widget ID the user via the entered phone number as well.
However, currently there is no way to reconcile the Phone Number custom field with a user contact phone number (direct line) in Zendesk via messaging.
Here is a small loom that helps illustrate the issue.
When the customer completes the phone number field, this is simply a custom field and doesn't identify with the customer real profile in Zendesk (which has a standard identifier phone number 'field') - this results in many end users with the same name and not under the single/same profile. Lot's of searching, merging and not very good for agent efficiency.
I can't even direct customers to a form on the help centre as you must have an email address to submit a form and even if they entered in a junk address, the same issue would occur with many user profiles created.
Does anyone know a way to solve this? I'm guessing customers would need to login to our system first (web portal) which is not feasible as we want to offer the widget and contact options to customers without an account with us as well. They could exist in Zendesk but not in our system.
I see the best way forward is to offer the standard identifier phone number 'field' as an option in the 'Ask for details' step - similar to asking for their email address.
It looks like this standard identifier can already perform the function of matching a user but it's just not available in messaging, but the email standard identifier is. What's the difference?
0
Dane
What I did on my end, is to create a custom text field for phone number and have added a specific message on how to enter the correct format.
Afterwards, I have created a webhook for user update.
This is the endpoint I used:
https://<yoursubdomain>.zendesk.com/api/v2/users/{{ticket.requester.id}}.json
I have created a trigger using this endpoint.
This is the JSON Body:
The only issue here is the customer can make mistakes on entering the phone number.
0
Chad Susa (Gravity CX - Zendesk Partner)
Hi Dane
Many thanks for providing this solution. Really appreciated.
Unfortunately this doesn't quite solve the problem. In my testing, each messaging 'chat' created a new end user with the same Phone Number under their contact. It doesn't actually create the ticket under the single profile. I think the phone number is added a shared number.
I think it has something to do with user identities but manipulating a user identity from a webhook is either way too hard for my feeble brain or not possible ;)
The only solution I can think of is to create a process using the API to search users based on their phone number, if a user is found (already exists) then merge these two profiles together.
Problem is we'd have to store the user ID somewhere so we can use to execute the merge.
Thanks for your help though. Would be great to be able to add the user Phone Number 'field/identity' to a messaging bot flow to identify users based on the phone number.
0
Dane
1
Bobby Koch
will there ever be a time we can just call the zendesk crm for this data? we have the user authenticated, we should be able to use that data in the flow by calling the user api. building these out after already doing the authentication peice is going to be hard to get resources allocated to, and it seems lke it should be possible
1
Zaffar Sayed
Dane
I am working on Messaging, Bot and Automation. I want to add custom field for my bot, can you please suggest a way to add these custom field for the Bot. I have created custom field and enabled it for end user. However, I can't see those in my custom field of Bot.
Is there a different way to add custom fields for Bot and automation?. I have searched a lot through the documentation and community but did not get a satisfactory answer.
I am simplifying my requirement, I am moving to Bot and Automation and testing bots for messaging.
Under Admin Centre > Channel > Messaging > Edit Bot > Under responses you get this section as shown in the image.
I have created custom field for Number and other details however and I can't find it under the customer details dropdown. There are only 2 predefined sections here Name and Email. Is there a way to add more fields. Please suggest.
0
Chad Susa (Gravity CX - Zendesk Partner)
Hi Zaffar Sayed
I believe only drop-down and text fields are supported in the bot builder.
Check out: https://support.zendesk.com/hc/en-us/articles/4766497566106-Why-aren-t-all-my-custom-fields-appearing-as-options-in-the-bot-builder#:~:text=Answer,display%20up%20to%20ten%20values.
1
Zaffar Sayed
Chad Susa (Gravity CX - Zendesk Partner)
Thank you for the response. It is helpful.
0
David Lewanda (Dave)
Two questions:
Thanks in advance for your answer.
0
Walter
Hi Gary,
Can you please confirm if Multi-line can be displayed in the conversation? I've tried, but I can't seem to access it in the Bot Builder.
0
Peter Gustafsson
We're building a chat with 100% custom UI using Smooch SDK's.
I have created a custom field for “App Market” which I would like to use to send metadata about the users selected market/country. The idea is to use this value in a trigger to assign tickets to different agents.
But I'm having trouble finding a way to set that metadata from the app using your SDK. We are using Sunshine Conversations for iOS and Android (Smooch)
The class reference for iOS only lists a getter for metadata.
https://docs.smooch.io/api/ios/Classes/SKTConversation.html#/c:objc(cs)SKTConversation(py)metadata
Do we need to use the REST API to set the metadata?
The REST endpoint I'm thinking of using.
https://docs.smooch.io/rest/#operation/updateConversation
0
Jason Kadlec
I'm confused on something pretty basic… I want to use variables in branch by condition steps in the flow builder.
I do not want users to have to set these variables, I want them to be always set by the .js api using things like button clicks or even the current URL the person is on.
In the flow builder, I have to add a "Set Variable" step before the branch by condition step, and I can't save the ‘set variable’ with no value, so I have to type one in.
The problem is that I'm trying to create a default_start answer which I want to check the variable, and based on that variable's content, start up a specific answer that matches the context I know them to be in (by the variable).
But if opening the chat for the first time starts the default_start answer, and the first step of that answer is to set the variable to “start_init” - that will overwrite whatever the API would have passed in when the chat first opens?
What's an alternative way to achieve this goal:
I have a web application and people will start a chat from either clicking on the chat icon, or by clicking on a button.
Clicking on the chat icon ideally needs to load a different Answer/Flow depending on where they are in the app …. I was hoping to pass the current URL into the variable when the chat gets opened.
Clicking on a button in the app to open the chat needs already a specific answer loaded - for example the button says:
[ Click here to give me zebra facts ]
I want the click on that button to not trigger the opening “hi I'm the chat bot how can I help you”.. it should instead load the “Zebra Facts” answer which has the chat bot say a bunch of interesting zebra facts.
[Click here to apply to become a zoo keeper ]
^ this would open the chat bot to an answer that has the application form in the chat window so they can apply/create the ticket etc.
tl/dr - how do I route the initial click on opening a chatbot to go to a specific answer based on a variable set by the .js api.. without the flow builder overwriting the value?
3
Catalin Prata
Hello, thank you for the thorough article!
Is there a way to pass down thses config fields from zendesk to the Ultimate chat bot? I am using that on Android with Zendesk SDK for Android but I don't know how to pull the custom fields to Ultimate dashboard.
Thank you!
0