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
      • Ticketing and Concierge Configuration Overview
      • Ticket Filters
      • Concierge Integrations
      • Ticketing Troubleshooting
        • Troubleshooting: Ticket Resolution
    • Forms
    • Forms - Integration Specific Guides
    • Live Agent Chat / Handoff
    • Triage
    • 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
  • Troubleshooting Ticket Resolution Failures
  • Overview
  • 1. Missing Required Fields (Most Common)
  • Symptoms
  • Diagnostic Steps
  • 2. Workflow Transition Constraints
  • Symptoms
  • Diagnostic Steps
  • 3. Technical Behavior: The “WIP” Transition Issue
  • The Logic
  • Why This Fails
  • The Solution: Source-State-Specific Mapping
  • 4. Permission & ACL Restrictions
  • Symptoms
  • Resolution
  • 5. System-Specific Considerations
  • Jira Service Desk
  • ServiceNow
  • 6. Testing Matrix
  • 7. Escalating to Moveworks Support
Service ManagementConcierge & Ticketing Capabilities OverviewTicketing Troubleshooting

Troubleshooting: Ticket Resolution

Understanding Moveworks Resolve Ticket State Transitions
||View as Markdown|
Was this page helpful?
Edit this page
Previous

Forms

Next
Built with

Troubleshooting Ticket Resolution Failures

Overview

This guide covers the most common reasons why “Resolve Ticket” actions fail when triggered via Moveworks. Use this guide to diagnose failures across Jira, ServiceNow, Zendesk, and Freshservice.

1. Missing Required Fields (Most Common)

The most frequent cause of resolution failure is a “Mandatory Field” constraint. When Moveworks attempts to update or transition a ticket, the ITSM system rejects the call because a field required by the workflow has not been populated.

Symptoms

  • Error messages such as: "Field 'Resolution Code' is required" or "Mandatory field missing: [Field_Name]".
  • The ticket remains in its original state.

Diagnostic Steps

  1. Check ITSM Requirements: Open a ticket in your ITSM (Jira/ServiceNow) and try to resolve it manually. Note any pop-up screens or fields that appear.
  2. Verify Field Mapping: Ensure these required fields are either:
    • Set to “Optional” in your ITSM for the API user.
    • Populated automatically via Moveworks “Update Ticket” configuration.
    • Passed as part of the resolution transition in the Moveworks Setup UI.

2. Workflow Transition Constraints

ITSM systems use state machine logic. A ticket cannot move from State A to State C if the workflow only allows A -> B or B -> C.

Symptoms

  • Error messages like: "Invalid transition", "Action not found", or "Transition not allowed from state: [State_Name]".

Diagnostic Steps

  1. Identify the Source State: Note exactly which state the ticket was in when the user clicked “Resolve.”
  2. Map the Path: Consult your workflow diagram in the ITSM. Is there a direct path to “Resolved”?
  3. Validate Permission: Ensure the Moveworks Service Account has the “Transition Issue” permission for that specific step.

3. Technical Behavior: The “WIP” Transition Issue

A specific nuance of the Moveworks “Resolve Ticket” action is that it performs a multi-step transition.

The Logic

Moveworks does NOT go: Current State → RESOLVED. Instead, it performs an atomic update: Current State → WIP (Work In Progress) → RESOLVED.

Why This Fails

If your ITSM workflow allows a direct move from WAITING_FOR_CUSTOMER to RESOLVED, but prohibits a move from WAITING_FOR_CUSTOMER to IN PROGRESS, the Moveworks action will fail.

The Solution: Source-State-Specific Mapping

You must ensure a valid path to “WIP” exists for every state where resolution is allowed.

Recommended Mapping Configuration:

Internal StateSource StateTarget State (ITSM)Transition ID
WIPWAITING_FOR_CUSTOMERIn Progress[ID_for_this_path]
WIPON_HOLDIn Progress[ID_for_this_path]
WIP*In Progress[Default_ID]
RESOLVED*Resolved[Resolve_ID]

4. Permission & ACL Restrictions

Even if the workflow and fields are correct, the Moveworks Service Account may be blocked by Access Control Lists (ACLs) or Permission Schemes.

Symptoms

  • Error message: "403 Forbidden" or "Insufficient permissions to update this record".
  • Failure occurs only for specific ticket types or specific assignment groups.

Resolution

  • Jira: Ensure the user has “Transition Issues” and “Edit Issues” permissions in the Project Permission Scheme.
  • ServiceNow: Ensure the integration user has the itil role and that no “Write” ACLs are restricting the state or resolution_notes fields.

5. System-Specific Considerations

Jira Service Desk

  • Transition IDs: Use the numeric ID (e.g., 761), not the name “Resolve.”
  • Resolution Field: Jira requires the “Resolution” field to be set (e.g., to “Done” or “Fixed”) to truly close a ticket.

ServiceNow

  • Business Rules: Check for custom Business Rules that might abort the update (current.setAbortAction(true)) if certain conditions aren’t met.
  • Data Policies: Data policies can enforce field requirements even if the UI doesn’t.

6. Testing Matrix

Before finalizing your configuration, test resolution from each of the following states:

  • New/Open
  • In Progress
  • Waiting for Customer (Critical for Moveworks WIP logic)
  • On Hold/Pending

7. Escalating to Moveworks Support

If diagnostics fail, provide the following to Moveworks Support:

  1. ITSM Ticket ID where the failure occurred.
  2. Approximate Timestamp of the failure.
  3. Screenshot of the Workflow from your ITSM showing the allowed transitions.