Connect your ticketing system with moveworks in 3 simple steps

Select connector for your ticketing system.
Select ticket types and select ticketing databases from your end system
Configure your ticket database table structure and configure default ticket payload for
1. Create ticket action
2. Update ticket action
3. Resolve ticket action
4. Reopen ticket action

Setup Ingestion

Setting up ingestion allows you to configure ticketing system into Moveworks. This can be achieved in following 3 simple steps.

Navigate to the Moveworks Setup module and click on the ingestion module.

Here you will be able to find previous ticketing system setup or will be able to integrate a new ticketing system.

Select Connector & Add System information

Connectors are the key component which connects Moveworks to the ticketing system. Select your existing connector to a system or create a new one if you don’t see it in the list.

Config name

Provide a config name for the integration. Advisable to provide a clear and simple config name as it can be recognized by other users

For e.g. : Service now, Fresh Service

Service account ID

Enter the service account id for the moveworks bot that is created in the external system. This should map to either

External_id
Itsm_user_id
User_itsm_info

From the moveworks user proto. This can be found in control center once the User ingestion is completed. Visit the control center page and find the related service account user details.

Ticket redirect link

Every ticket is linked to the service portal where it is stored. Provide a sample url template which can be used for redirecting user to the ticketing system. This is not required if your ticketing system is either

Example : Getting a sample redirect link from your Freshservice portal

⇒ Navigate to a ticket in the Freshservice portal

⇒ Pickup the URL that is in the browser

⇒ Format the ticket number to be in this format {ticket_id}

⇒ paste the URL taken from the browser in this input field : **https://moveworkshelpdesk.freshservice.com/a/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}

Select ticket types and configure ticket destinations

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

DEFAULT - This is the default ticket type in Moveworks. If you are unsure on where your external ticket is classified as map your ticket destination into this ticket type
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

Select Destinations

What is a destination ?

Destinations are end system table databases where your tickets are stored

for e.g.

In case of service now, Destination tables are
1. incident
2. sc-request
In case of freshservice Destination tables are a combination of Issue-type Id/Request-type Id & Project-key
1. Issue-type Id : 10172 & Project Key : IT
2. Request-type Id: 119 & Project Key: n/a

How to enter destination details

Destination entry is based on ticket system that has been selected the form will change as per the system

Service now
- Enter the service now table names where the tickets are getting stored in your instance.
JIRA
- Enter the issue type-id/request-type id for the tickets
- Enter the project key where the tickets are getting created
Freshservice
- Enter the table name for the tickets are getting stored
- Enter group id for a specific group within the table
- Enter the category to which the tickets belong to
Freshdesk
- Enter the table name where the tickets are getting stored
Ivanti
- Enter the business object corresponding to the ticket type
- Enter the table name where the business object are getting stored

💡 Visit your ticketing system and contact your ticketing system admins to know more about these details.

Select ticket types eligible for concierge

Select the ticket types that are enabled for check status and nudges with the bot

Select ticket types eligible for polling

Select ticket types that we should poll for in bot resolution by skills such as concierge, access software, forms, triage, etc.

Select ticket types that can be resolved

Select the type of ticket the bot can resolve

Configure ticket destinations

Once you have configured the ticket destinations 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 ticket structure allows Moveworks to understand what the ticket data contains.

For example

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

Map Prefix

Prefix adds a prefix to a ticket. This will help identify unique ticket types within bot.

For example

Add IT as a prefix for the ticket destinations where IT tickets are getting stored.
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 in your system. This can be simply done in two states

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
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.

Refer this documentation on adding this mapping : [JSON bender placeholder]

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.

Map ticket action default payloads

These ticket actions are the key interactions of the bot with your ticketing system. Map your default payload for these actions

Create ticket payload

This is payload that will be used to create a ticket

Update ticket payload

This is payload that will be used to update a ticket

Reopen ticket payload

This is payload that will be used to reopen a ticket

Resolve ticket payload

This is payload that will be used to resolve a ticket

Setup ticket filters

Ticket filters allows filtering of tickets that are ingested into the Doveworks 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

Do not ingest devops maintenance tickets.
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

Ask me skill - Tickets eligible for ask me
Concierge skill - Tickets eligible for concierge actions
Nudge skill - Ticket eligible for nudges
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.