> This page is for Assistant Platform. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Lab #8: Ticketing (Core) > **Info** > > ## Overview > > * **Learning Objectives:** Configure, modify, validate, and test ServiceNow IT ticketing in Moveworks > * **Estimated Time:** 45 minutes > * **Prerequisites:** > * [Lab #7](/ai-assistant/getting-started/labs/moveworks-setup/lab-7-basic-forms) complete (forms ingested; Section 2 revisits it) > * Admin access to your ServiceNow instance --- ### 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](/service-management/concierge-assistant) * [Moveworks Help: Configuring Ticketing for ServiceNow](/service-management/concierge-assistant/moveworks-setup-ticketing/new-ticketing-journeyconfigure-ticketing-for-servicenow) * [Moveworks Help: Ticket Data Object](/api-reference/configuration-languages/data-dictionary#ticket) * [Moveworks Help: Handoff Overview](/service-management/live-agent-handoff-assistant) --- ## 🛠️ 1: Walkthrough > **Error** > > **Save after every change.** Moveworks Setup does not auto-save. Click **Save** before you leave any page, or you lose your changes. This is the most common mistake in this lab, so the steps below include save reminders. ### 1.1: Add Two Custom Fields to the Incident Table Later steps map two custom incident fields into Moveworks. A stock ServiceNow instance doesn't have them, so create them first. 1. In ServiceNow, navigate to **System Definition > Tables** and open the **Incident** table (`incident`). 2. In the **Columns** related list, click **New** and create a column with **Type** `String` and **Column label** `Environment`. Confirm **Column name** reads `u_environment`, then click **Submit**. 3. Click **New** again and create a column with **Type** `True/False` and **Column label** `Is VIP`. Confirm **Column name** reads `u_is_vip`, then click **Submit**. ### 1.2: Configure Ticketing 1. Navigate to **Ticketing > Ticketing Configuration > New ticketing configuration** ![](/_fern-files/_img/07185839099a8a08e802de50c899ae7d1460367a00b4a9f6b49e9da0f65724a3.webp) 2. Click **Get Started** ![](/_fern-files/_img/04be3e1745a5fbd030eb10f09e1a26d99f72d713fbb5eea430207b40a36c301b.webp) 3. Select **ServiceNow** as the source system ![](/_fern-files/_img/15c4f9e525dbfc1bebb391ce22747facb859835161c9e3482ba2b9cce82af224.webp) 4. Start by selecting the **Connector Selection** ![](/_fern-files/_img/2af6673203858063c6ce0b7b09f49810ec8b38e9dbf135706a07ed64cb814d71.webp) 5. Select `snow` as the `connector` & `primary system` ![](/_fern-files/_img/da4cab6c0478ad366e862f487584097f6492ef2ccc142f87c94a679165e03ca5.webp) 6. Give your configuration a name ![](/_fern-files/_img/65e133524feae8f0357aec11c1258e10991de28d7c0be3dd9ab63e60d6f0f310.webp) > **Warning** > > **Save your configuration name** before continuing. 7. Click **Back** in the bottom left, then click **Setup Defaults** at the top of the page to create the preconfigured ticket types. ![](/_fern-files/_img/1229b84d6af899f84a5a4f657d5a90370e826694e38e55eee9be118db180d3a7.webp) 8. Navigate to the newly generated **Table mappings** page ![](/_fern-files/_img/cd9008c2ca434843392cfd8a7d09fc71b9913c8a7c2796725cb1235225850334.webp) 9. By default, Moveworks integrates with the tables shown. Click the **Incident** table: > **Note** > > Each ticket destination (table) lists the actions configured for it at the bottom. For Incident, these come preconfigured: > > * **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 ![](/_fern-files/_img/826f92b16fa79e501ba2fcf44018f2d2d9e999291739780380564c1278687f68.webp) 10. The Incident table definition opens. | 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 ticket field that represents the user who opened the ticket, often `caller_id`, `requested_for`, or `opened_by` | ![](/_fern-files/_img/4c2ba2efac3aecb87b2e145eeec135ca0d7db6ba370afe1ffcdadf4af942bbdc.webp) 11. Navigate to the **Query** page and review the **States Configuration** > **Note** > > The default state mappings match a stock ServiceNow instance. In a live implementation, check the source ITSM for additional states and map any that are missing. ![](/_fern-files/_img/d9efb9551baf6a12f1b626c4be163c3f9c2e7bdc82500fa64b60c77db22a80c6.webp) 12. Next, add `custom_data` fields to the **Query** mapping. > **Note** > > Ticketing starts with a list of default fields. When an implementation needs fields that don't exist out of the box, add them as `custom_data`. Downstream ticketing workflows can then reference them. 13. Add these `custom_data` fields (the two fields you created in Section 1.1) 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, fields on the **left** are Moveworks fields, and fields on the **right** are source system fields. > Reference the [Ticket Data Object](/api-reference/configuration-languages/data-dictionary#ticket) page on the Moveworks Help Site to understand all of the fields available on the Moveworks Ticket object by default. ![](/_fern-files/_img/91bc34980b33611ae05cbe2314b76294b2a2ce4e5567cedde59dd4271846cfa4.webp) > **Warning** > > **Save your Query mapping** before continuing. 14. Scroll down to the **Input fields in Mapper** section and add the `u_environment` and `u_is_vip` fields. ![](/_fern-files/_img/83f286790e9d4e97e678b17d0ea38e1d9d16a74b4e4de0bb3360d83a5bee828f.webp) > **Warning** > > **Save your Input fields** before continuing. 15. Set a default value that Moveworks populates when it creates an incident in ServiceNow. Select **Create** and add the field `u_environment` with the value `prod`: * `"u_environment": "\"prod\""` > **Note** > > When configuring **WRITE** actions (Create, Update, Resolve, Reopen), the formatting tells Moveworks whether to use a fixed value or a variable you already defined in your query configuration. > > **Using Moveworks variables:** To use data Moveworks already holds, use a **single pair of quotes**. The value on the right must match the key you defined in your query mapping. > > * **Syntax:** `"target_field": "stored_variable"` > * **Example:** `"assignment_group": "assignment_group"` > Moveworks finds the key `"assignment_group"` in your query mapping and uses the result of its `$TRIM(...)` expression. > > **Using static strings:** To write fixed text that **isn't** a variable, 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'"` ![](/_fern-files/_img/75912726f0ec00f42907ca829cc71b780a4b5bd38cb206c6085e3b75ee15f445.webp) > **Warning** > > **Save your Create mapping** before continuing. 16. Open the **Resolve** action and update the `close_code` field: * `"close_code": "\"Resolved by caller\""` ![](/_fern-files/_img/eab9c6527b89fed8b767547111083d07c8001d87e50fb491190e5f3cc0b503b9.webp) > **Warning** > > **Save your Resolve mapping** before continuing. 17. Click **Next**, review the Routing & Workflow conditions (no changes needed), then click **Save**. ![](/_fern-files/_img/e15dc7f124193c29efba4334b6e031f25ed0ca12cbf4fe6569e6e2a04b3b0a82.webp) ![](/_fern-files/_img/798c31f5db91b80ad232f1d4186f84d77cafc166feb8e2e9cfc6e1f8ea922a59.webp) > **Warning** > > **Save your Routing & Workflow configuration** before continuing. 18. Open **Table Actions** and confirm the **Incident** ticket type is enabled for polling and concierge updates. ![](/_fern-files/_img/6a237066c67a9e2e3f120a7136d014d7730aedc02997c3068fa5df69ca81405a.webp) ![](/_fern-files/_img/daa92154120a6db458111a3c58007af97389f7deac1dfceb7c1138fda4f6a2c7.webp) > **Warning** > > **Save your Table Actions** before continuing. 19. Confirm the **Access Control Strategy** is set to **Public to all members**. ![](/_fern-files/_img/299508cb1b322c1a0740259db774c5a0087672bf054d75132cffaa8da328cc30.webp) > **Warning** > > **Save your Access Control configuration** before continuing. > **Note** > > This lab doesn't change the **Org level settings**, but they control these behaviors across all ticket types: > > * **Ingestion Control:** Determines how often Moveworks polls your ITSM (e.g., ServiceNow) for updates and how far back it looks for changes. > * **Notification Window:** Sets business hours and weekend rules so the Assistant doesn't message users overnight. > * **Nudge Logic:** Configures the "Inactivity Threshold": the number of days a ticket sits idle before the Moveworks AI Assistant automatically nudges the assignee. > * **User Display:** Toggles what the employee sees in chat, such as the ticket state, assignee info, or the ability to upload attachments directly through the Moveworks AI Assistant. 20. Open **Service Portal URL** and create a configuration with your `snow` connector and your portal URL (`https://[your-instance].service-now.com/esc`). This controls where users land when they click a ServiceNow ticket link in Moveworks. ![](/_fern-files/_img/2f5410cd02c41c03323a146b5b33ee0edf297db73f134e7e9353e0c0883902c5.webp) ![](/_fern-files/_img/bcfe84d943c3441aa36e23fe056ead1a1a63fbdaa5a2f60236d21008d531e244.webp) > **Warning** > > **Save your Service Portal URL configuration** before continuing. 21. Ticketing for incidents is configured. File a ticket with your Moveworks AI Assistant and test each action. --- ## 🔄 2: Revisiting Lab #7: Why Form Submission Failed ### 2.1: Why "I need a standard laptop" Didn't Complete At the end of [Lab #7](/ai-assistant/getting-started/labs/moveworks-setup/lab-7-basic-forms), you asked the AI Assistant `I need a standard laptop`. The Assistant surfaced the **Standard Laptop** form, but submitting it didn't create anything in ServiceNow. That's because form handling in Moveworks splits across two capabilities: 1. **Form ingestion** (Lab #7) 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 has nowhere to send them. **Relevant Documentation:** * [Moveworks Help: Forms Integration for ServiceNow](https://docs.moveworks.com/service-management/forms/forms-integration-servicenow): how form ingestion works and which fields Moveworks supports * [Moveworks Help: Configuring Ticketing for ServiceNow](/service-management/concierge-assistant/moveworks-setup-ticketing/new-ticketing-journeyconfigure-ticketing-for-servicenow) ### 2.2: The Defaults Already Cover Most of It When you clicked **Setup Defaults** in Section 1.2, Moveworks pre-loaded mappings for four ticket types, each with a different set of default actions: | **Ticket Type** | **Table** | **Prefix** | **Default Actions** | | --------------- | ------------- | ---------- | ------------------------------ | | Incident | `incident` | INC | Query, Create, Update, Resolve | | Request | `sc_request` | REQ | Query, Create | | Request Item | `sc_req_item` | RITM | Query, Update, Resolve | | Task | `sc_task` | TASK | Query, Update | Section 1 customized the **Incident** mapping. The other three (**Request**, **Request Item**, and **Task**) are already in place from the defaults; you only need to verify them. > **Note** > > **Why these four tables work together:** When the AI Assistant submits a form, it invokes the **Create** action on `sc_request`, the parent record (REQ). ServiceNow's workflows then generate the child line items on `sc_req_item` (RITM) and any fulfillment tasks on `sc_task`. That's why only `sc_request` needs **Create** enabled in Moveworks. ### 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` | ![](/_fern-files/_img/dc858832a16dca749cc18c2ac83e2fbcc54b964bb6bd5221b16268fbb6c9a923.webp) 6. In the `sc_request` table mapping, confirm the **Create** action is listed. This is the action Moveworks invokes when a form submission completes. > **Warning** > > **Save your Table Mappings** if you made any changes. ### 2.4: Retest the Lab #7 Request In the Moveworks AI Assistant, type `I need a standard laptop` again. This time the form should fill **and submit**, creating a new RITM in your ServiceNow instance. Confirm it appears in `sc_req_item.list`. > **Note** > > **Still failing?** See **Section 4: Troubleshooting** below. The most common cause is a required field on `sc_req_item` in your instance. Check the **API Logs** to see which field ServiceNow rejects. --- ## ✅ 3: Verification & Next Steps 1. **Finalize:** Confirm all configurations are saved. 2. **Check success:** In the AI Assistant, confirm you can do each of these ticket actions: 1. File ![](/_fern-files/_img/1cd11caf0ef1c9478944d4da8b3f9090421acf220983f3d65fc385074d302b5c.webp) 2. Query ![](/_fern-files/_img/824fbbbfa790fa50149af2c2aa2c78ea30a87e8a3c288ebfefdd2528b81207b1.webp) 3. Update (Add Comment) ![](/_fern-files/_img/89a2ff8decee432af77896914590227ceec19eb64c9996ad1a957c2203abbbfc.webp) 4. Resolve/Close ![](/_fern-files/_img/397753dd0a4cd6cec3ac1f8beb61e6b05744294f94772dc4db048b9469ad863e.webp) 5. Reopen ![](/_fern-files/_img/4133173bc1d8e24b042d1236c29b6baebbca5fe2c3e81b83d37a02f86ca4d34c.webp) > **Success** > > **Next:** [Lab #9: EmployeeWorks Web App](/ai-assistant/getting-started/labs/moveworks-setup/lab-9-employeeworks-web-app) --- ## ❗ 4: Troubleshooting: Why Can't I Act on a Ticket? A ticketing action fails when the way Moveworks creates or updates the ticket doesn't match what the source system expects. Work through these checks. ### 4.1: Identify the Failure When a call to the ticketing system fails, the Assistant tells the user it couldn't complete the action, often with a short summary of why. In this example, Moveworks failed to create a ticket, likely because a mandatory field was missing from the API request. ![](/_fern-files/_img/75b47a6f0d22056959602a4153bfd978180b49754cfa74a02b22636b17e175ee.webp) ### 4.2: Check the API Logs In Moveworks Setup, the **API Logs** module shows what Moveworks sent to the source system and how it failed. 1. Find the log entry for the error. You can search by requesting user, trace ID, method, or plugin. ![](/_fern-files/_img/b36b58ee814557a9afcf5c43c8eb977a427d0d67d1af1928fb69dbdfd55c3e2a.webp) 2. Read the error message. Here, the request payload is missing `short_description`, which ServiceNow requires. ![](/_fern-files/_img/325f52544b8399a3370d4e9fadc257749daa8fa92350cd8db718680f3bc48a7a.webp) ### 4.3: Build a Working Payload in API Playground Use the details from Section 4.2 to rebuild the payload in API Playground until the call succeeds. This can take a few tries, and in a live implementation you may need more information from the customer to resolve some values. 1. Open Moveworks Setup in another tab and navigate to **Connectors > API Playground**. ![](/_fern-files/_img/58ff01d928e312b73cee677f54553c8cb2c3c57f9c248f5111dbea9d988d1e48.webp) 2. Copy the `api_url_endpoint` and `request_payload` from the log entry. ![](/_fern-files/_img/de03230a0cbb2498881b213b6a8d17263d095c991fd11567f26bb6e13649b324.webp) ![](/_fern-files/_img/61af1bd0f0bf879036702401ed64e36b4e69d430b36a0a7e0fb7f657ba16e2c1.webp) 3. Paste them into API Playground, adjust the payload, and test it. ![](/_fern-files/_img/c8125bf546f3f748aa35786b6c4295add8d7cbd2be0fb049e10c76ef537fbbb9.webp) 4. Repeat until the call succeeds. ![](/_fern-files/_img/8d40186abc1f393439a8283ea53f6e3f60aff5a821443921b523216f42790e50.webp) ### 4.4: Update the Ticket Mapping With a working payload, open the part of the ticketing configuration that caused the issue, apply the fix, save it, and retest in the Assistant. ![](/_fern-files/_img/f6ef2ea54d10e596d0847b05ff0a64386f53d99299d1b82fc46b7be6d78e19ef.webp) ![](/_fern-files/_img/3d6dcf595fcbd639b461bee1e7656b4bbd6d1711c0a6cf7673a37762f0da57bd.webp) ### 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](https://status.moveworks.com/) ### 4.6: Escalate to Moveworks Support > **Warning** > > Ticketing issues are almost always a misconfiguration: the ticketing configuration doesn't match what the source system expects. Confirm with the ITSM administrator that the same API call works outside of Moveworks. If you've validated the above and still can't find the root cause, [open a ticket with Moveworks Support](https://docs.moveworks.com/ai-assistant/getting-started/support) and include: 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 The more detail you include, the faster Moveworks Support can help. --- ## 🪞 5: Reflecting on This Configuration Through this lab, 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. | **Field Name** | **Action / Value to Enter** | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **Custom incident fields** | `u_environment` (String), `u_is_vip` (True/False) | | **Connector Selection** | `snow` | | **Mark System as Primary** | ✅ | | **Query custom_data fields** | `"custom_data.u_environment": "$TRIM($TEXT((u_environment).value OR ''))",` `"custom_data.u_vip_support": "$TRIM($TEXT((u_is_vip).value OR ''))",` | | **Input fields in Mapper** | u_environment, u_is_vip | | **Create Field Mapping** | `"u_environment": "\"prod\""` | | **Resolve Field Mapping** | `"close_code": "\"Resolved by caller\""` | | **Table Actions: Tables to enable for concierge updates** | Incident | | **Table Actions: Tables enabled for polling** | Incident | | **Access Control: User access configuration** | Public to all members | | **Service Portal URL: Integration Id** | `snow` | | **Service Portal URL: Service Portal URL** | `https://[your-instance].service-now.com/esc` |