For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Logo
DeveloperAcademyCommunityStatus
  • Service Management
    • Overview
    • Concierge & Ticketing Capabilities Overview
    • Forms
    • Forms - Integration Specific Guides
    • Live Agent Chat / Handoff
    • Triage
      • Triage 2.0: Technology Overview
      • Configure Triage
        • Triage Discovery Questionnaire
        • Configure Triage 2.0
        • Configure Model Configurations
        • Configure Field Configurations
        • Configure Model Retraining
        • Configure Field Heuristic Rule
    • Approval Mirroring
    • Ticket Interception
    • Generic Ticketing Integration: Ticket Gateway
  • Administration
    • MyMoveworks
    • Organization Information
    • Roles and Permissions
    • MyMoveworks SSO
  • Moveworks Setup
    • Accessing Moveworks Setup
    • First-Time Login via Magic Link
    • Moveworks Setup Modules
    • Moveworks Setup: Module How To Guides
    • Plugin Management
    • Monitor Alerts
    • Audit Logs
    • DSL Fields Defaults
    • Data Crawling View
    • API Playground
    • Setup Homepage
    • Troubleshooting Hub
    • Security and Privacy Settings
    • Configuration Delete
    • Advanced Config Editor
    • Identity configuration
    • Onboarding Stage
  • Security
    • Security
    • Hyperlink & Button Expiry
    • Attachment Handling
    • Moveworks Subprocessors
  • Provision Management
    • Overview
    • Access Software
    • Access Groups
    • Access Account
  • Access Requirements
    • Overview
    • Update Set Modules
    • Ticketing Systems & ITSMs Access
    • Identity and Access Management Systems Access
    • Multi-Factor Authentication (MFA) Systems Access
    • Knowledge Access Requirements
    • Email Distribution List Systems Access
    • Facilities Management Access
    • Live Agent Chat Access
    • HR Information System Access
    • Expense Management Access
    • Calendar Management Access
  • Core Platform
    • User Identity
    • Moveworks On-Prem Agent
    • Approvals Engine
    • Entity Catalog
    • Configuration Languages
    • Moveworks Data Objects
    • SIEM
  • Employee Experience Insights
    • Overview
    • Breaking Down the Dashboard
    • Understanding Industry Benchmarks
    • Apps & Services
    • Impact Module
    • EXI Common Use Cases
    • Configure EXI
    • Ticket Backpolling
  • Knowledge Studio
    • Overview
    • Knowledge Studio Configuration
    • AI Powered Recommendations
    • Inspecting & Verifying Sources
    • Publishing Articles
    • Creating Knowledge Articles
    • Resolving IT Tickets Guidance
DeveloperAcademyCommunityStatus
On this page
  • 1. Which ITSM are you using?
  • 2. Do you have sufficient ticket history in your ITSM?
  • 3. What tickets are in scope for Triage?
  • 4. What ticket fields are in scope for Triage?
  • 4a. For group-based fields: is user location an important routing attribute?
  • 4b. For category-based fields: is there a parent-child relationship between category and subcategory?
  • 5. For each field in scope, are there values that should be excluded from predictions?
  • 6. Would you like to deploy in dry-run mode first?
Service ManagementTriageConfigure Triage

Triage Discovery Questionnaire

Pre-implementation questions to answer before configuring Moveworks Triage 2.0.

||View as Markdown|
Was this page helpful?
Edit this page
Previous

Configure Triage 2.0

Next
Built with

Use this questionnaire to assess readiness and gather the information needed before beginning the Configure Triage 2.0 guide.


1. Which ITSM are you using?

Triage 2.0 currently supports the following systems:

  • ServiceNow
  • Jira
  • Zendesk
  • Cherwell
  • FreshService
  • Salesforce

2. Do you have sufficient ticket history in your ITSM?

Triage 2.0 builds its model from historical tickets. It needs enough historical data to identify patterns and make accurate predictions.

If your environment has fewer than 3,000 tickets in the past year, or if the ticket data is stale, it is not a good candidate for Triage at this time. Without sufficient recent history, the model will not have enough signal to make reliable predictions and results are likely to be poor.


3. What tickets are in scope for Triage?

This defines the Triage Filter (Step 7 of configuration). Identify the following dimensions:

  • Ticket type — e.g. INCIDENT, REQUEST, HR_CASE
  • Contact type — Triage only intercepts digitally-submitted tickets. Scope to: Portal, Email, AI Assistant. Exclude walk-ups, phone calls, and automated alerts.
  • Group — Triage should intercept tickets assigned to the L1 Service Desk. Avoid intercepting L2/L3 groups, as forms auto-assign tickets directly to them.

4. What ticket fields are in scope for Triage?

Prioritize in this order:

  1. Routing-based fields (highest value) — e.g. assignment_group, cmdb_ci. These directly control where the ticket goes and can trigger downstream business rules (e.g. ServiceNow rules that set assignment group based on cmdb_ci).
  2. Category-based fields — e.g. category, subcategory. Lower operational impact but improve reporting and ticket quality.

4a. For group-based fields: is user location an important routing attribute?

Look at the names of the groups in scope. If you see region indicators (e.g. NA, EMEA, APAC), location is likely a meaningful signal for the model.

If location is important, add requested_for.location as an Additional Feature in the Triage 2.0 Configuration (Step 6).

4b. For category-based fields: is there a parent-child relationship between category and subcategory?

In most implementations, category determines the set of valid subcategory values. If this relationship exists, configure a single concatenated Triage model to predict both fields simultaneously rather than two separate models.


5. For each field in scope, are there values that should be excluded from predictions?

For some fields, certain values should never be predicted — for example, L2 or L3 groups that require a human agent to intervene before assignment.

Identify any values that should go into the block list for each field. If a ticket would be predicted to a blocked value, Triage will fall back to the configured default value instead.


6. Would you like to deploy in dry-run mode first?

Dry-run mode allows you to evaluate Triage behavior and predictions without writing any values to tickets in the production environment. This is useful for validating model quality before going live.

To enable dry run: set Enable Triage = false and Send As Update = true in the Field Configuration.

Dry-run mode is an evaluation period, not a long-term state. It should not remain active for more than 2 weeks.