Suggested workaround to move around this error:

Cannot add value [ [xxxxxx)] ] to CustomField Request Type in Issue with summary 'xxxxxxx'. Probably value was in incorrect format  

On your CSV, you need to replace the name of the request type with the value from the request_type_key column.

To correctly specify the "request type" in your CSV file, you need to use the request type ID instead of the request type name.

• Navigate to Your Project:

• • Go to your Jira Service Management project.
  • Click on Project Settings.

• Access Request Types:

• • Within the project settings, select Request types.
• Identify the Request Type ID:
  • Click on the specific request type you need (e.g., "Epic (EPIC)" or "Story (STORY)").
  • Look at the URL in your browser's address bar. The number at the end of the URL is the request type ID you need to use in your CSV file.
    For example, if the URL is:

    https://test-support.atlassian.net/jira/servicedesk/projects/FOERD/settings/request-types/request-type/30/request-form 

    The request type ID is 30.

Hi, I'm Christian on the JSD team owning this component.

After having a close look at what the best way forward is, we've decided to create a suggestion for an XML issue import and close this bug. The reason is that we can't support both human-readable and machine-readable output using a limited format like CSV.

In particular, we can't fix the problem raised in this bug report without breaking https://jira.atlassian.com/browse/JSDCLOUD-4520. This bug has more affected customers, but I would prefer a solution where don't need to choose which use-case to support.

Support for a more powerful format for issue import, like XML, is the only way to ensure machine-readability in all circumstances. There are multiple related issues called out in our suggestion that are not realistic to support from CSV. See the list here: https://jira.atlassian.com/browse/JRACLOUD-74852.

Please vote for, and watch, the suggestion to ensure it being addressed with urgency.

Thanks for understanding,

Christian

Hi Folks!

As a part of our efforts to make sure that our bug reports have as much useful information in them as they can, I've gone through and reverified this issue, updated the issue description to make it a bit clearer. Please contact Atlassian support to apply the workaround for you.

Cheers,

Asim
Atlassian Support

Jira Cloud CSV export doesn't export the internal customer request type anymore. So, the only way is to ask support (

simple solution: provide the admins an export req type feature so he can at any time export the technical ID for further use... simple and quick solution... for a ticket that is open since 4.5 years...!

Hello Bridy,

thank you for your quick reply. Unfortunately, the field "Customer Request Type" does not appear in our bulk update page. Maybe it is because we use Jira Cloud...

BUT: In the meantime I found another solution. There is actually an internal ID for the Request type, that you can import via csv. If you export an issue where the request type is set, (e.g. CSV "export all fields"), the field Custom Field (Request Type) is included and it contains the internal Request Type ID 

In our case, e.g. "service/b7e54c65-4371-49a2-a83b-dad055038902"

Regards,

Jennifer 

Hi Jennifer,

From the Bulk Update page, you'll update the field called "Customer Request Type."  In our case, we had a 1:1 mapping between issue type and customer request type, so I was able to filter for each issue type and set the matching customer request type.  If you have a many:1 mapping, you'll want to import something else to search on (label, for example), so you know which issues to set to each request type.

Bridy

Hello Bridy, how did you bullk update the issues after the migration? 

The query in the workaround only supplied 4 request types on 2 sandbox projects and nothing from the main JSD project.  I tried using the same string format (<portal key/request type key>), but the values still weren't set during a CSV import (migration from Zendesk).  Thankfully I can bulk update the records after the migration is complete.

just kidding, apparently not