Lab #5: Ticketing (Core)

---

Key Concepts

Moveworks manages the full lifecycle of a ticket, from creation to resolution. The core ticketing configuration involves:

• Table Mappings: The configuration that tells Moveworks which tables to interact with (e.g., incident for breaks/fixes or sc_req_item for requests).
• Routing Conditions: Logic that directs a user’s request to a specific workflow (e.g., routing a “Concierge” intent to a standard ticket generation flow).
• Table Actions: The specific capabilities enabled for the bot, such as the ability to “Query” (look up), “Update” (add comments), or “Resolve” a ticket.
• Service Portal URL: The base web address of your ITSM portal. Moveworks appends ticket IDs to this URL to provide users with direct “View in Portal” links.

Relevant Documentation:

• Moveworks Help: Concierge & Ticketing Capabilities Overview
• Moveworks Help: Configuring Ticketing for ServiceNow
• Moveworks Help: Ticket Data Object
• Moveworks Help: Handoff Overview

---

🛠️ 1: Walkthrough

1.1: Initial Setup

1. Navigate to Ticketing > Ticketing Configuration > New ticketing configuration

   

2. Start by selecting the Connector Selection

   

3. Select snow as the connector & primary system

   

4. Give your configuration a name

   

5. Click the Back button in bottom left hand side, and click the Setup Defaults button at the top of the page to establish the pre-configured ticketing types.

   

6. Navigate to the newly generated Table mappings page

   

7. By default, Moveworks will be integrated with the following tables within a ServiceNow instance. Select the Incident table by clicking the UI box:

   Note: Each ticket destination (table) will include a note at the bottom about what functionality is configured. For Incidents, we can see that the following functionality comes pre-configured:

   • Query: Allows requestors to search for their existing tickets
   • Create: Enables requestors to initiate new tickets
   • Update: Permits requestors to add comments to active tickets
   • Resolve: Grants requestors the ability to close their own tickets

   

8. After clicking into the Incident section, we will see the table definition.

   Field Name	Use
   Table Name	Table name within the Moveworks UI
   Table Label	Name of the table in the integrated ITSM
   Domain	The associated enterprise domain that the ticket falls under (IT, HR, Finance, etc)
   Ticket Type	The ticket type within Moveworks (Mirrors ServiceNow: Incident, Request, Request Item, Task, etc)
   Prefix ID	Matches to the prefix within the target system (INC, REQ, RITM, etc)
   Requestor Column Name	The associated ticket metadata field that represents the user who opened the ticket. often caller_id, requested_for, opened_by

   

9. Navigate to the Query page and review the States Configuration

   Note: The default State mappings within Moveworks will map to the defaults in the ServiceNow PDI environment. When integrating with a live environment, always ensure that you check the additional states in the source ITSM, and map any outstanding states into Moveworks.

   

10. Next, we will add custom_data fields to the Query mapping.

---

11. Based on our requirements, we will add the custom_data fields to the Query ticket mapping:

    Field Name	Value
    custom_data.u_vip_support	"$TRIM($TEXT((u_is_vip).value.$TRIM()))"
    custom_data.u_environment	"$TRIM($TEXT((u_environment).value.$TRIM()))"

    Note: In the Query configuration, all fields on the left are the Moveworks defined fields, while all fields on the right are the field name from the source system. Reference the Ticket Data Object page on the Moveworks Help Site to understand all of the fields available on the Moveworks Ticket object by default.

    

12. Scroll down to the Input fields in Mapper section and add the u_environment and u_is_vip fields

    

13. Add one of the custom_data fields as a default value that will be populated when Moveworks Creates an Incident ticket within ServiceNow

    1. Select Create and add the field u_environment with the value prod, as shown below:
       • "custom_data.u_environment": "\"prod\""
    Note: When configuring WRITE tables (Create, Update, Resolve, Reopen), the formatting tells Moveworks whether to use a fixed value or a variable you’ve already defined in your query configuration.

    1. Using Moveworks Variables

    To use data already stored in the Moveworks “data bank,” use a single pair of quotes. The “value” on the right must match the “key” you defined in your ingestion script.

    • Syntax: "target_field": "stored_variable"
    • Example: "assignment_group": "assignment_group"

      In this case, Moveworks looks at your ingestion code, finds the key "assignment_group", and pulls the result of that $TRIM(IF...) logic.

    2. Using Static Raw Strings

    To write a specific piece of text that isn’t a variable, you must escape the quotes.

    • Syntax: "target_field": "\"Fixed Value\""
    • Example: "short_description": "\"New Ticket from Moveworks\""

    

14. Next, navigate to the Resolve table, and update the close_code field that Moveworks will write to ServiceNow. Be sure to Save:

    • "close_code": "\"Resolved by caller\""

    

15. After saving, select Next, review the Routing & Workflow conditions (no updates needed at this time) and then Save

    

    

16. Navigate to the Table Actions and confirm that the Incident ticket type is enabled for Polling and Concierge Updates. Ensure you click Save before moving on

    

    

17. Ensure that the Access Control Strategy is set to Public to all members, and Save your configuration

    

18. Navigate to the Service Portal URL and create a configuration, leveraging your snow connector and your portal URL

    1. This configuration will control the redirect URL when a user clicks a hyperlink to a NOW ticket within Moveworks

    

    

19. You have completed the Ticketing configuration for Incidents, now file a Ticket with your Moveworks AI Assistant and test all of the functionality to ensure it is working!

---

✅ 2: Verification & Next Steps

1. Finalize: Confirm all configurations are saved
2. Check Success: Talk to Moveworks! Confirm you are able to do the following ticket actions:

   1. File

      

   2. Query

      

   3. Update (Add Comment)

      

   4. Resolve/Close

      

   5. Reopen

      

---

❗ 3: Troubleshooting Triage: Why am I unable to Action on a Ticket?

When a user attempts to do a ticketing action within Moveworks, the action may fail if there is a misconfiguration between how Moveworks is creating or updating the ticket, and what the source system expects. We should go through the following troubleshooting flow if we are experiencing issues with ticketing.

3.1: Encountering a Ticketing Error — “Failure Identification”

If the Assistant fails in a communication to the ticketing platform, it will state to the end-user that it failed to take the requested action.

The Assistant will often provide a short summary of what the occurring failure mode was. In the following case, we can see that Moveworks failed to create a ticket, and it looks like the issue may be related to a mandatory field not being included in the API request.

3.2: Check the API Logs — “What is Being Sent?”

Within Moveworks Setup, we can check the API Logs module to see what Moveworks tried to send to the endpoint system and how it failed.

1. Identify the log that indicates the error. You can search by the requesting user, trace id, method, or plugin

   

2. Analyze the error message. In this case we can see that our request payload is missing short_description, and the ServiceNow instance is stating that it is a required field

   

3.3: Constructing the Proper Payload in API Playground — “Solutioning”

Within API Playground, we can take the following information from step 2, and reconstruct our payload until we get a success in the system. This may be an iterative process, and we may need to ask our client for more information if we cannot properly resolve some values during this step.

1. Open another Moveworks Setup tab & navigate to API Playground

   

2. Copy the api_url_endpoint & request_payload

   

   

3. Plug them into API playground and try creating a new payload & test it to get feedback from the system

   

4. Iterate on it until you get a working result

   

3.4: Updating the Associated Ticket Mapping — “The Fix”

Now that we understand the problem and have a working solution, we can navigate to the segment of our ticketing configuration that was causing the issue, add our fix, save it, and validate the Assistant is now working as expected.

3.5: Check the Moveworks Status Page

Validate that there have been no broader issues reported by the Moveworks team on the Moveworks Status Page

3.6: Escalate to Moveworks Support

If we have validated the following, and are unable to diagnose the root cause, we can open a ticket with the Moveworks support team and include the following details related to the failure mode we are seeing:

1. The email of the user experiencing the issue
2. The action they are attempting to take
3. How the Moveworks Ticketing Plugin is failing

We always want to provide the Moveworks team with as much information as possible, to accelerate their ability to provide us support.

---

🪞 4: Reflecting on This Configuration

Through this guide, you’ve learned the following:

• How to complete the Ticketing Configuration
• How to add custom_data fields to the Ticket Query Mappings
• What ticketing actions Moveworks can take
• How to validate the actions are working as expected
• The thought process to follow when ticketing is not operating as expected

---

⚙️ 5: Configuration Details

Use the table below to fill in the required fields accurately.