Ticketing Configuration Overview

This document serves as a overview for configuring ticketing and supporting configurations end-to-end within Moveworks. Follow these steps to seamlessly connect your ticketing system with Moveworks.

The sections below walk through the configuration steps for each Ticketing systems.

Connect Your Ticketing System in Three Simple Steps

  1. Select the Source Ticketing System: Choose the appropriate connector for your ticketing system.
  2. Classify Ticket Types: Select ticket types and relevant tables or projects from your existing Ticketing system, which you would like to integrate into Moveworks.
  3. Select Ticket Types and Databases: This is where you configure Ticket Mapping and Ticket Action Payloads that get used by the Moveworks AI Assistant for ticketing actions such as querying, creating, updating, resolving, and reopening tickets.

Connect to a Ticketing system

  1. Navigate to Ticketing > Ticket Settings > Ticket Mapping and click on New Ticketing System Setup.

  1. Enter a Name for the ticketing system - Be sure to assign a clear and concise config name for the integration to ensure easy recognition by all users. It's useful to indicate the team (i.e: IT, HR, Finance, etc.), and the level of the environment (i.e: Prod, Sandbox, Dev, etc.).
    2. Example: Use names like "Servicenow-IT-prod" or "freshservice-HR".
  2. Enter the Bot Service account Id. This is typically the backend user ID for the service account in your Ticketing platform. In ServiceNow, this is the sys_id.
  3. Enter the Ticket redirect URL format- In the Moveworks AI Assistant, each ticket includes a link back to the service portal in the Ticketing System.
    1. For ServiceNow, this can be left blank to leverage the default Service Portal URL.
    2. For Jira, it would be: https://your_tenant.atlassian.net/servicedesk/customer/portal/3/ -- be sure to replace 3 with the Service Desk ID.

For any other system, you can follow the instructions below to get a sample Redirect Link

  • Navigate to a ticket within your end user Service Portal.
  • Copy the URL shown in the browser.
  • Replace the ticket number with a placeholder such as {ticket_id}.
  1. Enter the Link to view all tickets - This is a link to the ticketing system page, where users can view all their open tickets. It is presented to users when they access the 'View All Tickets' option in the Assistant.

Once you have completed your configuration, select NEXT: Add Destinations

Select Ticket Types

Moveworks classifies tickets into different internal ticket types. These are used for different purposes under ticketing workflow

  • INCIDENT - This type of ticket refers to an unexpected issue or disruption that you're facing with a service or product, which needs to be fixed to restore normal operation.
  • REQUEST - This is a type of ticket you would create when you need a specific service or product from the support team. It could be anything from a new software installation to a request for information.
  • REQUEST_ITEM -This specific type of ticket refers to a request for a particular item, like a piece of hardware or software. It's typically used when you're asking for something tangible or downloadable.
  • CALL - This ticket is used to document a telephone call with the support team. In this scenario, you've probably reported an issue or made a request over the phone, and this ticket keeps track of that interaction.
  • TASK - This type of ticket represents a specific task that the support team needs to carry out to resolve an issue or fulfill a service request.
  • MISC - This type of ticket is used for situations that don't fit into other categories. If you've got a unique or uncommon issue, it's likely it would be categorized under this ticket type.
  • UNIVERSAL_REQUEST - This type of ticket is used when making a broad request that might involve multiple departments or aspects of the support team's service. It's a way to organize complex requests that can't be covered in a standard request ticket.
  • HR_CASE - Map your HR related ticketing destinations into this ticket type

Once a ticket type has been selected we will need to define the Destination Table under it in order for Moveworks to interact with it.

Ticket Type Eligibility for Concierge

This where we need to select the Type of tickets which should be polled and supported by the Concierge skill.

If a ticket type is selected in this field, that ticket type will be polled actively and users will be notified about the updates to the tickets and also nudge you when there have been no updates on the ticket.

Ticket Type Eligibility for Polling

This where we need to select the Type of tickets which should be polled by the Ticketing Engine.

If a ticket type is selected in this field, that ticket type will be polled actively and will then go through the ticketing life cycle via the Moveworks AI Assistant.

Note : The polling of tickets is also defined by the Ticket Filters which are defined under the Ticket Filters configuration page.

Configure Ticket Destinations

Once you have selected the Ticket Types and defined the Ticket destination tables, we need to provide additional details on individual ticket destination. Adding these configurations will enable Moveworks to read tickets from your system and perform Create/Update/Resolve/Reopen action on the tickets.

Map Ticket Structure

Mapping the ticket structure of your ITSM system to Moveworkes, allows Moveworks to understand what the ticket data contains and what will be represented back to the user.

For Example :

  • Understanding who the requestor is
  • Understanding what the state ticket is currently under

Map Prefix

Adding a Prefix to the ticket type adds a prefix to the ticket link when it is provided in the AI Assistant. This will help identify unique ticket types within bot.

For example

  1. Add IT as a prefix for the ticket destinations where IT tickets are getting stored.
  2. Add HR as a prefix for the ticket destinations where HR tickets are getting stored.

Map State Transition

Mapping state transition allows Moveworks to understand the ticket workflow which is currently running in your ITSM system. This can be simply done in two states :

  1. From States - Choose the states from your current system and link them with Moveworks' system. This will help Moveworks identify and understand your system's states
  2. To States - Choose the state in your current system that you want to match with a state in the new system. This match is important when you’re performing actions in your current (external) system.

Map Domain

Domain mapping allows segregation of ticket types under different domain. Map your IT related tickets under IT domain and HR related ticket under HR domain. This will help down stream to define impact when looking at Ticket data in Analytics.

Map Ticket Action Default payloads

In order to manage tickets effectively within your system, the following payloads must be configured for different ticketing actions. These payloads define the data necessary for each API call to function correctly.

  • Create Ticket Payload
    This payload is utilized when creating a new ticket. It is used in a POST method API call, requiring specific attributes to be included in the payload to successfully file a ticket. Common Required Attributes:
    • Title: The subject or short description of the ticket.
    • Description: Detailed information about the issue or request.
    • Requester: Information about the person creating the ticket.
    • Priority: The urgency of the ticket.
    • Category: Classification or type of the ticket.
  • Update Ticket Payload
    This payload applies when updating an existing ticket's details. It allows for modifications to be made based on new information or status changes. Common Required Attributes:
    • Ticket ID: Unique identifier for the ticket to be updated.
    • Updated Fields: Any fields within the ticket that need to be changed, such as status, priority, or additional comments.
  • Resolve Ticket Payload
    This payload resolves a ticket, indicating that the issue has been addressed and the ticket can be closed. Common Required Attributes:
    • Ticket ID: Unique identifier for the ticket to be resolved.
    • Resolution Notes: Details regarding how the issue was resolved.
    • Resolution Date: The date and time when the ticket was resolved.
  • Reopen Ticket Payload
    This payload is used to reopen a previously closed ticket, typically used when an issue resurfaces or wasn't fully resolved. Common Required Attributes:
    • Ticket ID: Unique identifier for the ticket to be reopened.
    • Reason: Justification for reopening the ticket.
    • Additional Comments: Any new information or context required to address the issue further.