Issue when moving data from a Select List (single choice) Field in Jira to a Pick List field on Azure DevOps “ADO'“. the values being passed match on both systems

General Questions
,
1

Hi, we are having an issue when moving data from a Select List (single choice) Field in Jira to a Pick List field on Azure DevOps “ADO’“. the values being passed match on both systems.

ADO Incoming:
// ==============================
// Work Type (Jira select single text) → ADO Custom.WorkType
// ==============================
def workTypeVal = replica.properties?.get(‘workType’) as String
if (workTypeVal?.trim()) {
workItem.“Custom.WorkType” = workTypeVal.trim()
}
**
Exalate** Error:
Error Type:
Issue Tracker Error
Error Creation Time:
Nov 05, 2025 22:06:55
Error Detail Message:
Bad response when Updating work item - 400 - response body: The field ‘Work Type’ contains the value ‘BasicHubOption{id=‘76714’, value=Unplanned - Support, sequence=‘7’, disabled=‘false’}’ that is not in the list of supported values
com.exalate.api.exception.IssueTrackerException: Bad response when Updating work item - 400 - response body: The field ‘Work Type’ contains the value ‘BasicHubOption{id=‘76714’, value=Unplanned - Support, sequence=‘7’, disabled=‘false’}’ that is not in the list of supported values at azurenode.services.node.client.AzureClient.filterResponse(AzureClient.scala:815) at azurenode.services.node.client.AzureClient.$anonfun$updateWorkItem$4(AzureClient.scala:466) at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:470) at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:63) at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:100) at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18) at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:94) at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:100) at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:49) at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:48) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

2

The error you’re seeing—The field ‘Work Type’ contains the value ‘BasicHubOption{id=‘76714’, value=Unplanned - Support, ...}’ that is not in the list of supported values—suggests that the value being sent from Jira to Azure DevOps (ADO) isn’t in the format ADO expects for its pick list field.

Here’s what’s happening:

  • Jira’s Select List (single choice) field sends an object (an “Option”), not just a plain string.
  • ADO’s pick list expects a string value that exactly matches one of its allowed options.

In your script, you’re using:

def workTypeVal = replica.properties?.get('workType') as String
if (workTypeVal?.trim()) {
  workItem."Custom.WorkType" = workTypeVal.trim()
}

But if replica.properties?.get('workType') is still an object (like BasicHubOption{...}), ADO will reject it.

How to fix:
You need to extract just the string value from the Jira option. According to the documentation, you should use .value to get the string:

def workTypeVal = replica.properties?.get('workType')?.value
if (workTypeVal?.trim()) {
  workItem."Custom.WorkType" = workTypeVal.trim()
}

This ensures only the string (e.g., "Unplanned - Support") is sent to ADO.

If you need to map values between systems (in case the option names differ), you can use a mapping dictionary as shown in the docs:

def workTypeMap = ["JiraOption1": "ADOOption1", "JiraOption2": "ADOOption2"]
def workTypeVal = replica.properties?.get('workType')?.value
workItem."Custom.WorkType" = workTypeMap[workTypeVal] ?: workTypeVal

For more details, check the official documentation on syncing custom fields with options:

This adjustment should resolve the 400 error and ensure the value matches what ADO expects.

3

Hi @Honduras74 ,

Wondering if the AIDA response here solved the problem for you?

Thanks
Majid