Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
Thanks @Kanad Dagaonkar - overall, I am not too phased by this. I am always for simplifications and, more importantly, optimization and performance improvements.
As long as, like you mentioned, things behind the scene does not break, like JQL, automations/flows, etc, I am happy with the summary > title change as well. Luckily for us, we do not use too many add ons but I do see where that can cause some frustration with this.
Atlassian Team members are employees working across the company in a wide variety of roles.
July 16, 2026 edited
Update: We're rolling "Summary" back
Hi everyone — an update, and a genuine thank you.
When we introduced the new create experience, we renamed theSummaryfield toTitle— and this thread was one of the clearest signals that we hadn't got it right. You told us it broke muscle memory, clashed with your docs, training, and customized screens, and didn't line up with the API and JQL (which still usesummary). We read all of it.
So we've started rolling"Summary" backas the field name. It's a gradual rollout, so you'll see the label revert automatically as it reaches your site over the coming weeks — nothing for you to do.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
Hi. Just another slightly off-topic RE App updates like this.
I went to Admin > Apps > Platform experiences > App updates to find this so I can be notified when the change rolls out to us. It was hard to find - but for anyone that is curious, it is called "Create work items faster with a modernized experience"
@Kanad Dagaonkar I would suggest when things like this are updating and posted on the community forum, you share the item under App updates so we can look out for it
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
With the compact view, when we enter the title, the AI-based Similar Work Items suggestions are no longer displayed, whereas they were available in the previous view.
Are the AI-based Similar Work Items suggestions available in the compact view? They help us identify similar issues and avoid creating duplicates.
These new changes are making it much harder and more frustrating to enter tickets. Please provide instructions on how to return to the former (user friendly) view. This change is actually creating more work, more clicks, more frustration. Change for the sake of change is not good customer service.
@Selena Vogel - someone posted previously, the way to turn off/toggle off/disable the GIC feature is:
"Admins can also revert their site to the previous create experience via Settings > System > General Configurations, then set "Simple Create as Default" to off. This applies to the entire site.”
Hope the instructions work. I don't have GIC feature in the instance I support yet so I couldn't test it. But, when the feature is available, it is getting toggled off.
@Kanad Dagaonkar I don't always have time to read the new release notices and was completely unaware that this was happening. I found out from my users that this "feature" 🙄 was turned on automatically.
When users are used to a tool with a certain look and feel, making such changes isn't cool. Atlassian really just needs to send the announcement and let the admins decide where and when, or even if, to turn it on.
@Erin Thompson Those are field descriptions - which is most other views, the new-ish UI (last 5 or so years) of Jira have hidden away so comprehensively that few people see them (even if they would be extremely helpful).
You can see them by viewing the field configurations for the project/space you're creating the call for - then looking up the specific field.
In a perfect world, we'd all see those field descriptions in forms - and be able to use them to say "Please add (this thing we really want you to add to your call) in the description". We DO see the equivalent on JSM request types - where they actually are helpful.
A bit late to see this - but it hasn't landed in my instance yet (sadly, it may do so soon).
But:
This seems like a guarantee that:
* More people will log calls in the wrong Jira space * More people will never change the default work item type for that Jira space * A massive reduction in anyone filling in a non-mandatory field ever again
As far as I can see, there's no indicator to show "you're not seeing all the fields here" so why would people look for more?
This presumes that the people LEAST likely to be Jira experts (especially new or infrequent users), are expected to click things that only Jira experts (those familiar with the Jira environment and knowing what to look for) will click on ("menus" that aren't visibly menus ("space name" and "work item types") and a "show more" button that looks like "maximise" rather than "there's more things here we're not showing" to most people. A lack of field names on the Summary and Description fields aren't ideal either if anyone is providing documentation for this.
* This makes changing spaces an afterthought. * It makes changing work item types an afterthought - and people new to Jira won't notice it. * It presumes that non-mandatory means "don't care" - but many non-mandatory fields are important especially in spaces where "a lot of different things happen" - a field might be really important if you're logging a work item about (a) while worthless if you're logging a call about (b) - but both are logged in the same space in the same work item type.
...
This reminds me of a number of years back when Atlassian reimplemented "Field Descriptions" after removing them (for newer admins - these are like "Display Description" in JSM request type fields - essentially a "permanently on field help" - but for normal Jira projects). Atlassian reenabled the descriptions - but ONLY if you carefully moved your mouse over the field name where a TINY "i" (for information) icon would show which - if you PRECISELY moved your mouse over that tiny icon...you'd see the field description.
So the people who needed these field descriptions the most - were the least likely ever see them. And it's so badly implemented that even people reading this probably don't know it exists :(
Ironically, the old Create experience was one of the few places these field descriptions displayed properly :(
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
@Kanad Dagaonkar our workflow relies on canned responses in the description fields of new work items but with the new UI I don't seem to have a way of getting them to come up, is that something I need to change in the settings or do you have a suggestion on how to manage this in the future?
Our visually impaired team members, as well as the less tech-savvy ones, are really struggling with this change. They are unable to find the space and work item dropdowns, assuming they're just stuck creating things right then and there. Nothing has the "editable" look, it just looks like a text wall (even if you CAN see just fine). This is a really poorly through out change. It's actually wild that you have some black box magic set up to GUESS which fields are most relevant - and now we have to change hundreds of screens in our environment and re-train hundreds of users (who are still adjusting to migrating in the first place)?
I would be very interested in seeing your testing paradigms and customer feedback. The lack of transparency involved in rolling this out, too - there was no notification to our admins that this was coming and we were absolutely blindsided.
It doesn't really matter to the user that this loads 35% faster when the data-entry experience is terrible. This version of the form takes me longer to complete every single ticket.
I've sent most of these in-app and nothing has improved. I have no idea why this was a priority out of all of the things that Atlassian could have worked on. Speed improvements on bulk edit might have been nice?
ISSUES
Modal Title
Come on. This is basic UX. Are you going to take the title out of the "Rovo" dialog as well when it's floating? Also, why are the Rovo and Create docked mini-modals different sizes? Messy.
Project Space/Issue Type selectors
I'm losing more than 35% of create form loading time by having to MOVE issues after I create them. You've made the dropdowns so innocuous that I completely miss them every time. I'm constantly switching between bug and story tickets. You CANNOT have a setting to default to the last-used type without making it obvious to the user that you have selected something for them? It's REALLY terrible UX.
Summary/Description Inputs
When you use read-only styling for inputs with grey text... it looks like there are no inputs. When the new version of the form opened for the first time I had no idea what was happening, or how to do data-entry. I had to click in several places before I figured out where I could actually do data-entry.
Also, why is there a giant blank space below the description input placeholder text if it's just blank space? Minimum, it should be part of the <textarea> so that clicking it activates the input. It's actually a BUG right now because double-clicking it selects the Summary text.
Speaking of which, you know what's really confusing? When that summary text is selected from the double-click but I can't edit it because you made the input... not an input all of the time.
Hover Styling
Why do Summary and Description not have hover shading like the other inputs?! Why would these EVER be custom editor components that you would even need to remember to style them the same? They have different fills, different cursors for THE SAME BEHAVIOR.
Also, why does the Attachment input not have hover styling like the other inputs? A cursor change indicates the TYPE of interaction that can take place, but it is secondary. It ALWAYS needs to be paired with another more obvious styling change.
Rich Text Toolbar
I hated the floating toolbar when Microsoft introduced it in Office 2007 and I still hate it here. Also, they are extremely buggy in this form:
you can have multiple open at the same time for different fields (I'm up to three)
the are anchored to the body, not the inputs so you can scroll away and they are still there (all three)
they modify the text even when the input isn't active, which is really really weird paired with your view/edit per input paradigm.
clicking on the modal chrome DOESN'T DISMISS THE **** THINGS. I literally can't get rid of some of them.
Tabbing
Have you TRIED to tab through this form and do data-entry? This is a input-first experience and that should be the top priority of ANY user story applied to this screen. I was an accountant for over a decade, and am currently working on accounting software and data-entry UX is KING. Overall performance always takes a backseat because it's much more frustrating to experience front-end issues in the form. Please find some feedback group users who have done data-entry in data-entry (not workflow) products.
---
IN SUMMARY
This feels like a engineering-led initiative for performance, vs a persona/user story driven experience. Many organizations deal with that problem, but I wasn't expecting it from Atlassian.
Major blocker: discoverability of space/issue type inputs
Major blocker: keyboard navigation data-entry experience
At least 7 bugs
Numerous other UX issues.
Please turn this off until it's cleaned up. It needs much broader feedback and testing than you gave it.
Admins can also revert their site to the previous create experience via Settings > System > General Configurations, then set "Simple Create as Default" to off. This applies to the entire site.
Good catch, Ankit — and you're right that Similar Work Items is a useful guard against duplicates. It is not surfaced in the compact view yet. We're reworking the detection logic to make the suggestions more accurate, and we'll bring them back into the new Create shortly.
@Selena Vogel Thanks Selena, and sorry this has made your day harder — that's the opposite of the intent. The switch is a site-level setting, so you'd need your Jira admin to turn it off: Settings > System > General Configurations > "Simple Create as Default" > off (this reverts the whole site). If it's specific clicks/steps that got slower, I'd genuinely like the detail — that's what we're fixing.
Thanks Erin — and thanks Scott for jumping in. That text is a migrated field description carried over from your legacy config. We're rolling out a change to clean up this migrated text, and it should reach your site soon. If the duplicate persists after that, let us know.
Thanks Marta — canned responses in the description are a workflow we don't want to break. To point you the right way: are these Jira description templates configured per issue type, or some other text expander? If it's the former, they should still apply and I'd like to debug why they aren't — the fastest path is a support ticket so we can look at your specific config, and I'll keep an eye out for it.
On field selection: it isn't a guess. The required and optional sections follow the exact field order your admins set in the space configuration. Two refinements apply: the Reporter field is not shown in quick create and fields users rarely interact with move under "Show more fields" for fullform layout Nothing is hidden permanently
On changing screens and re-training. The new form is a view over your existing configuration — no fields are removed, and your screens and field configs are unchanged. Anything not shown by default is still there under the Full form layout, in the order you set.
After the initial experience, our users asked us to revert to the old GUI for Create Issue.
Here is a summary of the initial feedback we received -
it's not obvious that the ticket type can be selected / changed in the form - that was more explicit with the old one (I now multiple times only saw later that I didn't select the proper type), and
the summary field is not clearly separated from the description. If there was at least some "visual border" between the two, it'd be easier to select one of the two (it feels like one has to be very exact before selecting one).
no formatting buttons for the description, this is needed (not knowing all the markdown tricks)
missing frames around fields to guide the eyes
reduced width of the create screen - I have always hoped for a wider create window as log extracts and other elements benefit from wider screen from an Engineering perspective.
clumsy and close together fields created a confusing and brittle impression, no breathing and joy of use
the title and the first headline being squashed together in the ticket was irritating. If you made the first line H1, it looked as if it was one long sentence.
@Kanad Dagaonkar there hasn't been a response to several of the issues that have been repeated in this thread
the space/issue selectors being undiscoverable
that inputs don't look inputs
that the Summary/Description in particular are troublesome
the rich text toolbars are hidden
What's the plan for these problems? At a minimum, a quick fix would be to add dropdown arrows to the space/issue selectors. That should be a no-brainer at this point, at least until a better UX/layout is figured out. Turns out that traditional UI has reasons for existing...
@Kanad Dagaonkar - the new view over the existing configuration is not working for my company's setup. Important fields are hidden from view and the expand button does not work - it sometimes appears for a flash and then disappears.
We don't enforce every important field as required because they're not required on every single ticket of that type. Because the expand button disappears (as numerous others have reported), nobody can access the Full form layout to enter important (but not required) fields, to actually enter that data in (unless I outright disable it in global settings as others have pointed out). Alternatively, I can edit hundreds of screens to somehow work with this logic - which I assume I'll have to do once you get rid of the global setting anyway.
It's seriously thrown off our migration plan and our end users are frankly terrified of all of these changes, and upset with me for being unable to "fix" it.
There was no acknowledgement of the accessibility issues, so I am mentioning it again in case it got lost in the other details.
Atlassian Team members are employees working across the company in a wide variety of roles.
August 5, 2026 edited
@SA : We'd love to dig into this with you directly. Rather than going back and forth in the comments, would you be open to a quick 30-minute call? It'll let us see the issue in your environment firsthand, understand the steps that trigger it, and get it in front of the right people on our team to fix.
50 comments