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:

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.
4. API Response: If available, the raw error message from the TicketGatewayService logs.