Submit a request

Support Centre

Escalator User Guide (v1)

1 Overview

Vendor escalation is a technique of raising a ticket with a third party company to perform some work or investigate a problem. An example of this is the following:

A theatre company receives a ticket complaining about broken chairs in the the auditorium. The theatre company escalates the issue to the auditorium owners to ask them to fix the chairs by creating a Vendor ticket using Escalator. In this case the vendor was the auditorium owner.

The “Escalator” app implements a simple vendor escalation model. By selecting a vendor from a dropdown list, a ‘vendor’ sub-ticket is created and linked to the ‘parent’ or ‘problem’ ticket, and listed in the Escalator app in the Apps panel when viewing the ticket. This vendor sub-ticket would have the vendor as the requester.

This guide is written based on version 1.0.2 of Escalator.

2 Installing Escalator Data Field

Once Escalator has been installed on Zendesk using license key, some additional setup is required before Escalator can be used: data field.

To do so, on Agent left sidebar, there should be Lovely app (a cloud icon). This app is to configure Escalator and all other Lovestock & Leaf apps.

Click on Lovely (cloud icon) -> Escalator -> Requirements -> Install

This will install the required data field for Escalator. Once done, the data field ID on the config screen will change from 0 to the ID of the newly created field; indicating we’ve successfully installed the data field and can start configuring/using Escalator.

Important (Enterprise only): if there are multiple ticket forms on your Zendesk, please go to each ticket form (Zendesk Settings->Ticket Forms) and add LL_Data_Escalator field to each ticket form.

3 Configuring Escalator

3.1 Using Lovely app

Escalator should ideally be configured using the "Lovely" app. The "Lovely" app is found on the left hand side menu bar and has a "cloud" icon.

On click on Lovely (cloud icon) -> select Escalator to configure Escalator.

The config is in YAML, so spacings/vertical alignment between each config levels are important, otherwise the config becomes invalid or is not meant to function as what it was meant to.

For example, this is invalid because the “requester” option is not having same spacing as other options:

  name: Fictitious Company
 requester: 123
  subject: “This is subticket subject”

It should be changed to as below:

  name: Fictitious Company
  requester: 123
  subject: “This is subticket subject”

3.2 Vendors

3.2.1 Quick Start:

A vendor can be setup in Escalator within a few simple steps:

  1. Create an end-user account for this vendor on Zendesk (Add -> User)
  2. Find out the user ID of this end-user by opening the user profile (it should automatically open after the user is created, or we can search Zendesk by email of existing user). The user profile will have URL in the browser similar to this:

    where 199070066 is the user ID. Note down this number.

  3. Open Lovely -> Escalator, and put in the following config with name and user ID:
      name: "Vendor A"
      requester: 19907006


  4. Save the config and reload Escalator.

The setup is done and "Vendor A" is ready for use in Escalator.

The escalated ticket for this Vendor A will have requester 199070066 (which is the vendor - the end-user account we created at step 1). And they can start discussing issue in that escalated ticket with the agent, separately from the original ticket.

3.2.2 Advanced Config:

There are more options that can be put in each vendor config beside "name" and "requester" as in the quick start section above. This is the full list:

  name: Fictitious Company
  requester: 123
  assignee: 567
  subject: “This is subticket subject”
  publicComments: true
  privateComments: true
  inheritFields: true
  inheritTags: true 
  attachments: true
  comment: A comment
  subTickets: false 
  status: open

The top level entry (fictitious_company) is the tag value for the vendor you are escalating to. This should not contain spaces, but it can contain underscores (_).

Within the tag there are following options:

  • Name: (required) This is the friendly name for the tag. This is what is presented to the user. This is a mandatory field which must appear for each top level vendor configuration.
  • requester: (required) This is the ID of a person who will become the requester of the escalated ticket. If not provided or is set to 0 (zero), the current agent will be the requester. Typically this should be the Zendesk user account ID of the end-user at the vendor company.
  • assignee: (optional) This is the ID of a person who will become the assignee of the escalated ticket.

    _ If not provided, the system will default to current user*
    _ If set to 0, the ticket will not be assigned to anyone.
    _ If set to “inherit”, the assignee of escalated ticket will be set to current assignee of the ticket

    * Current User: the agent doing ticket escalation

    Make sure you carefully set this value. If your agents who are escalating tickets do not have access to the assignee’s group, the tickets will not be re-assigned.
  • group: (optional) (version 2.1.11 onward only) This is the group ID for the escalated ticket.

    _ If set to “inherit”, the group is same as the original ticket's
    _ If not set and:
    • if assignee of the escalated ticket is same as current user*, use default group of current user (if user does not have default group, use their first group)
    • if assignee of the escalated ticket is different to current user, the group will be same as the original ticket's group.
      (Note: this may not work if the assignee does not belong to the group of the original ticket's).
    • if the escalated ticket does not have assignee, the group is not set.

      * Current User: the agent doing ticket escalation

  • subject: (optional) the pre-filled ticket subject for the escalated ticket. This supports placeholders.
  • status: (optional) can be “inherit” (using the current ticket status) or “pending”, “open”, “solved” or “closed”.
  • publicComments: (optional) This is a boolean setting that determines whether the public comments should be included when you escalate the ticket to a vendor. This means that all public comments are included by default when you escalate a ticket. This is optional. The default value for this value is “false”.
  • privateComments: (optional) This is a boolean setting that determines whether the private comments should be included by default when you escalate the ticket to a vendor. This means that all private comments are included when you escalate a ticket. This is optional. The default value for this value is “false”.
  • attachments: (optional) This is a boolean setting that determines whether attachments should be included by default when you escalate a ticket to a vendor. The default value for this is “false”.
  • comment: (optional) This is the default comment text which is displayed in the “Comment” field when you escalate the ticket. The default value for this is an empty string. This supports placeholders.
  • subTickets: (optional) Allows you to escalate a ticket from a ticket that has been escalated from another ticket. By default you cannot re-escalate a ticket from an already escalated ticket. If you set this to “true” then this overrides the setting and allows you to escalate again. This is optional. The default value for this is “false”.
  • inheritFields: (optional) if set to “true”, the escalated ticket will have the same field values as current ticket. Default value is “false”
  • inheritTags: (optional) if set to “true”, the escalated ticket will have the same tags as current ticket. Default value is “false”

User IDs can be found via the ID Viewer in the Cloudmetro Lovely app (cloud icon) or by opening the user profile on Zendesk and look for the ID in the website URL.

3.3.3 ll-default config:

“ll-default” is a special vendor entry that is used as the base for all vendors, so that if the vendors share the same options, we don't need to put them in each Vendor config.

If an option is not specified for a vendor, the setting under ll-default will be used for that vendor.

Same as normal vendor entry, the config for “ll-default” can contain all options or only some options to be applied to all vendors.

  requester: 0
  assignee: 0
  publicComments: true
  privateComments: true
  attachments: true
  comment: “”
  subTickets: false

A full sample config is as below with a base setting and 3 sample vendors. The base setting (ll-default) will apply to all vendors. If each vendor has matching option, the vendor option will override the base setting. More details of each option will be provided later in this guide:

  publicComments: true
  privateComments: false
  attachments: true
  subTickets: false

  name: Fictitious Company One
  requester: 123
  assignee: 456
  comment: some comment for fictitious company one

  name: Fictitious Company Two
  requester: 111
  assignee: 555
  comment: some comment for fictitious company two

  requester: 888
  assignee: 999
  name: Fictitious Company Three
  privateComments: true
  comment: some comment for fictitious company three

In this case all three companies inherit from the default values. The third company then overrides the “privateComments” setting.

3.3 Placeholders

Placeholders can be used in the config to insert dynamic contents. “Subject” and “Comment” support placeholders.

Placeholders are recognised by putting inside double curly brackets.

For example:

  name: “Sample PlaceHolder Replacement”
  subject: “This is a subticket of {{}}”
  comment: “The original ticket subject was: {{ticket.subject}}”

The result:

Full list of supported placeholders:

  • ticket.subject
  • ticket.description
  • ticket.status
  • ticket.priority
  • ticket.type
  • (version 2.1.4 and later)

4 Using the Escalator app

The “Escalator” app appears in the Apps panel for existing tickets. You will not see it if you are creating a new ticket.

The app has a single drop-down listing the possible vendors that you can escalate the ticket to. The list of vendors is configured by the administrator. Further details are in the administration section later in the document.

The text below the app name notes whether this ticket has any vendor escalated tickets which were created from it, or whether the current ticket is an escalation from another ticket. Screenshots of this are in the “Escalate to vendor” section of the document.

4.1 Escalate ticket to vendor

When the agent selects a vendor to escalate a ticket to, the following modal screen appears:

This has the following options for the agent:

  • Subject: This is the subject for the escalated ticket, and is set to the current subject as the default value. This can be modified, and cannot be empty.
  • Comment: This is the comment that is added to the escalated ticket. This should not be empty, as this is how you would inform the vendor what you require from them.
  • Close: This button will close the modal screen and take no action (cancel the operation). This is the same as clicking on the “X” at the top right of the modal screen.
  • Escalate to vendor: This will create the new escalation ticket which is sent to the vendor, and marks the new ticket as a sub-ticket of the ticket you escalated from.

If you are an agent and the configuration is set to assign the ticket to another agent who is not in one of the groups that you have access to, then the ticket will be assigned to you. Administrator users can assign tickets to anyone.

If you are an agent and you escalate a ticket and you want to attach previous comments individually, the timestamp for adding the comments will be the time you escalated the ticket. The app adds the timestamp at the top of each individual comment.

4.2 Including existing comments

The agent has the ability to include comments from the ticket which is going to be escalated from. This way relevant information in the original ticket can easily be sent to the vendor. Clicking on the “Include” button will include that comment into the escalated ticket. By clicking the “Exclude” button (which is the opposite of the “Include” button) the comment will be excluded from the escalated ticket.

If the agent has chosen to include the comment, they also have the opportunity to edit that included comment. A common reason for editing included comments is to remove details such as bank account details, or personally identifying information that should not be passed on.

An example where the agent has chosen to include a comment is shown below:

The screenshot above has the “Exclude” button which you would click on to exclude this comment from the escalated ticket. In this state the comment will be included in the escalated ticket.

The agent can also include or exclude attachments which were included in the escalated from ticket.

In the example above the first attachment on the left has been excluded. The “Include Attachment” button and the greyed out attachment signify this. The second attachment on the right have been chosen to be included which is denoted by the “Exclude Attachment” and the solid attachments.

A screenshot for where the agent has chosen to exclude a comment is shown below:

Here you can see that the entire comment and subsequently the comment’s attachments have been excluded from the escalated ticket.

4.3 Escalate to vendor

The vendor escalation ticket is created by clicking on the “Escalate to vendor” button. This creates a new ticket with the comments as defined by the agent. The new ticket is marked as a sub-ticket of the ticket that was escalated from.

The app now displays as follows for the vendor escalated ticket:

Normally you can not re-escalate an escalated ticket. However there is a setting which allows you to re-escalate a ticket. If you have chosen to be able to re-escalate a ticket, the app will display as follows:

The app is displayed as follows for the escalated from ticket:

In both cases the ticket number is a clickable link which will take you to the nominated ticket.

4.4 FAQs

1. How can a 3rd party interact with the ticket without using the Zendesk Help Center?

If you don't want the 3rd party to log in on your Zendesk like a conventional end-user, you can have separate notification emails without the ticket link for tickets that are tagged as escalated tickets.

2. Does the 3rd party get inserted as the Assignee, if so, does this require an Agent account for each?

No, the 3rd party will be the requester on the Escalated sub-ticket, and can be an end-user.

3. What happens when escalating to a vendor that also uses a ticketing system?

The escalated ticket is a normal ZD ticket that is just linked to the original ticket via the app, so if they have a ticketing system that replies automatically by sending out its own notification email, it will create a new ticket on your Zendesk just like with any other ticket.

Have more questions? Submit a request