Pre-Requisites

• Please ensure the required Fresh Desk Connector has been created with the necessary permissions to support ticket actions. Please refer the FreshDesk Access Requirements Doc for details.
• Please ensure the API Key being used for connecting to FreshDesk has access to the Ticket Tables users want to interact with.

Configuration

Start by navigating to Ticketing > Ticketing Setting > Ticket Mapping where you can create a new mapping for your ITSM system. Start by clicking on Create.

Step 1: Select Source

Name for the ticketing system - Please name your ticketing system configuration

Select Connector - Select the connector which was configured by following the steps in the Guide here.

Bot Service account Id - ID of service account for Moveworks bot in the Ticketing system which is being configured.

Ticket redirect URL format - This is the redirect URL Format for your ticket. Leave this empty in the case of ServiceNow as the Moveworks Default will be picked up.

https://<instance_name>.freshdesk.com/a/tickets/{ticket_id}

Link to view all tickets - This is a link to the Jira Service Portal, where users can view all their open tickets. It is presented to users when they access the ‘View All Tickets’ option in the Assistant.

Step 2: Classify Ticket Type

Define what Ticket Types you want Moveworks to support and the tables which are categorised into the predefined types which are provided by Moveworks.

In this scenario we are defining an Incident type ticket where we need to define the below fields.

• Fresh Desk Table Name - Define the name of the table on the Fresh Desk end which is the destination where tickets will be polled and interacted with.

  

Once we have classified the Ticket types, we need to select that in the below polling configurations in order for Moveworks to interact with the Tickets.

• Select ticket type eligible for concierge - Select the Type of ticket which should be polled for updates and status checks which fall under the Concierge skill.
• Select ticket type eligible for polling - Select the type of ticket which should be considered for polling in order to support the Ticket operations for it.

Step 3: Configure Ticket Type

Now that we have defined what types of tickets Moveworks should support, We can now configure the Payloads for the Ticket Actions which can be performed by the AI Assistant. We will also define the below configurations to support Ticketing in Moveworks.

Step 4: Configure the Map Ticket Structure

In order for Moveworks to poll/query your tickets from the external ITSM system we need to map the structure of the ITSM Ticket payload to the internal Moveworks Attribute Structure which is defined under Ticket Attribute Mapping. Mapping ticket structure allows Moveworks to understand what the ticket data contains.

For example :

• Understanding who the requestor of the ticket is.
• Understanding what the state ticket is currently under.
• Understanding what is the Ticket number.

The below fields need to be defined in order for the Ticketing Mapping to be created.

Query Ticket Field Map

• Use Same as Ticket Destination - This option is selected when there is already a pre-existing ticket type mapper which can be reused.
• Ticket JSON Mapper and input fields - Map the ticket structure or payload. Leverage the ‘use-same-as’ option to duplicate data from a different destination. For more information refer to the Moveworks Data Mapping.
  • Ticket JSON Mapper - The attributes in red are the Moveworks attributes which are mapped to the External ITSM attributes marked in blue.

Step 5: Configure the Ticket State Mapping

This configuration is used for Mapping state transition, which allows Moveworks to understand the ticket workflow in your system. This can be simply done in two states.

• From External 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 External 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.

Step 6: Configure the Domain

The Domain the ticket type falls under, for instace break/fix issues are part of IT_DOMAIN. While user requests are part of HR_DOMAIN

Step 7: Configure the Prefix

Prefix adds a prefix to a ticket type. This will help identify unique ticket types within AI Assistant and define how the ticket numbers are represented in the Notifications.

Step 8: Configure the Table Name

The External Table on the ITSM end where the tickets are polled and created by the AI Assistant

Step 9: Configure the Ticket Action Payloads

Each of these payloads are defined to support a specific ticket action.

Create Ticket Payload

These are the ticket attributes which need to be defined in the JSON payload in order to submit the API call which will create the ticket. The Attributes which the ITSM system is expecting is on the left.

While the Moveworks variables which will slot and populate the data are defined on the right. Some of these values can be static as well and can be explicitly defined as strings.

{
  "description": "description",
  "requester_id": "$INTEGER(requested_for or null)",
  "subject": "$TRUNCATE(short_description, 50, TRUE)",
  "group_id": "$INTEGER(assignment_group OR \"15000000736\" or null)",
  "tags": [
    "\"navi\""
  ],
  "type": "\"HRIS\"",
  "status": "2",
  "priority": "1"
}

Update Ticket Payload

This mapper defines which attributes need to be submitted in order to update a ticket on Jira via API calls. Here we will be updating the comments and labels which are provided by the user.

{
  "description": "description",
  "subject": "short_description",
  "type": "type",
  "group_id": "$INTEGER(assignment_group or null)",
  "comments": "$TRIM((comments) OR NULL)",
  "work_notes": "$TRIM((work_notes) OR NULL)",
  "parent": "$TRIM((parent) OR NULL)",
  "responder_id": "assigned_to_user"
}

Resolve Ticket Payload

This is the ticket payload which needs to be submitted in order for the user to resolve the ticket, The fields to resolve a ticket can differ for customer workflows, so please ensure you are using the right attributes.

If there is no payload you need to pass in order to Resolve the ticket then you can skip defining the Resolve Ticket Output Field Map Base Mapper and go directly to Resolve Ticket Update If Empty Field Map Base Mapper which is to be used when the payload map is being sent empty.

In these cases we set specific attribute fields that will need to be set to Resolve the ticket.

{
  "custom_fields": {
    "cf_hris_issue": "\"Other\"",
    "cf_hris_detail": "\"Other tool(s)\""
  },
  "responder_id": "xxxxxxxxxxx"
}

Reopen Ticket Payload

This ticket payload is leveraged to reopen a Resolved ticket on the ITSM, Reopen flows are specific and require the user to provide comments when reopening, or some flows do not support reopening tickets once closed. In the case of Fresh Desk this can be left emtpy.

If you would like to support Reopening action please define the attributes in the payload in the same format as Resolve Ticket Payload.

Submit the config to Complete the Ticket Mapping for Moveworks.

Step 10: Configure the Ticket Routing

After your Ticket mapping has been completed we need to write the default routing rules in the Assistant context in order to allow the ticket actions to take place. Ticket routes are separated into action specific which can house both default and Conditional routes.

• In this scenario, you can see that we have created a specific Workflow called fresh_desk_generate_ticket_workflow which is conditionally executed.
• The condition in this scenario is searching for the below data points :
  • Checking if the Domain is HR
  • Checking if the Custom Attribute is_employee is equal to Y
    • OR If the user email_addr is based on a subset of emails.

Step 11: Configure the Ticket Workflows

This is where the workflows referenced in Ticket Routing are configured. Please ensure the Workflow names match what has been defined in the routing configuration.

• You need to start by defining the Workflow name and the Connector of the ITSM system where the ticket action will be carried out.
• Next we need to define the Default Action of the Workflow where we can select the Action type.
• Depending on the workflow you are trying to create, select the appropriate Action which in this case is the Generate Ticket Action
• It allows you to select the Ticket Destination and Payloads we defined earlier in ticket mapping which will be used to perform the action.

Step 12: Ticketing Integration Permissions

In order to allow Moveworks to query the tickets from your external ITSM system, we need to enable the permissions on the Moveworks end. You can set this up by Navigating to Resource Permissions > Permission rules where you can create a new configuration for permissioning access to this ticket plugin.

Here is a Guide to learn more about Resource Permissions and how they work.

There are 2 types of Permissioning Strategies which are supported ABAC and REBAC. In the case of Ticketing since this is going to be an Integration level Permission rule, we can only use ABAC as the Permissioning strategy.

• The resource selected here is going to be Integration as this is what allows Moveworks to poll tickets and then present them back to the user in the Assistant.
• Set any Resource Permission DSL value to TRUE to FALSE to globally enable or disable it.

You have completed the configuration ✅

Validation

We can now try performing the ticket action like create or query depending on the Workflow which was created. Try to validate each ticketing action independently to ensure it is working as expected