---
title: 'Troubleshooting: Ticket Resolution'
excerpt: Understanding Moveworks Resolve Ticket State Transitions
deprecated: false
hidden: false
metadata:
  robots: index
---
# 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 State | Source State         | Target State (ITSM) | Transition ID      |
| :------------- | :------------------- | :------------------ | :----------------- |
| WIP            | WAITING_FOR_CUSTOMER | In Progress         | [ID_for_this_path] |
| WIP            | ON_HOLD              | In 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.