Jacquelyn Brewer

To make it easy for admins to identify the sample data and configurations, all of their names begin with [SAMPLE]. This preface isn't displayed to requesters in tickets cases where the name is visible to both agents and requesters. However, it's a good idea to remove this preface from the names of any sample data and configurations you decide to use in your workflows.

It's also important to understand that all of the sample data and configurations for employee services are active by default. That means, unlike Customer Service Suite and Support plans, Employee Service Suite plans have multiple groups, brands, and ticket forms from the start. This changes some expected behaviors, so it's important to identify which of these are applicable to your use case, and deactivate everything else.

For example, new Employee Service Suite plans have multiple brands and omnichannel routing on by default. However, omnichannel routing doesn't recognize which brands agents belong to and tickets are associated with, which can lead to issues. See Using brands (department spaces) with omnichannel routing.

When inspecting an environment's configuration, you can save a snapshot of the configuration as it exists at that time.

If you need to look back at a previous configuration for an environment, you can use the Versions page to open read-only versions of saved historical configurations.

Versions are read-only. After a version is saved, the only thing that can be changed is the version's name.

If you no longer need a version, you can delete it. Deleting a version is permanent and can't be undone.

The Compare versions page in Admin Center allows you to compare two read-only saved versions of your environments. You can compare two versions of the same environment, or versions of two different environments.

When viewing a comparison, you can drill-down into each configuration to see what has been added, modified, and deleted. Within the comparison, old versions of a configuration are highlighted in red and new versions of a configuration are highlighted in green.

Consider the following information before authenticating end users for messaging:

When an end user is authenticated, agents see a green check mark icon next to the visitor's name in conversations and the end user's external ID in the user's profile.

Additionally, each response posted by an end user after they're authenticated has the check mark icon.

Authenticated end users can participate synchronously in a conversation across devices.

After you implement end-user authentication for messaging, end users shouldn't notice much of a difference. After they've been authenticated and their identity is verified with Zendesk, end users aren't prompted to provide their name or email address by AI agents for messaging as part of the default messaging response.

Conversations for authenticated end users are synced across devices when the end user is authenticated. Separate user records and conversations are created for unauthenticated end users. If an end user authenticates mid-conversation, the anonymous conversation that was created before they signed in is automatically merged with the authenticated conversation to provide conversational continuity.

Inspecting configurations provides a big-picture view of an environment.

When inspecting an environment's configuration, you can save a read-only version of the configuration as it exists at that time. After a version is saved, you can view, edit, and delete it from the Versions page in Admin Center.

Zendesk has already defined some standard relationships, such as users to tickets (ticket requester, assignee, followers), tickets to organizations, agents to groups, and so on. Admins can also use lookup relationship fields to define custom relationships between objects. Lookup relationship fields are how the data in custom object records is integrated into your Zendesk workflows, but can also be used to define custom relationships between standard Zendesk objects. However, unlike the standard object relationships which can be one-to-many or many-to-many, lookup relationship fields always define one-to-many relationships.

There are many valuable use cases for complex many-to-many relationships. However, let's work through an example of an IT team managing assets assigned to employees. In this scenario, employees are typically assigned to multiple assets and some assets can be assigned to more than one user at a time.

In this scenario, the junction object is used to connect multiple users and assets. This is accomplished by adding at least two lookup relationship fields to the object, one connecting to each of the primary objects.

To build out the relationships between assets and employees, you'll create asset assignment records. Because of the lookup relationship fields, the data in the asset assignment records is visible in the related object's records, too. In this case, an employee's profile will list all assigned assets and an asset record will list all assigned employees.

For the purposes of this example, we're going to add asset assignment records involving two agents (William Carlton and Harper Yoshimotot) and three assets (A001, A002, and A003).

Liquid is a templating language for rendering HTML. It's the mechanism that enables the automated placement of data in email notifications using placeholders. In addition to placeholders, Liquid can also be used to create simple programming logic about how the content is expressed in the notification, such as if/else statements, case statements, and variable assignments.

For more information and examples, see Understanding Liquid markup and Zendesk Support.