Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Request type is not recognized during csv import

Hi, I have multiple issues during CSV import :

+ Ticket request type value is not recognized and produce an error :

Cannot add value [ [Technical support] ] to CustomField Request Type in Issue 

Technical support request type is exact name of the value exported in CSV file from Jira.

+ Tickets are imported as Status = Closed + Resolution = Done + Resolved date in the past, but SLA are calculated based on import date, why?

Thanks for help. I have 14 customers to migrate and a bit afraid right now :( SLA calculation is needed for global reporting.

3 answers

I found it slightly odd that the requestType was a custom field, but anyways, I was able to solve this by going to the request type config page, clicking into the edit view of the request type, and getting the ID of the object from the URL path. Then in the csv for importing, I just set the ID for the corresponding request type. Just the integer, no strings. And amazingly it worked as expected. hope this helps someone!

Thanks a lot! That worked well for me

easy one and worked great!

Just as an update -- 
Context - we have 20 CRT and we migrated a help desk from JIRA Server to JIRA Data Center and this is what worked for us. 

There is some manual work here but having the CRT information was imperative to the migration, if they didn't have that then we couldn't migrate. 

We used Scriptrunner to run this script in the console for where the new project would be - 
import com.onresolve.scriptrunner.db.DatabaseUtil
DatabaseUtil.withSql('Jira DB Connection') { sql ->
sql.rows("""SELECT p.pname, r."NAME" as request_type_name , (po."KEY" || '/' || r."KEY") AS request_type_key
FROM "AO_54307E_VIEWPORT" po, "AO_54307E_VIEWPORTFORM" r, project p
ORDER BY p.pname""")

It output all of the request type IDs for us for the new project not the source project, I then did a page search for the project that I needed the IDs for and then I matched them up with the CRT names and using Excel used a relational vlookup table to match the field values in the csv file and then imported using "external import" and we were good to go. 

The CRT ID would replace the CRT field in your CSV file -- the format would be 
example: arlhelp/92370ba6-f16a-4459-a289-58d77940f56r

This is the JSD Server ticket that helped the most -  


You're looking for values request_type_key (from Scriptrunner output) or data-key (from XML file)

The CRT ID would replace the CRT field in your CSV file -- the format would be 
example: arlhelp/92370ba6-f16a-4459-a289-58d77940f56r

1 vote
Patricia Francezi
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 05, 2020


If you are migrating from Server to Cloud, You will need to map the old Request Type ID to the new one in cloud, and convert your CSV. 

From the SLA, bulk import is like creating new issues, so the SLA starts from the creation.

If you are running a brand new cloud instance, I would suggest to use the backup import feature in cloud. 

You can backup from server, donwload a XML and import in your instance.

Check your server instance to verify if the docs are correct for you. 

Check also this doc:


Be aware that you need to understand carefully the steps. 


If my answer provided clarity for you, I would ask to accept it :)

Thanks for reply :-)


That doesn't clarify me yet, I explain.

Concerning Request type, csv export has been done from cloud, and I'm trying to import this csv, considering some other fields values. Request type should be imported like it has been exported.


Concerning my SLA issue, I don't use bulk import, but CSV import, that's 2 different things. Bulk use import date as creation yes, but CSV use created date from csv issue lines. That's necessary cause my tickets have been created and solved some months ago.


I saw on forums that's there is an issue with SLA count from CSV import, it doesn't stop cause not triggered by import action (resolution changes, resolved date... ) I'm looking for a workaround in order to have correct SLA calculation = resolved date - created date. For reporting purpose.

Hi @Vincent Naudion  did you ever managed to import your request type properly? 


Best Regards,


Used a bulk change of all imported issues to change the requestType to the new value...

I'm having this same problem and I cannot use the work around like Christian mentioned because I have several different request types I need to import. Why is this failing when the request type in my csv matches exactly how I would search for it using JQL --- as in it has the request type name plus the project key in parenthesis and it's still not working and getting same issue as Christian originally reported. 

Hi Jamie,

maybe you can import each request type on it‘s own, bulk change the type afterwards and then do the next one...pretty annoying but the only option I see.



Good point. Looks like this will be my Sunday Funday :) Thanks Christian. Hopefully Atlassian can get this fixed soon. 

Suggest an answer

Log in or Sign up to answer
Site Admin
AUG Leaders

Atlassian Community Events