Very cool - have been waiting for the term "issue" to be changed for many years. Not sure I love the new term "work item" though!? Don't get me wrong - it is much better, but we customise / store information about Equipment, Documents and other Physical Items meaning "work item" is a little nonsensical too. Maybe just "Item" would have been a better/generic term...but thanks none the less!
This is ridiculous — who in their right mind thinks it's a good idea to change the names of structured fields? Clearly, the person behind this nonsense didn’t stop to consider for even a second how it would impact the development work integrated with the platform. Not only are they wasting time on pointless changes, but they’re also kicking their own clients in the process.
The Key to success is to innovate, and maintain quality in industry standards and where this is not feasible define the new standard !>>>>Not something Atlassian seems to do !
The renaming of "issue" to "work item" has no impact on the operation of the CSV importer.
I used the CSV importer today and everything worked perfectly fine.
I suggest exporting a set of manually created issues and studying the structure, and reading the documentation. For the work item to be imported with a custom work item type (issue type), you need to have a column with cells mentioning the type name and then map it to the "issue type" field during the second importer step.
But I will say that it would be nice if the field "issue type" was renamed as well.
My first question was answered in the FAQs "Will filters and APIs etc still function with the term 'issue'." But I didn't see the answer to my next question "In filters and other places, can I replace the term 'issue' with 'work'?"
Hi @Jamie Echlin _ScriptRunner - The Adaptavist Group_ Thanks for replying to my post. I am referring to the real ISSUES which almost everyone is talking about. The question is why aren't the main features of JIRA working properly. For importing test cases, what is the template that is proposed. Someone commented that one needs to have a column added to the csv file which talks about the Issue Type and it has to have a value of "Test case" or "Test", I am not sure.
Anyway, for me, I used the same import template I have been using. And it resulted in creation of User stories for all those items in csv. Isn't this a HIGH RISK item? If there is a change in step, Please Highlight it.
What about Traceability Matrix- Do I need to even get started on it :)?
See, the thing is, there are so many issues in JIRA for so long (I have highlighted just a few coz I am tired) and the Atlassian team comes up with this cosmetic change.
@Anupam Jha your question is not related to this topic, and it seems that you are trying to import test data, but you don't have the fields created in Jira, or corresponding testing app.
As this is not what this thread is about, I don't think you will see much action for this here. Do you have a topic for this already as a question? Otherwise, I would suggest you create such a question so we can help you with this issue in a more appropriate way.
Once you have created the questions, feel free to ping me, and I'll help you with this, but chances are many others will help you before me :)
We recently started migrating our work items from Azure DevOps to Jira and have noticed that work item types no longer align with how they did during our trial process.
Before, they matched what we expected in terms of hierarchy. Epic -> User Story -> Sub-Task or Epic -> Task -> Sub-Task.
Now it only has the Epic -> Task -> Sub-Task option, and User Stories no longer can have Epic parents nor can they have Sub-Tasks. All our original work items still have the old way, but you can't add more without changing the User Stories to Tasks first.
Is this expected behavior or is this a bug that needs to be reported?
Thanks for sharing this update. I understand the goal of making Jira terminology more inclusive for different teams, and I see how using “work item” can make sense beyond software development. However, I share some of the concerns mentioned here, especially around automation scripts and integrations that heavily rely on the “issue” terminology.
It would be great if Atlassian could provide more detailed migration guidelines or an optional toggle during the rollout to help admins manage this transition smoothly
@Leonel Goitia@Josh Sherwood The roadmap is exactly what I am missing. E.g. @Josh Sherwood has answered to me in post in April 28, 2025 that "updates to these permissions should be made soon", but we still not see them in our instance. (Note: the post is about site Permission, e.g. Default Permission Scheme, has title is "Work items" but permission names and descriptions still have "issues" inside, e.g.: Create Issues: Ability to create issues.)
I worry some parts of Jira would never be transformed.
Thanks for clarifying, @Ondřej Medek . I completely agree with your point about the roadmap.
From my side, while I understand and support the intent behind the terminology change, the lack of a clear migration path is what worries me the most. As you mentioned, permissions and other core parts of Jira still reference “issues,” and without knowing if or when they’ll be updated, it’s challenging for us to plan automation adjustments or ensure consistency across integrations.
Having a documented timeline or at least confirmation of which areas will (or will not) be updated would really help admins like us manage this transition without breaking existing setups.
148 comments