--- title: Ticketing and Concierge Configuration Overview excerpt: '' deprecated: false hidden: false metadata: title: '' description: '' robots: index next: description: '' --- This section provides a high level overview of configuring Moveworks Concierge, as well as important foundational terminology to understand before diving into the configuration. Terms such as Ticket Type, Ticket Destination, Domain, Prefix, Table Name, Service Desk ID, Ticket Mapping, Ticket Routing, and Ticket Workflow are technical concepts that are required to be familiar with before starting the ticketing configuration. Familiarity with these terms will help you follow the rest of the guide and configure effectively. ## Key Terminology
Term Definition
**Ticket Type** A ticket type is a classification or category—such as INCIDENT, REQUEST, or HR CASE—that defines the nature and workflow of a ticket and mapping to a specific system record. * **INCIDENT** - This type of ticket refers to an unexpected issue or disruption that you're facing with a service or product, which needs to be fixed to restore normal operation. * **REQUEST** - This is a type of ticket you would create when you need a specific service or product from the support team. It could be anything from a new software installation to a request for information. * **REQUEST_ITEM** -This specific type of ticket refers to a request for a particular item, like a piece of hardware or software. It's typically used when you're asking for something tangible or downloadable. * **CALL** - This ticket is used to document a telephone call with the support team. In this scenario, you've probably reported an issue or made a request over the phone, and this ticket keeps track of that interaction. * **TASK** - This type of ticket represents a specific task that the support team needs to carry out to resolve an issue or fulfill a service request. * **MISC** - This type of ticket is used for situations that don't fit into other categories. If you've got a unique or uncommon issue, it's likely it would be categorized under this ticket type. * **UNIVERSAL_REQUEST** - This type of ticket is used when making a broad request that might involve multiple departments or aspects of the support team's service. It's a way to organize complex requests that can't be covered in a standard request ticket. * **HR_CASE** - Map your HR related ticketing destinations into this ticket type
**Ticket Destination** The logical container or structure within your external ticketing system where tickets are created and managed e.g., the table`incident`in ServiceNow and `IssueType`in Jira
**Domain** A domain in Moveworks refers to a high-level category—like IT, HR, or FACILITIES—used to route employee requests to the appropriate support area or team. This classification ensures that a particular ticket is handled efficiently by the right department or function (e.g., `IT_DOMAIN`, `HR_DOMAIN`). Read more on [Domains](/docs/domain-definitions-assistant)
**Prefix** A unique identifier added at the beginning of a ticket reference for clear categorization and easy tracking e.g., "IT" for`IT-12345` in Jira or "INC" for `INC018320122` in ServiceNow
**Table Name** Name of the external ticketing system table storing the ticket e.g., the table`incident`in ServiceNow and `IssueType`in Jira This value is usually the same as the **Ticket Destination** as shown above
**Service Desk ID** ID for a project/service desk in systems like Jira.
**Ticket Mapping** Setup that connects Moveworks to your ticketing system and defines actions like create/update.
**Ticket Routing** Logic that determines which workflow to use based on context.
**Ticket Workflow** Ticket workflows are sequence of steps Moveworks executes for a ticketing action. The system provides predefined default workflows for standard ticket actions, detailed as follows: * :one: **Create Ticket Workflow:** This workflow initiates when a new ticket is generated by the AI Assistant, establishing the foundation for ticket creation in the **Ticket Destination** and determining which fields will be populated.. * :two: **Query Ticket workflow :** This workflow runs when an end user requests details for a specific ticket or their most recent tickets. * :three: **Update Ticket Workflow:** This workflow permits modifications to existing tickets, such as status changes and adding end user comments * :four: **Resolve Ticket Workflow:** This workflow plans how the ticket is resolved. It guides the process to ensure the issue has been properly dealt with, documented, and resolved. * :five: **Reopen Ticket Workflow:** This is activated when a previously resolved or closed ticket needs to be reexamined. The procedure ensures the ticket receives proper attention for resolution
## Ticket States and State Mapping ### Internal States Internal States are the names or labels used within Moveworks AI Assistant to categorize the status of a ticket. These states are part of your internal workflow or process management. In the AI Assistant, there are a total of 5 Internal States * **NEW**: Represents a newly created or reopened ticket. * **WAITING_FOR_USER**: Indicates that the ticket is waiting for input or action from the user. * **WIP** (Work In Progress): Marks a ticket that is actively being worked on. * **RESOLVED**: Signifies that the ticket has been resolved. * **CLOSED**: Shows that the ticket is closed, either because it was completed or canceled. > 🚧 NO LONGER SUPPORTED > > **WAITING_FOR_VENDOR**, **WAITING_FOR_APPROVAL** and **NOT_APPLICABLE** are legacy states that are no longer supported in AI Assistant ### External States External States are the names or labels used in the connected Ticketing Service Management system . These states reflect the status of a ticket as recognized by the external system. They are mapped to internal states to ensure consistency and communication between systems. ## Mapping Process **State Mapping**: The process involves linking each external state to an internal state. This ensures that when a ticket's status changes in the Ticketing Service Management system, it is accurately reflected in the AI Assistant. _For example_, if a ticket in the ServiceNow is marked as "In Progress" or "On Hold," it corresponds to the internal state of **WIP** the AI Assistant **State Transition**: When an action occurs (e.g., a user comment or a resolution of a Ticket), the system updates the ticket's state based on these mappings. This ensures that both systems stay in sync and reflect the current status of the ticket accurately. *** ## The Process of Configuring Moveworks Ticketing and Concierge 1. **Select the Source Ticketing System:** Choose the appropriate connector for your ticketing system. 2. **Configure Ticket Types:** Configure the relevant ticket types and relevant tables or projects from your existing Ticketing system, which you would like to integrate into Moveworks. 3. **Configure Ticket Action Mapping**: This is where you configure Ticket Mapping and Ticket Action Payloads that get used by the Moveworks AI Assistant for ticketing actions such as querying, creating, updating, resolving, and reopening tickets. 1. Specify how Moveworks performs ticket actions (create, update, resolve, reopen): * Map data fields between Moveworks and your system. * Define status/value mappings to trigger notifications. 4. **Configure Ticket Workflows** (Routing & Workflow Conditions) - Set conditional rules to route requests to the correct workflow based on attributes like domain, user attributes, or ticket type. 1. Define the operational steps for each ticket action: * Choose connector. * Configure API calls and data payloads. * Add conditional or default steps. * Following Error Codes can be defined under Raise Exception Action Type | **Error Code** | **Description** | | -------------- | ------------------------------------------------ | | **5301** | Cannot add a comment to the ticket. | | **5302** | Failed to close the ticket. | | **5303** | You do not have permission to close the ticket. | | **5304** | Unable to create a new ticket. | | **5305** | Agent channel handoff is not configured. | | **5306** | Error occurred during agent channel handoff. | | **5307** | You do not have permission to view this ticket. | | **5308** | You do not have permission to reopen the ticket. | | **5309** | Cannot add a comment to a closed ticket. | | **5310** | A required user comment is missing. | 5. **Configure Ticket Filters** - Control which tickets are included/excluded from bot actions: 1. **Standard Filters**: Apply globally across the assistants 2. **Skill-Specific Filters**: Apply only to certain actions (e.g., notifications). 6. **Ticket Notifications (Concierge Notifications)** -- Customize user notifications for key events: 1. Enable/disable alerts (e.g., resolved, commented). 2. Configure nudge rules. 3. Set quiet hours or working hours. ## Setting up Ticketing in below Integrations After you've reviewed this configuration process, you can follow the detailed step by step guides below to configure Moveworks Concierge for your Ticketing system: * [Configure Ticketing for ServiceNow](/docs/configure-ticketing-for-servicenow) * [Configure Ticketing for Jira Service Desk](/docs/configure-ticketing-for-jira-service-desk) * [Configure Ticketing for Fresh Desk](/docs/configure-ticketing-for-fresh-desk) * [Configure Ticketing for Fresh Service](/docs/configure-ticketing-for-fresh-service) ## Common Enhancements Once you've completed the baseline configuration steps above, oftentimes you may configure common enhancements like Rich Ticket filing. ### Rich Ticket Filing Enhance the ticket creation flow with custom forms: * Define fields to collect per domain/type. * Auto-fill known information. * Deliver form-based UX within chat. You can view more details about the [Rich Ticket Filing configuration in this guide](/docs/setup-rich-ticket-filing). ## Key Callouts / Common Mistakes 1. When passing an attribute from the Ticket Workflow Ticket Mapper Payload to the ticket action config, be sure to map the attribute/variable in both Ticket Action Payload & Ticket Workflow configurations.