Configure Triage 2.0

Triage 2.0 classifies tickets by building a field-specific semantic index and using it to predict values like assignment_group, category, or cmdb_ci. Complete all steps below in order — each step depends on the previous one.

Step 1: Configure Ticket Attribute Mapping

Before Triage can read or write ticket fields, those fields must be mapped in your Ticketing Configuration.

Navigate to Ticketing > Ticketing Configuration > [Your Config] > Table Mappings > [Ticket Type]

Query Ticket Payload

For each ticket type you intend to triage, add the triage field(s) to the Query Ticket Payload. Each triage field requires two entries:

Also add each triage field to the Input Fields in Mapper section of the Query configuration. This ensures the field values are available to Triage at runtime.

Write Ticket Payload

Triage must write its prediction back to the ticket. How you configure this depends on whether Triage Before Ticket Creation (TBTC) is enabled:

Step 2: Ticket Backpolling

Triage 2.0 builds its index from historical tickets stored in Moveworks’ ticket tables. Backpolling populates those tables from your ITSM.

1. Navigate to Core Platform > Ingestion > Ticket Backpolling
2. Set Product Area to Employee Experience Insight
3. Select your ITSM Integration
4. Set a Start Date and End Date covering the historical range you want to train on (e.g. 180 days back)
5. Click Start Backpolling

Verifying completion: Check the Backpolling Logs table at the bottom of the page. The Employee Experience Insight row must show a status of Completed with matching Records Polled and Records Processed counts before you proceed.

Step 3: Field Configurations

Field Configurations define what Triage predicts, for which ticket type, and how it behaves.

1. Navigate to Triage > Field Configurations
2. Click Create
3. Fill in the following fields:

Field Settings

• Field Name — The Moveworks field name to predict, e.g. assignment_group, category, cmdb_ci
• Ticket Type — The ticket type to triage, e.g. INCIDENT, hr_case
• Routes — Controls when triage fires:
  • TICKET — Triage runs on existing tickets via polling. Use this for most implementations.
  • BOT — Triage runs before ticket creation (bot-created tickets only). Requires TBTC to be on and the field mapped in the Create Ticket Payload.
• Select Connector — Your ITSM connector, e.g. snow

Dry Run vs. Live Mode

• Send As Recommendation — Sends a work note with the prediction rather than writing the field value. Requires Enable Triage = true.
• Start Date — Required for the analytics dashboard to show results. Format: YYYY-MM-DD. Without this, the dashboard will show no data.

Predicted Value Filter

Controls which values Triage is allowed to predict:

• Block list — Values in this list will not be predicted. If the model’s top prediction is on the blocklist, it falls back to the default value.
• Allow list — Only values in this list are eligible to be predicted.

Values to Overwrite

Controls which tickets are eligible for triage based on the field’s current value:

Other Fields

• Mapped Field — Used for analytics categorization. Choose from assignment_group, category, or call_type. If unsure, use category.
• Required Field — For dependent models where a prediction must succeed before downstream models run (e.g. must predict category before subcategory). If checked, Triage will early exit if no prediction is made for this field.
• Default Value — Fallback value if no prediction passes the confidence threshold. Use the sys_id for sys_id-backed fields.

4. Click Submit using the title format: triage.[field].[ticket_type].['Route']
   • Example: triage.assignment_group.INCIDENT.['TICKET']

Step 4: Field Heuristic Settings

Heuristic rules let you override model predictions with deterministic logic — for example, always routing tickets mentioning “VPN” to the Network team regardless of what the model predicts.

1. Navigate to Triage > Field Heuristics Settings
2. Click Create

3. Under Field Settings, enter the same Field Name, Ticket Type, Routes, and Connector as the corresponding Field Configuration from Step 3.
4. Under Heuristic Rule Configs, add any override rules. Leave this section empty if you have none.

5. Click Submit using the same title format: triage.[field].[ticket_type].['Route']

Step 5: Metadata Cache

The Metadata Cache maintains an up-to-date list of valid values (e.g. active assignment groups) that Triage uses when ranking predictions.

1. Navigate to Triage > Metadata Cache
2. Click Create
3. Fill in the following:

4. Click Submit

Step 6: Triage 2.0 Configuration & Build Index

Initial Setup

1. Navigate to Triage > Triage 2.0

2. Click Create and fill in:
   • Field Name — e.g. assignment_group, category
   • Select Additional Features — Optional signal fields to improve prediction ranking (e.g. requested_for.location)
   • SQL Parameters — Set at minimum:
     • Ticket type: itsm_ticket_type = 'INCIDENT'
     • Contact type: contact_type IN ('Assistant', 'Portal', 'Email') — filters out walk-ups, phone calls, and automated alerts
     • Add DSL-based filters for any additional scoping, e.g. json_extract_scalar(ticket_custom_data, '$.u_domain') in ('...')
   • Lookback Window (Days) — How far back to pull training data (e.g. 180)

3. Click Calculate Scope — this runs a query against your backpolled ticket data and returns an estimated training set size.

4. Click Save Configuration

Build Index

1. Click Not Started to begin building the index. The status will update to success or failure once complete.
2. Click Fetch Report to generate the Precision & Coverage graph.
3. Select a model threshold based on your target:
   • High precision (> 90%) — fewer predictions but higher accuracy; recommended for conservative rollouts
   • High coverage — more predictions; maximizes Triage impact
4. Click Save Threshold

Step 7: Configure Triage Filter

The Triage Filter controls which tickets are eligible for triage at runtime. When a ticket arrives, Moveworks evaluates in this order:

1. Triage Filter — is this ticket in scope?

2. Values to Overwrite (Step 3) — is the field’s current value eligible to be overwritten?

3. Allowlist / Blocklist (Step 3) — is the predicted value permitted?

4. Navigate to Ticketing > Ticketing Settings > Ticket Filters > Skill-specific ticket filters > Ticket filter for Triage skill

5. Configure your filter rules to define which tickets Triage should act on

6. Validate your syntax using the Validate Syntax button and test against tickets that should be in scope

Step 8: Enable Triage 2.0

Two toggles must both be on for Triage to go live:

1. Field Configurations → Enable Triage — enable this for each model configured in Step 3

2. Triage 2.0 product-level switch — navigate to Triage > Triage 2.0 and enable the product-level toggle

Once both are enabled, Triage 2.0 is live. Monitor predictions via the Triage analytics dashboard.