---
title: Best Practices for Configuring Rich Ticket Filing
deprecated: false
hidden: false
metadata:
  robots: index
---
**Rich Ticket Filing (RTF)** allows admins to configure and present users with a UI Form when they want to file a ticket through the Moveworks AI Assistant for specific type of **Issue/Request**. Instead of users just filing a generic Ticket type which collects a **short description, description and attachments** to create it on the ITSM.

**RTF** lets you capture structured fields such as dropdowns, check-boxes, dates and attachments. This guide walks you through the Overview of how **Rich Ticket Filing (RTF)** works and the **Best practices** surrounding the approach which should be taken depending on the Enterprise requirement.

# Overview of Configuring RTF

Moveworks requires the combination of the below configurations in order to Render an RTF Form in the Assistant Chat interface. Each Configuration serves a purpose and is required in conjunction with the others to be used effectively.

![](https://files.readme.io/fef4ea6152fcf5c99ec4d635b51f81401a44b5b9a5d2d487c25fc988b7b06f8c-Screenshot_2025-09-18_at_3.58.48_PM.png)

### 1. Ticket Payload Configuration

**Purpose** : This configuration is what connects Moveworks to the ITSM system to allow creation of a specific Ticket Type.

Before the RTF can be created, we first need to create the **Ticket Mapping configuration** for the ticket type which the user will be submitting to the ITSM system.

* Define the **Ticket Type** and **Destination Table** where the Ticket will be created.
* The Attributes defined in the **Create Ticket Mapper Payload** will be used to Configure the RTF later.

You can follow the Integration specific Guides for the different ITSM systems mentioned [here](/docs/moveworks-setup-ticketing#/setting-up-ticketing-in-below-integrations).

### 2. RTF Form Configuration

**Purpose** : Once the Ticket Mapping has been configured, We need to define these attributes inside the Rich Ticket Filing Configuration in order to define the fields to be rendered.

* Define the RTF ID(unique), RTF Title, RTF Description.
* Add the Fields inside the RTF which include types like single-line text, multi-line text, single-option dropdowns, check boxes.

### 3. Handoff Configuration

**Purpose** : This configuration is responsible for rendering the RTF in the AI Assistant Chat platform. You will use a combination of Display Configurations here to define the UI fields.

* Define the Handoff Item Name and which Domain it falls under.
* Describe the Handoff Item Type and define the **ID of the RTF Form**.
* Create the relevant Display configurations to support the Rendering of the RTF.

### 4. Ticket Workflows

**Purpose** : This configuration defines the Workflow which will carry out the Action of creating the ticket in the External ITSM System. The workflow will utilise the attributes from the **Create Payload Mapper** which has been configured for the **Ticket Type.**

* Create a Workflow and Define the local routing conditions which are Workflow Specific.
* Define the Global Routing Conditions for the Workflows.

# Recommended RTF Configurations Approaches

Customers may have different requirements for their ticket-filing workflows and how RTF needs to be implemented. Taking all these scenarios into account for other Enterprises, We have 2 common approaches which can be used depending on the Requirements :

## Single RTF Form Routed via a Single Workflow

This approach should be used when your organisation wants users to :

* Interact with a single RTF Form which contains a broad set of fields for a particular **Category** request (e.g., HR requests have **sub-categories** such as Benefits, PTO, Payroll, Policies)
* This way users can choose an HR Category within the RTF form, and then the singular Workflow allows you to route the submission to the **appropriate ticket table** based on the user choice for a given field.
* The RTF will be presented to the User via a Single Handoff Category.
* Using a **Single Workflow**, this method allows us to route a **single RTF** to **multiple Ticket Destinations** or support different Payloads.
* By writing DSL Rules based on the RTF fields, We can route a single Workflow to use multiple payloads

  ![](https://files.readme.io/759b4bfaedd2b66086f9cf63bcadac0094784a89459b0cdf97407ba0224f4ef7-Screenshot_2025-09-22_at_9.54.20_PM.png)

### Please follow [this guide](/docs/setup-rich-ticket-filing) on how to configure this approach of RTF for a single entry point.

***

## Multiple RTF Forms Routed via Multiple Workflows

This approach should be used when your organisation wants to:

* Provide different **RTF forms for each request category**, where each category requires distinct fields or customisation.
* **Minimise** conditional logic inside a single form by letting the **context domain classifier** automatically surface the correct form to the user.

With this setup, each **domain** (e.g., Benefits, PTO, Payroll) has its own **RTF form** and its own dedicated workflow. This makes field mapping simpler and **avoids complex branching logic.**

* Each **domain** corresponds to a specific **ticket category** (e.g., BENEFITS_DOMAIN, PTO_DOMAIN, PAYROLL_DOMAIN).
* Each **domain** has its own **RTF form** containing only the relevant fields (e.g., Benefits → coverage type, plan options; PTO → start and end dates; Payroll → pay period or paycheck issue).
* This allows us to maintain a single **RTF** form for each **domain**.
* Each **domain** routes directly into its associated ServiceNow table with a straightforward, **single workflow**.

![](https://files.readme.io/f87cc7700a8d45ef2266e61600f9cd7818428383ee5fc2712d98a6be69916e60-Screenshot_2025-09-22_at_10.16.28_PM.png)

### Please follow [this guide](/docs/setup-rich-ticket-filing) on how to configure this approach of RTF for multi RTF entry point.