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

The below Sections walk you through the Configuration flow for ticketing and the various aspects of it. Using the knowledge of the below sections you can Implement ticketing for the below ITSM systems.

Here are step by step guides around :

• Configure Ticketing for ServiceNow
• Configure Ticketing for Jira Service Desk
• Configure Ticketing for Fresh Desk

Connect Your Ticketing System in Three Simple Steps

1. Select a Connector: Choose the appropriate connector for your ticketing system.
2. Select Ticket Types and Databases: Identify ticket types and select relevant databases from your existing system.
3. Configure Database Structure and Default Ticket Payload: For actions such as creating, updating, resolving, and reopening tickets.

Setup Ingestion

Setting up ingestion integrates your ticketing system so that Moveworks can manage and interact with it effectively. This can be achieved in three straightforward steps.

1. Access the Setup Module

• Log into the Moveworks Setup Module.
• Navigate to Ticketing > Ticket Settings > Ticket Mapping and click on Create.

2. Select Connector & Add System Information

Connectors are essential for linking Moveworks with your ticketing system. You can select an existing connector or create a new one if needed.

Config Name

Assign a clear and concise config name for the integration to ensure easy recognition by all users.

Example: Use names like "ServiceNow Integration" or "Freshservice Connector".

Service Account ID

Enter the service account ID for the Moveworks bot used in the external ticketing system. This ID should map to:

• external_id
• itsm_user_id
• user_itsm_info

These can be found in the Moveworks control panel after user ingestion is completed. Check the control center page for relevant service account details.

Ticket Redirect Link

Each ticket includes a link back to the service portal where it is managed. Provide a template URL for navigation back to the ticketing system. This might not be necessary for all systems.

Example: Getting a Sample Redirect Link

• Go to a ticket within your portal.
• Copy the URL shown in the browser.
• Replace the ticket number with a placeholder such as {ticket_id}.
• Enter the formatted URL into the system, such as: <https://yourserviceportal.com/tickets/{{ticket_id}}>

This process is applicable to all of the system excluding service now and jira. Visit your ticketing portal and take the browser url and replace the ticket-id with {ticket_id}

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.

Example :

• Go to a ticketing portal home page where you can view all your tickets
• Copy the URL shown in the browser

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.

Setup ticket filters

Ticket filters allows filtering of tickets that are ingested into the Moveworks system. There are different use-case where you don’t want the ticket to be present in Moveworks ecosystem. By using DSL rule you are able to filter these types of tickets

Generally you don’t need to define these filters and should be used only in exceptional cases.

For example

1. Do not ingest devops maintenance tickets.
2. Do not allow concierge actions on tickets generated through “phone” or “physical walk-in with service desk” team.

Standard ticket filters

These are generic filters that are applicable to the whole platform. These filters are written in the DSL language. Please refer to the DSL documentation to understand how to enable this. These filters can be written to include tickets or exclude tickets. Default behaviour is to include all of the tickets coming from the external system.

Universal ticket filter

This filters defines what gets ingested into Moveworks. Tickets excluded by this filter are not eligible for analytics or any action available within the Moveworks bots

Filter for ticket resolution

Filter tickets that are eligible to be counted under as resolved. Tickets excluded through this filter can still be present in the Moveworks system but won’t be counted under resolution

Filter for tickets eligible for resolution action

Filter tickets that are eligible for resolution action through the bot. When a user requests to close the ticket the bot is able to move it’s state and mark the ticket as resolved. Apply a filter on the tickets which can’t be marked as resolved through the bot.

Skill-specific ticket filters

These are skill specific filters which only work in a combination of skill and filter defined.

Define the ticket filters here for

1. Ask me skill - Tickets eligible for ask me
2. Concierge skill - Tickets eligible for concierge actions
3. Nudge skill - Ticket eligible for nudges
4. Triage skill - Ticket eligible for triage actions

This is the basic setup for ticket ingestion, Once done with these settings your basic ticketing setup is completed. Complete the workflow setup also to enable the ticketing skill through the bot.