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 Moveworks AI Assistant, 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. Click Get Started

   

3. Select ServiceNow as the source system

   

4. Start by selecting the Connector Selection

   

5. Select snow as the connector & primary system

   

6. Give your configuration a name

   

   Save your configuration name before continuing.

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

   

8. Navigate to the newly generated Table mappings page

   

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

   

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

    

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

    

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

---

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

    "custom_data.u_environment": "$TRIM($TEXT((u_environment).value OR ''))",
    "custom_data.u_vip_support": "$TRIM($TEXT((u_is_vip).value OR ''))",
    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.

    

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

    

15. 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:
       • "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(...) logic.

    2. Using Static Raw Strings

    To write a specific piece of text that isn’t a variable, you must escape the quotes or use single quotes — both are valid in Bender.

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

    

16. Next, navigate to the Resolve table and update the close_code field:

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

    

17. Select Next, review the Routing & Workflow conditions (no updates needed at this time), then Save

    

    

18. Navigate to the Table Actions and confirm that the Incident ticket type is enabled for Polling and Concierge Updates.

    

    

19. Ensure that the Access Control Strategy is set to Public to all members

    

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

    

    

21. 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: Revisiting Lab 4a — Why Form Submission Failed

2.1: Why “I need a standard laptop” didn’t complete

At the end of Lab 4a, you asked the AI Assistant "I need a standard laptop". The Assistant surfaced the Standard Laptop form and walked you through filling it in chat — but when you tried to submit, nothing was actually created in ServiceNow.

That’s because form handling in Moveworks splits across two capabilities:

1. Form ingestion (Lab 4a) makes forms discoverable and fillable. Moveworks pulls the catalog items, permissions, and field definitions from ServiceNow so the AI Assistant can ask follow-up questions and render the form in chat.
2. Ticketing configuration (this lab) provides the destination tables Moveworks writes to. A form submission creates a Request Item (sc_req_item) record in ServiceNow, which requires the Request and Request Item tables to be mapped in your ticketing configuration.

Without ticketing configured, the Assistant can collect the inputs — but it has nowhere to post the final payload.

Relevant Documentation:

• Moveworks Help: Forms Integration — ServiceNow — how form ingestion works and which fields Moveworks supports
• Moveworks Help: Configuring Ticketing for ServiceNow

2.2: Good news — defaults already covered most of it

When you clicked Setup Defaults in step 7 of the walkthrough, Moveworks pre-loaded mappings for four ticket types, each with a different set of default actions:

Section 1 walked you through customizing the Incident mapping. The other three — Request, Request Item, and Task — are already in place from the defaults. You only need to verify them.

2.3: Verify the Request, Request Item, and Task mappings

1. Navigate to Ticketing > Table Mappings in Moveworks Setup.

2. Confirm all four tables — incident, sc_request, sc_req_item, and sc_task — appear in the list.

3. Click into sc_request and verify the default fields:

   Field	Expected Value
   Table Name	sc_request
   Ticket Type	Request
   Prefix ID	REQ
   Requestor Column Name	requested_for

4. Repeat for sc_req_item:

   Field	Expected Value
   Table Name	sc_req_item
   Ticket Type	Request Item
   Prefix ID	RITM
   Requestor Column Name	request.requested_for

5. Repeat for sc_task:

   Field	Expected Value
   Table Name	sc_task
   Ticket Type	Task
   Prefix ID	TASK
   Requestor Column Name	request.requested_for

   

6. Under Table Actions for sc_request, confirm Create is enabled. This is the action Moveworks invokes when a form submission completes.

   Save your Table Mappings if you made any changes.

2.4: Re-test the Lab 4a query

Head back to the Moveworks AI Assistant and type "I need a standard laptop" again.

This time the form should fill and submit — creating a new RITM in your ServiceNow training instance. Verify it appears under sc_req_item.list in ServiceNow.

---

✅ 3: 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

      

---

❗ 4: 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.

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

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

   

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

   

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

4.5: Check the Moveworks Status Page

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

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

---

🪞 5: 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

---

⚙️ 6: Configuration Details

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