Support requests

Support requests

Zendesk Support allows users to submit support requests through a conversational UI or a non-conversational form and email-based interface. Support requests are also known as tickets.

The Support functionality allows users to submit requests with standard and custom field inputs as well as file attachments. This functionality is available natively in Android, iOS, Windows, and OSX. The responses from your customer support team can be received, read, and replied to in-app by your users with the conversational view enabled. Alternatively, the responses can be routed to the user's email address following their request submission.

All support requests can be submitted with any specified tags. By default, the Zendesk UI's buttons allow you to specify a tag that should be sent with every request. The tags can be overridden in the Inspector.

Note: The Zendesk back-end does not trust input sent from the client and will strip or escape any input before displaying the data in the Zendesk agent interface. If you send any data back to your own data store, Zendesk recommends validating and sanitizing the data before ingesting it.

Choosing a view

You can give users a conversational or non-conversational view for submitting support requests.

Be aware of the following considerations:

• If you use the conversational view in your app, consider that end users can't enter their email and name to authenticate. Instead, you can set end users' identity (email and name) in the code with the SetAnonymousIdentity method of the ZendeskMain.cs class. The SetAnonymousIdentity method only works for the conversational view. If you don't set the email and name fields for the end user, a unique identifier is used to authenticate. No email and name are associated with the user.
• If you use the non-conversational view in your app, end users can enter their email and user name to authenticate when they create their first request. The information is saved automatically and used for future requests.
• If you don't set the identity for end users in the conversational view, we recommend not converting your application to the non-conversational view. After converting the application, the end users retain their previous identity and they won't receive any emails.

Using a conversational view

Important: Conversations feature is not available on Essential plans.

The conversational view lets users send and respond to tickets in-app in a chat-like interaction.

By default, users are prompted to enter their message and receive feedback noting that their request has been received. Images can be attached using the standard attach icon on the chat pane.

Any responses sent from agents in Zendesk are viewable by the user in-app, including any rich text and links. If the agent includes a help center link in the response, the end user can tap the link to open and read the article natively in the Zendesk SDK without having to launch any external browser or wrapper.

External links are also supported in the responses. These will open in the end user's browser as normal.

Conversational requests can be refreshed with a pull-to-refresh motion of dragging down and then releasing the view panel.

Users can use the Support/My Tickets panel to view their request history and any responses received. This panel also serves as a safe spot to always direct users to when launching your application. Any user without open requests will be prompted to create one if needed. See the image below.

Using a non-conversational view

Non-conversational tickets allow an end user to create a support request in-app with the intention of getting an email response.

Non-conversational tickets support custom fields as well as in-line image attachments. See Adding custom fields. Users will only be prompted to enter their name or email once. The information is automatically populated in subsequent tickets.

After successfully submitting a request, the end user is prompted to return to the application. See image below.

Adding custom fields

Custom fields allow you to send additional data with every support request. Custom fields can be visible or invisible. Visible fields are completed by users. Invisible fields are populated with application-provided data through an ActionDelegate method.

You can define custom fields in the Support admin interface (recommended) or manually in the Unity editor using the Inspector.

Custom fields also support localization to any Zendesk-supported language.

For details on adding custom fields along with hooking them into your Unity application, see the following documentation:

• Defining custom fields in Support
• Adding visible custom fields
• Advanced options
• Translating custom field labels
• Sending invisible custom field values

Defining custom fields in Support

Custom fields must be defined in the Support admin interface before you can place them in your Unity application.

See Adding custom fields to your tickets and support request form in Zendesk help. You must be a Zendesk admin to define custom fields. If you're not an admin, ask one to define them for you.

The Unity SDK currently supports the following field types:

• Text
• Multiline
• Checkbox
• Numeric
• Decimal

Ensure that the permissions of any field meant to be visible is set to Editable for end users in the Support admin interface.

Once complete, the new custom fields should appear in the Ticket Fields page in Zendesk Admin. Note the Field ID of each new field. The values are required for inserting the fields into Unity.

After adding any other additional custom fields required by your project, it is strongly recommended that you download the CSV to ensure that your Unity form settings are in sync with your Zendesk settings. The CSV download button is next to the Add Field button on the Ticket Fields page in the Support admin interface.

Warning: If your custom fields are set up incorrectly in the Support admin interface, your application may experience unwanted behavior. As such, we strongly recommend setting up all fields in the Supoort admin interface before attempting to add or import them into your Unity project.

Adding visible custom fields

Visible custom fields let a user include more information in a support request.

To add the visible custom fields into Unity

1. Import the ticket fields CSV downloaded from Zendesk into your Assets folder in your Unity project.

   In Zendesk, the CSV download button is next to the Add Field button on the Ticket Fields page in the Support admin interface.

2. Select the Support GameObject in the Zendesk prefab.

3. In the Inspector panel, select the Custom Fields tab and drag your ticket fields CSV into the Custom Fields component.

4. Click Load Custom Fields from CSV File.

Advanced options

Validation messages for required fields can be added under the generated Request Form array.

While additional options can be configured directly in the Request Form array, it is strongly recommended that you rely on your ticket fields CSV to generate these options for you. Any mismatch between your Support admin settings and Unity project settings may result in unexpected behavior.

Translating custom field labels

If you have localized translations for custom fields, you can attach them with the Custom Field Translations component in the Inspector window. Place the custom field translations in a CSV with the following format.

• The first line of the CSV should start with an empty value (,) then list the ICU language codes of the supported languages. For example:

,en-US,pt-BR

• All subsequent lines should start with a unique identifier for the string to be localized, followed by the translations of the string in the corresponding languages on the first line. For example:

  usdk_cf_{custom-field-id}_label,Hello,Olá

Example

,en-US,pt-BRusdk_cf_123_label,Contact Number,Número de Contatousdk_cf_123_validation_message,Contact Number is required,Número de Contato é obrigatóriousdk_cf_456_label,How many hours have you played this game?, Quantas horas você jogou esse jogo?

Sending invisible custom field values

Before you start, make sure you have the field IDs from the Support admin interface. See Defining custom fields in Support.

You will need to create a script that references the ZendeskSupportUI component and passes through a Dictionary type containing any custom field values.

The ZendeskSupportUI component contains SetInvisibleCustomFields and AddInvisibleCustomField methods which must be invoked prior to your user submitting any Support ticket.

SetInvisibleCustomFields

The SetInvisibleCustomFields method should be invoked with a Dictionary<long,string> parameter, which should contain any relevant KeyValuePair items configured with (long) Custom_Field_ID keys and (string) Custom_Field_Value values.

The SetInvisibleCustomFields method has the following parameter:

Example

Dictionary<long,string> invisibleCustomFields = new Dictionary<long,string>;
invisibleCustomFields.Add(1,"test");invisibleCustomFields.Add(2,"123");
zendeskSupportUI.SetInvisibleCustomFields(invisibleCustomFields);

Sets invisible custom fields. You can only set invisible custom fields when the request is created. Agents can update custom fields after the request is created. If you need to update a custom field after the request is created, ask an agent to do so.

AddInvisibleCustomField

The AddInvisibleCustomField method should be invoked with a long and string parameter, which should contain a (long) id and (string) value values. It will be added to the existing Custom Fields list.

Parameters

Example

zendeskSupportUI.SetInvisibleCustomFields(1, "invisible custom field value");

Enabling Customer Satisfaction (CSAT) surveys

Customer Satisfaction (CSAT) allows users to provide ratings on any support requests marked as solved.

Once a request is marked as Solved by an agent in Zendesk, the end user will be prompted to provide a Good or Bad rating. Optionally, the end user may choose to respond to the ticket if they want to re-engage with support.

To see the CSAT screen after a ticket is marked as Solved, the end user must refresh the ticket. The ticket can be refreshed by pulling the ticket details screen or by closing the ticket and opening it again. Once the ticket is refreshed, the end user will be able to see the CSAT screen.

CSAT must be enabled in your app settings on the Mobile SDK page in the Support admin interface to function in your Unity project. If an app ID is shared between projects built on other frameworks (such as using Zendesk's standalone Android or iOS SDKs), CSAT will only work in your Unity project.

Getting request updates

The ZendeskSupportProvider has a method called GetRequestUpdates which can be used to check if there are any updates to an end user's tickets. This can be used to create a visual indicator for your users when there has been activity on their requests.

ZendeskSupportProvider supportProvider = zendeskObjectInstantiated.GetComponent<ZendeskMain>().supportProvider;
supportProvider.GetRequestUpdates(GetRequestUpdatesCallback);
private void GetRequestUpdatesCallback(ZendeskResponse<ZendeskRequestUpdates> response){	if (response.Result.hasUpdates)	{		Debug.Log("Total new comments: " + response.Result.newComments + "\n");
		foreach (var item in response.Result.requestUpdates)		{			var text = consoleText.text;			text += "\n Request Id: " + item.id;			text += "\n New Comments: " + item.newComments;			text += "\n ----------------------------------------------------------";			Debug.Log(text);		}	}}

This method caches ZendeskRequestUpdates for up to an hour. Any subsequent calls within that timeframe will return the same cached object without querying the network. Viewing a request will update it from the cached object, since the updates have now been seen. This is done when the request's comments load in the conversational view. If you have implemented any custom UI, you can mark a request as seen by calling the following method:

ZendeskSupportProvider supportProvider = zendeskObjectInstantiated.GetComponent<ZendeskMain>().supportProvider;
//Mark all request updates as readsupportProvider.MarkRequestAsRead();
//Mark only the requests in the list below as readList<string> requestIds = new List<string>(){"requestId1", "requestId2"};supportProvider.MarkRequestAsRead(requestIds);