[New] Configure Ticketing for FreshService

This guide walks you through configuring Freshservice as a ticketing system in Moveworks using the new Ticketing Configuration Wizard. Once configured, employees can create, view, and manage Freshservice tickets directly through the Moveworks AI Assistant.

Pre-Requisites

Please ensure the following are completed before starting:

• Please ensure the required Freshservice connector has been created with the necessary permissions to support ticket actions. Please refer to the Freshservice Access Requirement Document for details
• Please ensure the Service Account configuration in Moveworks Setup exists. This service account is used by Moveworks to connect to Freshservice.
• Please ensure the API key being used for connecting to Freshdesk has access to the ticket data that users will interact with.
• Please set up the identity configuration for Freshservice so users are ingested with their external system ID. This is required for filing tickets on behalf of users.
• Please set up the Service Portal configuration for Freshservice. This is the end-user portal link where users can view and track their tickets. Refer to this section for dedicated guide to set this up. Please ensure you configure this before testing ticketing actions in Moveworks AI Assistant.
• Please ensure you have completed the chat configurations for the AI Assistant to test ticketing flows end-to-end. This is necessary to have a conversation with your AI Assistant and test the ticketing actions.

Ensure you complete the actions above to seamlessly test Freshservice ticketing integration in the Moveworks AI Assistant. These are necessary for the Moveworks Ticketing skill to work

Navigate to the new ticketing wizard

Navigate to Ticketing Automation > Ticketing Configuration, where you can create and manage ticketing configurations for Freshservice.

• If you are configuring ticketing for the first time or adding a new ticketing system, click Create.

• If you want to update settings or add new destinations for an existing configuration, click Edit next to the Freshservice configuration.

  

  

Configuration Structure

Ticketing configuration is organized into three sections and should be completed in order:

1. Setup destinations and workflows

Connect to your Freshdesk instance and enable default ticket destinations and workflows. Review the destinations created by default and configure any additional destinations you want to support. You can also customize workflows and routing to control how tickets are created, updated, resolved, and reopened.

2. Define ticket forms, actions and access

Configure the ticket intake experience for end users. By default, Moveworks provides a standard intake form. You can create custom intake forms if additional information is required.

Enable destinations for concierge updates and ticket polling, and configure which users can access the Freshdesk ticketing integration.

3. Platform settings

Manage platform-level ticketing configurations, including ticket polling behavior, notifications, nudges, and display settings.

1. Setup connector and defaults

• Select the Freshservice connector that Moveworks will use to integrate with your Freshservice instance. Refer to the Freshservice connector documentation to complete the connector setup.

• The connector enables Moveworks to:

  • Create tickets
  • Retrieve ticket status and updates
  • Access ticket fields and metadata
  • Perform ticket actions on behalf of users

• Please select “Mark this system as primary” if this is your first ticketing system.

• Provide a configuration name to help identify this setup later.

  

Common mistakes

1. Not marking the system as primary

   If your organization does not already have a ticketing system configured, you must mark this system as primary. If the system is not marked as primary, the new ticketing configuration wizard will show an error. The primary system is required so Moveworks knows which ticketing system to use by default.

2. Not configuring a Service Account

   A Service Account configuration must exist for the connector you select. If a Service Account is not configured, the wizard will show an error and you will not be able to proceed. Refer to the prerequisites section to complete the Service Account setup before continuing.

3. Selecting a connector that was previously used

   The new ticketing journey does not support using a connector that is already associated with an existing ticketing configuration, including legacy configurations. If you attempt to use a previously configured connector, the wizard will show an error. To continue, create and use a new connector for this ticketing setup.

1.1 Enabling defaults

Once you have completed the connector setup, you can enable the default Freshservice configurations. After saving the connector, you will be redirected to the configuration home page. At the top of the page, you will see a Setup defaults section.

Click Setup defaults. This opens a modal where you can review the configurations that will be created automatically.

Moveworks creates default Freshservice destination tables along with the default ticketing workflows required to support common ticketing actions.

If this is your first Freshservice ticketing configuration, Moveworks will also set the default workflows under routing conditions. Review these workflows to ensure they align with your Freshservice setup.

If this is a secondary ticketing system, routing, payload configurations, and intake form settings may already be present. These configurations are shared across ticketing systems, and updates here apply across all ticketing configurations.

2. Review default created destinations

Navigate to the Table mappings section. Here, you will see the default Freshservice destinations that Moveworks has created.

Each destination represents a Freshservice table from which tickets are read, created, and managed.

Moveworks automatically populates the destination details and configures the required state mappings and field mappings for each supported ticketing action, including query, create, update, resolve, and reopen. Review these configurations to ensure they are set up correctly for your Freshservice environment.

Refer to the sections below to learn how to add a new destination and to understand what each field represents.

3. Review ticket workflows and routing

Click Next to navigate to the Routing and Workflows section.

In this section, you can review the routing configuration for the supported ticketing actions, including query, generate, update, resolve, and reopen. For each action, you will see the workflow that is currently selected, along with any conditional workflows that have been configured.

If this is your primary ticketing setup, Moveworks automatically assigns default workflows for each action. If this is a secondary ticketing setup, existing default workflows are not overridden.

You can add additional routing conditions or associate different workflows as needed.

Navigate to the Workflows section to review the workflows created by default. Moveworks generates a default workflow for each ticketing action, and each workflow may contain one or more steps.

3.1 Updating the default generate workflow

Setup destination for ticket creation

In order to continue testing the default actions within MoveWorks ticketing skills, you will need to put in some few updates on the default generated workflows.

First of all, navigate to the workflows section and select the GENERIC_MW_DEFAULT_FALLBACK_GENERATE_TICKET_WORKFLOW . In this you will find a generate ticket action Select the destination ID that you want the ticket to be filed in.

By default Moveworks supports out-of-the-box incident filing. Please select the destination as incident so you’ll be able to test the incident creation in the next step

4. Test the defaults that are created for your organization

Test the default configurations to ensure ticketing is working as expected.

Test file ticket

Ask the Moveworks AI Assistant to file a ticket by entering a sample request, such as “My VPN is not connecting” and then click File Ticket. Verify that a ticket is created in Freshservice with the expected details.

5. How to add a new destination

Let’s go through the process to add a new table in the ticketing configuration. After a successful test of defaults, you can expand the ticketing use-cases according to requirements. In order to add a new table, click on the “Create New” button on the top right. This will open up the table creation flow for adding a new table.

Field details

Table Name : Table name in Freshservice where you want to read and create tickets from. For example: Incident.

Group ID : Specify the Freshservice group ID if tickets should be assigned to a particular group.

Category : Define the category to be associated with tickets created through this table.

Workspace Identifier : If your Freshservice instance uses workspaces, provide the workspace identifier corresponding to this table.

Table label : This is a Moveworks-specific construct where you re-enter the table name in order to tie it with the Create/Update/Resolve/Reopen configurations. Re-enter the same table name here.

Domain : This refers to the business domain to which this destination belongs. Select the domain from the dropdown.

Ticket type : Select the ticket type represented by this table (for example: Incident or Request).

Prefix-ID : Configure a prefix for tickets created or fetched from this table. For example, INC.

Is default : Enable this if this table should be the default destination for ticket creation.

Once the table is created, you will see a new entry for it in the Table mappings page. Let’s now populate details for this table such as state mapping and payload configuration for Query / Create / Update / Resolve / Reopen.

State mapping

Each ticket in your Freshservice instance goes through a lifecycle starting from states such as “Open” to “Resolved” or “Closed”. State mapping allows Moveworks to understand the Freshservice ticket workflow and correctly interpret ticket states.

For each state mapping, configure the following fields:

Name : These are Moveworks internal states. Select one from the dropdown (for example: NEW, WIP, RESOLVED).

From External State values : Enter the Freshservice status values that correspond to the selected Moveworks state. For example, Freshservice status codes such as 2 (Open) or 4 (Resolved), depending on your Freshservice configuration.

To External State Value : Enter the Freshservice status value that Moveworks should send when updating the ticket state. This ensures that when a ticket is resolved or reopened through Moveworks, the correct Freshservice status is applied.

This configuration ensures Moveworks can both understand the current state of the ticket and update it correctly in Freshservice.

Ticket Attribute Mapping

Moveworks needs to understand the structure of a ticket from your Freshservice table. You must map the Freshservice ticket fields to the Moveworks internal ticket object. Refer to the Moveworks ticket data object documentation to understand supported attributes.

There are two ways to add this mapping:

Use same as : This will reuse the details from a previously configured table.

Define manually : In this, you must enter a JSON mapping of fields from the Freshservice ticket to the Moveworks ticket object.

1
{
2
  "created_at": "$TIMECONV(created_at)",
3
  "contact_type": "$TEXT(source)",
4
  "assignment_group": "$TEXT(group_id)",
5
  "identifier.ticket_id": "$TEXT(id)",
6
  "display_ticket_id": "$TEXT(id)",
7
  "timestamp_fields.closed_at": "$TIMECONV(stats.closed_at)",
8
  "updated_at": "$TIMECONV(updated_at)",
9
  "text": "body_text",
10
  "timestamp_fields.resolved_at": "$TIMECONV(stats.resolved_at)",
11
  "resolved_at": "$TIMECONV(stats.resolved_at)",
12
  "core_fields.state": "$TEXT(status)",
13
  "core_fields.full_description": "description_text",
14
  "short_description": "subject",
15
  "timestamp_fields.updated_at": "$TIMECONV(updated_at)",
16
  "core_fields.short_description": "subject",
17
  "closed_at": "$TIMECONV(stats.closed_at)",
18
  "description": "description_text",
19
  "core_fields.assignment_group_id": "$TEXT(group_id)",
20
  "core_fields.ticket_type": "type",
21
  "id": "$TEXT(id)",
22
  "requested_for": {
23
    "CONDITIONAL()": {
24
      "condition": "$TEXT(requester_id)",
25
      "on_pass": {
26
        "user_id_info.user_itsm_id_info": [
27
          {
28
            "external_id": "$TEXT(requester_id)"
29
          }
30
        ],
31
        "external_system_identities.unknown_system": {
32
          "external_id": "$TEXT(requester_id)"
33
        }
34
      }
35
    }
36
  },
37
  "user_fields.requested_for_user_id": "$TEXT(requester_id)",
38
  "assigned_to_user": {
39
    "CONDITIONAL()": {
40
      "condition": "$TEXT(responder_id)",
41
      "on_pass": {
42
        "user_id_info.user_itsm_id_info": [
43
          {
44
            "external_id": "$TEXT(responder_id)"
45
          }
46
        ],
47
        "external_system_identities.unknown_system": {
48
          "external_id": "$TEXT(responder_id)"
49
        }
50
      }
51
    }
52
  },
53
  "user_fields.created_by_user_id": "$TEXT(requester_id)",
54
  "external_id": "$TEXT(id)",
55
  "timestamp_fields.created_at": "$TIMECONV(created_at)",
56
  "created_by": {
57
    "CONDITIONAL()": {
58
      "condition": "$TEXT(requester_id)",
59
      "on_pass": {
60
        "user_id_info.user_itsm_id_info": [
61
          {
62
            "external_id": "$TEXT(requester_id)"
63
          }
64
        ],
65
        "external_system_identities.unknown_system": {
66
          "external_id": "$TEXT(requester_id)"
67
        }
68
      }
69
    }
70
  },
71
  "state": "$TEXT(status)",
72
  "user_id": "$TEXT(user_id)"
73
}

Create Ticket Payload:

Moveworks creates a ticket in your Freshservice system and sends fields to the create ticket API. These fields must be configured here so Moveworks can populate them. You can configure this in two methods:

Use same as : Reuse the create payload from another table.

Define manually : Provide a JSON mapping of Freshservice fields expected by the create ticket API.

1
{
2
  "description": "description",
3
  "subject": "short_description",
4
  "requester_id": "$INTEGER(itsm_user_name or null)",
5
  "source": "1002",
6
  "category": "\"Application/Software\"",
7
  "status": "2",
8
  "priority": "1"
9
}

Update Ticket Payload:

Moveworks updates tickets in Freshservice when users perform actions such as adding comments or updating ticket details. Configure this payload using Use same as or Define manually

Resolve Ticket Payload:

Moveworks can resolve tickets based on end-user requests. Freshservice may require specific fields to mark a ticket as resolved. Configure this payload using Use same as or Define manually

1
{
2
  "custom_fields": {
3
    "resolution_notes": "\"The requester has requested that this ticket be resolved\"",
4
    "close_code": "\"Customer Resolved\""
5
  }
6
}

Reopen Ticket Payload:

Moveworks can reopen tickets based on end-user requests. If Freshservice requires specific fields for reopening, define them here using Use same as or Define manually

6. How to add a new destination

The first step to set up ticketing actions is to ensure that the table has already been created and configured. The previous section guides you through creating the table and defining the required payloads.

Let’s now go through how to enable the Generate ticket action for a newly configured table.

Navigate to the Routing & Workflows section in the ticketing configuration journey. This section defines how ticketing actions are triggered when users interact with the Moveworks AI Assistant.

In the Routing Conditions tab, locate the Generate ticket action settings. Here you will see the Default Workflow that is executed when no conditional routes match.

First, review the Default Workflow configured for the Generate ticket action. This workflow is used when no routing conditions apply. Navigate to the Workflows tab and open the workflow referenced in the Generate ticket action settings.

Inside the workflow, go to the Default Actions section and locate the Generate Ticket action. Select the Freshservice table you created earlier as the destination. This ensures that tickets are created in the correct Freshservice table when users file a ticket.

If you want to enable ticket creation for the new table only under specific conditions, you can add a Conditional Route.

In the Routing Conditions tab under Generate ticket action settings, click Add in the Conditional Routes section. Define the routing condition using DSL based on your use case, such as domain, skill name, or ticket type. Then select the workflow that references the newly created Freshservice table.

When the defined condition evaluates to true, Moveworks executes the associated workflow and creates the ticket in the selected Freshservice table. If no conditions match, the Default Workflow is executed.

Once this is done the new ticket table is configured for ticketing use-case through the Moveworks AI Assistant. Now you have mulitple options to change this behaviour

You can potentially add a condition in the routing configuration and create a entirely new workflow to file a ticket You can also create a new entry in the Handoff configuration to initiate a file ticket for your use-case. We will cover how to create a new RTF form in the next section.

Go through this doc in detail to understand what is routing & workflows : /docs/workflows-and-workflows-triggering

7. How to create a new Intake form and enable ticketing filing through it ?

What a Intake form - Intake form provides you ability to take structured input from the users while filing a ticket in Freshservice. This is also know as RTF in Moveworks

Go through guide to understand how intake forms work in Moveworks : /docs/best-practices-rich-ticket-filing

Let’s go through the steps of creating a RTF form and enabling ticketing filing through it

Moveworks helps employees solve many routine issues instantly. But often, uncategorised issues require manual support and lack a dedicated form. In such cases, employees file generic tickets via Moveworks for help (synonymous with filing tickets in the backstop/via the bot).

Without a Rich Ticket Filing form, every ticket filed via the AI Assistant only includes:

• Short Description
• More Details
• Attachments

By using Rich Ticket Filing (RTF), you can configure a form-based ticket filing experience that collects structured information from users at the time of filing. This makes ticket routing and triage far more efficient.

1. Setup Ticket Destination Mapping

Before we start setting up the RTF, we need to setup the ITSM connection for the Destination where the RTF will create the ticket.

• Navigate to Ticketing > Ticket Settings > Ticket Mapping Configuration under the Ticketing Automation Module.

  • Edit the configuration and go to the Configure Ticket Type step where you can add the new Destination table. Follow this guide to setup Ticketing for a new Table.

• In the Create Ticket Payload, you will need to define the attributes which are required to make a successful API call to create the Ticket.

• The Attributes in Red are what the ITSM expects to see in the Payload, while the Attributes in Blue are Moveworks based and can also be hardcoded.

  If you are always going to use an RTF for a specific Ticket Destination, Then it is recommended to define fallback values if a field is empty.

  1
  {
  2
  "urgency": "urgency_rtf OR \"Low\"",
  3
  "short_description": "short_description",
  4
  "description": "description"
  5
  }

2. Create a Rich Ticket Filing Form

• Navigate to ”Create intake form” section in the new ticketing journey configuration

  

• Click on Create to setup a new form.

• You will start by selecting the domain, and provide a unique ID for the form. (This ID will be used in multiple other configurations). Ensure that each form has a unique ID. Duplicate IDs will cause conflicts.

• Add the following details:

  • Form Title – e.g., “Submit a Ticket” or “Ask HR a Question”

  • Description & Short Description – user-facing help text on how to fill the Form.

  • Fields – information you need from the user.

    Required fields

    Rich Ticket Filing forms must have at least one field with Field Name description or short_description. If neither of these fields are included in a Rich Ticket Filing form, ticket creation will fail.

    If only 1 needs to be available, use short_description, as that is required for user’s chat context to be passed into the ticket creation form.

1. Add Fields to the Form

Rich Ticket Filing supports the following field types:

• Single-line text
• Multi-line text
• Single-options dropdown (max 100 options unless the field type is USER)
• Checkboxes
• Datetime fields (MS Teams only)
• Attachments (MS Teams only)

For each field, configure:

• Field Label – user-facing name.

• Field Name – internal identifier. This must be noted for mapping to ITSM fields later.

  • Unmapped fields will be sent to the ticket description by default.

• Field Type

• Description– optional tooltip help text.

• Required/Read Only

• Auto-population (if any)

• Dropdown Options (for option fields):

  • Label – shown to the user.
  • Value – backend value accepted by Freshservice.
    When configuring the OPTIONS field type, it is mandatory that each Label-Value pair is unique. Duplication within these pairs may lead to logic inconsistencies during system processing.

  
  

Example: For an Travel & Expense dropdown, add values for Travel and Expense. The selected value will determine which workflow runs based on the condition satisfied.

4. Linking RTF to Handoff Configuration

Now that the RTF has been configured, we need to create the display settings associated with it in order to Render it in the Assistant Chat Platform UI.

• Navigate to Handoff > Handoff Settings under Ticketing Automation.

• Create a new Category, or setup a new Item in an existing Category so we can link it to the RTF.

• Deflection Action → UI Form Id

• UI Form Id → unique ID of RTF we set earlier.

  

Always ensure the Pre-Trigger being provided here is based on the Domain the RTF was defined under.

5. Setting up Display Configuration

Once the Handoff is created, We need to provide some metadata to it, in order to define the details like name and description to the Item which was created for the Handoff.

You can follow this Guide on How To Configure the Display Fields for Handoff Items

6. Configure Ticket Action Workflows

In order to define which payload is used to Generate the ticket for an RTF, we can use Ticket Workflows condition actions.

• The Ticket Workflows have the ability to leverage the option a user has selected in an RTF by referencing the field name as part of a DSL Rule.

• When you create a new Workflow, the Default Action will define the Generate Ticket Action with the default payload which has been set for a Destination.

  

• Then comes the Conditional Action section, which allows you to define a DSL rule, based on which you can define Generate Ticket Action with multiple different Payloads. Here we can leverage the RTF Field value which has been configured earlier.

• In the below example, ticket_type_rtf is the RTF field which can be used for evaluating the condition.

  

• When writing the DSL Rule, we need to ensure both ticket_data & ticket.ticket_vars are included for the Condition to be Evaluated accurately

• You can add more conditions here using different RTF fields in the DSL Rule in order to use the required payload.

  1
  (context.system_context.domain == "HR_DOMAIN" AND
  2
  ((context.concierge_context.ticket_data.rtf_hr_service.$LENGTH() > 0) OR
  3
  (context.system_context.ticket.ticket_vars.rtf_hr_service.$LENGTH() > 0)))
  Workflow Conditions is the only place where the RTF field context is available. These rule conventions should only be used here.

You should now be able to test this by clicking on the Get Help option, and then selecting the Handoff Category which the RTF belongs to.

Common questions

Q: For a User Type field, what if multiple users have the same name?

A: Moveworks will show Name: <Email> for USER type fields dropdown in the form, so even if they have multiple names, you can disambiguate using name + email pair.

8. How to enable ticket polling and concierge updates

Moveworks automatically polls Freshservice to provide concierge updates such as ticket notifications, status changes, and automated nudges. Polling also enables ticket-related actions such as viewing, updating, and resolving tickets through the AI Assistant.

To enable these features, you must specify which Freshservice destinations are eligible.

Navigate to the Table Actions section and select the Freshservice destinations that should be eligible for polling and concierge updates.

Access control

You must define which users can access the Freshservice ticketing integration in Moveworks. Two access control options are available:

• Public: Accessible to all members.
• ABAC (Attribute-Based Access Control): Define a custom DSL rule to control access based on user attributes.

Choose the option that best fits your organization’s access requirements.

9. Enabling platform level settings for ticketing

Manage ticket polling, notifications and filters. Control ticket display

Ticketing Polling Configuration

• Configure how frequently Moveworks polls Freshservice for ticket updates.

• Define:

  • Poll interval (in seconds)
  • Maximum look-back window

• Apply universal ticket filters using DSL to limit which tickets are considered.

  

Notifications

• Control how and when users receive ticket notifications.
• Configure notification filters using DSL.
• Restrict notifications to business hours if required.
• Optionally:

  • Respect user time zones

  • Enable weekend notifications

  • Notify watchers on ticket updates

    

Nudges

• Configure automated reminders for inactive tickets.

• Define:

  • Inactivity threshold
  • Nudge interval
  • Maximum nudges per ticket

• Enable or disable polling-based and channel-based nudges as needed.

  

Display Settings

• Control how ticket information is displayed in Moveworks.
• Configure options such as:
  • Displaying ticket state
  • Showing assignee information
  • Allowing attachment uploads
  • Requiring comments before reopening tickets
  • Hiding the reopen option for closed tickets