We have the same name of the request type on both the remote site and the local site, but if we change it the sync is does not update the request type field.
Syncing the “Request Type” field between two Jira Cloud Service Management instances can be tricky because the request type is tightly linked to both the issue type and the service desk project. Here’s what you need to know and do:
Outgoing Sync (Source Side):
Make sure your outgoing sync script includes:
This will set the local request type to match the incoming value.
Important Notes:
The request type must exist and be valid for the issue type and service desk project on the destination side.
If the issue type or project doesn’t match, the request type won’t be set.
The custom field name might differ depending on your Jira configuration—double-check the exact field name in your instance.
If It’s Still Not Working:
Confirm that the request type name and issue type are identical and valid on both sides.
Make sure the issue is being created with the correct issue type before setting the request type.
If you’re using Visual Mode, you’ll need to add a Script Rule to set the request type, as it’s not available in the standard field mapping UI. Example:
if (firstSync) {
sd.issue.customFields."Request Type".value = "General Incident"
}
For more details, check out the official documentation:
The Request Type field in Jira Service Management cannot be updated on existing issues. This is a limitation of the Jira Cloud platform itself, not just Exalate. The Request Type can only be set when an issue is first created through the Service Desk API. Jira Cloud does not expose an API to change it afterward.
A workaround is to use the httpClient (but there is no endpoint from atlassian out) or a text field where you store the Request Type.
We do have the need to change the request type from time to time, so we will look into a workaround for this. Perhaps by syncing a custom field called “Remote Request Type” and an automation rule to perform the actual changing of the request type based on that.
Although I am not 100% sure what I am suggesting here would work 100% but it’s still worth a shot.
What Mathieu (my colleague) suggested above is what I think as well, and changing the Request Type after the issue creation is a limitation and the only way out here would be httpClient().
Here’s an example for you which you can try.
if(firstSync){
issue.projectKey = "DEMO"
// Set type name from source issue, if not found set a default
issue.typeName = nodeHelper.getIssueType(replica.type?.name, issue.projectKey)?.name ?: "Task"
issue.summary = replica.summary
store(issue)
}
// We do a store(issue) so the issue.key will be created on the first sync and the request type will be set
// Note that customfield_10010 is the request type field and 33 is the request type id
def url = "/rest/api/3/issue/${issue.key}/"
def data = "{\"fields\": {\"customfield_10010\": \"33\"}}"
httpClient.put(url, data)
We have tested this with a mapping of “remote request type name” to “local request type id”, and this works to both store the request type upon creating the ticket and when updating the request type .
