Unable to set Jira Service Desk's Request Type

General Questions
1

I am trying to set the issue Request Type on a Jira Service Desk project.

I am in exalate script, Jira side, incoming script.

I tried all the flavours I know:

issue.customFields."Request Type".value = requestType // the name        issue.customFields."10010".value = requestType // the name
issue.customFields."Request Type".value = requestTypeID // a string with the "ID"
issue.customFields."10010".value = requestTypeID // a string with the "ID"

But I always get an error that tells me that request type has not been found, and lists the available request types.

Fact is, the request type I am assigning, is present in the project’s configuration!

I checked 100 times.

Should I set it differently?

2

Setting the Request Type in Jira Service Management (formerly Service Desk) via Exalate’s scripting can be a bit tricky, because the Request Type field is a special system field and not a regular custom field. Assigning it directly like a normal custom field (e.g., issue.customFields."Request Type".value = ...) won’t work.

Here’s how you should set the Request Type in your incoming sync script on the Jira side:

// Replace 'serviceDeskKey' and 'requestTypeKey' with your actual values
def serviceDeskKey = "YOUR_PROJECT_KEY"
def requestTypeKey = "YOUR_REQUEST_TYPE_KEY" // e.g., "getithelp"

issue.setRequestType(serviceDeskKey, requestTypeKey)
  • serviceDeskKey is your Jira Service Management project key (e.g., “ITSD”).
  • requestTypeKey is the unique key of the request type (not the display name or ID). You can find this key in the URL when editing the request type in Jira, or via the Jira REST API.

Important:

  • The setRequestType method is the supported way to set the request type in Exalate scripts for Jira Service Management.
  • The value you pass as requestTypeKey must match the key (not the name or ID) of the request type as defined in your Jira project.

You can find more details in the Exalate documentation here:
https://docs.exalate.com/docs/setting-the-request-type-in-jira-service-management

If you use the above approach and ensure the keys are correct, you should be able to set the request type without errors.

3

Is there a limit on the number of Request Types that Exalate can map?

Because, strange enough, the number of the "known” request types that Exalate tells me in the error message text is exactly 50, while in the Project’s configurations there are many more.

1 Like
4

Hi @Aldo_Ercolani

Apologies for the late response.

Can you please give update whether you are still facing the issue? We will surely to take this into consideration and try to provide some workaround if its a bug/issue in product.

Thanks,

Sonal

5

Hello @Sonal_Otwani

while we worked our way around the previous issue by moving the Request Type “upper” in Jira’s list, so it fell inside the 50 limit, we are now facing it again.
The thing is: I know exactly the value I need to assign, and I know it’s there, I can see it in Jira project’s configuration. But it’s like Exalate tries to validate this value against the list of available Request Types for the project, and in doing so it considers only the first 50.

So it really seems there’s nothing I can do on my script’s side.

Thanks

6

Hey @Aldo_Ercolani

Please give me a day and will update you for this soon!

Thanks,

Sonal

7

Hey @Sonal_Otwani have you got any news on this for me?

Thanks

8

Hey @Aldo_Ercolani

Apologies for the delayed response!

Yes, there is a known bug where Exalate fetches only the first 50 Request Types. To work around this, we have two options:

  1. Fetch Request Types via API – This requires an advanced script in the incoming sync script on Jira Cloud.

  2. Manual Mapping – Create a mapping between Request Type names and IDs by fetching them via API manually (outside of Exalate).

Please let me know which approach you’d prefer, and I’ll guide you through the implementation.

Regards,

Sonal

9

Hello @Sonal_Otwani

thanks for your answer.

I am not sure I’ve understood your suggestions: I already have a mapping in place and know exactly what is the request type to set, the problem is the validation of this value on Exalate’s back-end.

However, I currently set the request type by setting its name. Are you saying I should set it directly with the Jira’s internal ID?
Can you give me a sample code of how to do that?

Thanks and BR

10

Hello @Aldo_Ercolani

Here are the details:

Setting Request Type on Jira Service Desk Issues (Incoming Sync)

Note: Request Type can only be set at issue creation time. It cannot
be changed on existing issues

Step 1: Find the VP_ORIGIN Custom Field ID

Call the Jira REST API to get all fields:

GET https://<your_instnace>.atlassian.net/rest/api/3/field

In the response, search for the field with “custom”:“com.atlassian.servicedesk:vp-origin”:

{
“id”: “customfield_10010”,
“name”: “Customer Request Type”,
“schema”: {
“custom”: “com.atlassian.servicedesk:vp-origin”,
“customId”: 10010
}
}

Note the customId value (e.g., 10010).

Step 2: Find Request Type IDs

First, find your Service Desk ID:

GET
https://<yourinstance>.atlassian.net/rest/servicedeskapi/servicedesk

Response:
{
“values”: [
{ “id”: “3”, “projectKey”: “ITHD”, “projectName”: “IT Help Desk”
}
]
}

Then, fetch request types for that Service Desk (paginate if more han 50):

GET https://.atlassian.net/rest/servicedeskapi/servicedes
k/3/requesttype?start=0&limit=100

Response:
{
“values”: [
{ “id”: “25”, “name”: “Hardware Request” },
{ “id”: “26”, “name”: “Software Installation” },
{ “id”: “27”, “name”: “Report an Incident” }
]
}

Note the id for each request type you want to map.

Step 3: Incoming Sync Script

// ============================================================
// REQUEST TYPE MAPPING (only applied during issue creation)
// ============================================================
// VP_ORIGIN custom field numeric ID (from Step 1)
def vpOriginCfId = 10010L

// Map source issue type name → Jira Service Desk request type ID
(from Step 2)
def requestTypeMap = [
“Bug”             : “25”,
“Service Request” : “26”,
“Incident”        : “27”
]

// Resolve request type ID from source issue type
def sourceType = replica.type?.name
def requestTypeId = requestTypeMap[sourceType]

if (requestTypeId) {
def vpOrigin = new
com.exalate.basic.domain.hubobject.v1.BasicHubVpOrigin()
vpOrigin.requestTypeId = requestTypeId

  def cfKey = "com.atlassian.servicedesk:vp-origin"               
  def cf = issue.customFields[cfKey]                              
  if (cf != null) {                                               
      cf.value = vpOrigin                                         
  } else {                                                        
      cf = new                                                    

com.exalate.basic.domain.hubobject.v1.BasicHubCustomField()
cf.setId(vpOriginCfId)
cf.setName(cfKey)
cf.setUid(cfKey)
cf.setType(com.exalate.api.domain.hubobject.v1_2.HubCustomFi
eldType.VP_ORIGIN)
cf.setValue(vpOrigin)
issue.customFields[cfKey] = cf
}
}

Customization

  • Fixed request type for all issues: Replace the map logic with a
    single ID:
    def requestTypeId = “25”
  • Map by other fields: You can map by any replica field, e.g.,
    replica.priority?.name, replica.project?.name, etc.

Kindly let me know if this will work or not?

Thanks,

Sonal

11

@Sonal_Otwani THAT WAS AWESOME!

That worked perfectly and I will keep it as a precious secret in my locker.

Very interesting code.

12

Hi @Aldo_Ercolani

Thanks for the confirmation.

Regards,

Sonal