nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Introducing the new, streamlined Create experience in Jira

Kanad Dagaonkar

Hi Jira Community,

We're updating how work items are created in Jira Cloud through the Global Issue Create button and wanted to give you a heads up on what’s changing.

Why this change?

Today, creating a work item from Jira Cloud’s top navigation Global Issue Create (GIC) button opens the large full form create screen. Over time, this screen has accumulated many fields – and today, the default form shows far more than what most users need for creating a typical work item. This leads to unnecessary friction: slower load times, a steeper learning curve for new users, and a flow that feels heavyweight even for simple tasks creation.

Instead, we wanted to design an experience that is easier to start with, and just as powerful when you need it.

What's changing?

We’re introducing a faster, redesigned create experience that gives you a focused quick-create flow by default, while keeping the full form available whenever you need it.

Before	After

Here’s what’s new and different:

Window and Layout Control

The new modal supports two main modes - a compact Quick Create mode and a Full Form mode

Quick Create form by default: The create dialog now opens as a focused modal showing the most essential fields – instead of the full list upfront.

Quick form mode

Full form is still available: You can expand to the full form anytime by clicking on the expand icon.

Quick to Full Form.gif — *Full form mode*

Additionally, you can also dock the create modal to the bottom-right of your screen (similar to the old GIC). Docked mode lets you continue working on other tasks and return to finish creating your work item whenever you're ready – without losing your context or interrupting your flow.

Info

While the Quick Create is the default mode for simpler work items, you will see the Full Form load automatically if your work item has more complex requirements - tabs, more than three required fields, custom create screens (CMP spaces), Forge UI app modifications, or a complex field type such as rich text.

Main Input Area

Description field is responsive : Expands vertically to accommodate long descriptions, code blocks, table edits, and pasted images.

Exhibit | Responsiveness of create dialog with long code block

Description field supports slash commands: Continue to use / in the Description field to insert elements or invoke Rovo. A formatting toolbar appears when text is selected

Exhibit | Use `/` to invoke Rovo Exhibit | Demonstrating Formatting toolbar and More elements in `/`

Field Chips

Required and optional fields are separated: Required fields appear first on the quick create form. Optional fields appear beside them. When there aren’t any required fields, the quick create modal shows only the optional fields.
The order of fields in the required and optional sections matches the order set by admins in the space setting - with two refinements: fields that always have a system default (such as Reporter) and fields that a user rarely interacts with are excluded from the default view, keeping the form focused. These fields remain accessible via "Show more fields."

What does this mean for you?

A faster create experience

A compact form allows us to load the create screen faster for you. In our internal testing, we have seen ~35% reduction in loading times.
The quick create form allows for more focussed work item creation. No fields are being removed. The full set of fields remains available – they're just not shown upfront by default

Field visibility customization as a Jira user

You can customize which specific optional fields appear — select More actions (•••), then Configure Fields, then choose Custom fields from the dropdown to pick the fields you want. Unchecked fields will be hidden from both the quick create and full form.

You can also make Full Form your default. Select More actions (•••) while in full form mode, then toggle on “Always open in this view”. No admin action needed.

If you're an admin

You can control which fields your team sees by default in Quick Create via Space Settings.

Select Space Setting.jpeg

Select Space Setting

For team-managed spaces,
1. Once inside Space Setting, select Work types.
2. Select the work type you want to configure.
3. Reorder the fields to control what your team sees in Quick Create. The Quick Create form always shows Summary, Description and upto 3 required fields – those are fixed. Beyond those, it picks the top optional fields based on the ranking below. For instance, if you want your team to see Team and Due Date in Quick Create, drag those to the top of the field list.

For company-managed spaces
- Once inside Space Setting, select the Screen corresponding to create issue and the targeted work type. Based on your configuration, you may find either (A) a single screen across create/edit/view issue operations or (B) a custom screen for create operations.
  
  (A) single screen for all operations (B) custom screen for create operation
- CASE A : Reorder the fields to control what your team sees in Quick Create.
- CASE B : Having a custom create screen always opens the Full Form by default.

Note: 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.

Simple create as default.jpeg

Note

With this change, other entry points in Jira that previously opened the older create form will now open the new modal – including inline creation in Board, Timeline, and Roadmap views (where the new modal appears when required fields need to be completed), and creating child items within a work item.
The new changes do not apply yet to Jira Service Management (JSM) and Jira Product Discovery (JPD).

When is this rolling out?

This update will roll out progressively to all Jira Cloud customers starting mid-July with the summer Jira release.

Questions or feedback?

If you have questions about this change or run into anything unexpected, please share in the comments below. We'll do our best to respond and take your feedback into account.

Thank you!

Edit (July 2026): We've updated this post to reflect a change in the final release. The new create modal uses "Summary" as the field label — an earlier version of this post mentioned that the field would be relabelled "Title" in the UI. That change did not make it into the release. JQL queries, API calls, and integrations referencing summary continue to work as before, as they always have.

Comments

Dave Mathijs

Thanks @Kanad Dagaonkar Today, I learned a new acronym: The Global Issue Create (GIC) button. 💡

Are there any future plans on the roadmap to expand this to JSM and JPD?

Julia Foden

Hi @Kanad Dagaonkar

Well I'm glad to see there is finally a Community post about this, but it has actually been rolling out since at least May. I gave my strongly negative views on it here and the Release Note says that it started rolling out in April!

The most important thing for everyone to know is that as admins we can switch it off entirely, as you said:

Note: 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.

My feedback:

I'm glad to see that it now names the space and work item type rather than relying on icons
Renaming Summary as Title is madness. What do you hope to achieve by this? Increasing speed is a valid reason for some of the changes (even though I don't like them), but I can't think of any valid reason for giving the Summary field a different name in the Create screen! I am forever telling people to take note of exact field names for the purpose of searching, reporting, dashboards etc. The Issue Navigator (JQL) uses Summary. It does not recognise Title. The field name is Summary - please change it back. And what about sites who have a custom field called Title?

Lorenzzi Bassoto

I keep thinking about the impact these changes could have on ScriptRunner Behaviours that affect the create screen. It could definitely get messy.

Cornelia Jeppsson

I read "Up to 3 required fields" - if there are more required fields than that, then those will not show in the quick create screen? How will that experience be for users?

Itamar Ben Sinai

To top the previous questions.

How will it work with fields set to required in workflows?
Why do the required fields have no required indication to separate them from the non-required?
What didn't you improve in the Create screen, and stop the endless scrolling down in case there are many fields (some Jira users love many fields), and take the initiative to improve the Xretae screen layout?

Thanks

Apryl Harris

@Kanad Dagaonkar

If an organization is using Bundled Releases, will this feature be included in a bundled release or should the org just expect it to "show up" in their PROD environment one day?

Atlassian CoreIT

Only 1 question: WHY?

Darryl Lee

Hrm, I don't think we'll get too many answers today from @Kanad Dagaonkar as it's almost 10:30PM their time.

@Cornelia Jeppsson - @Dave Meyer answered your question about > 3 required fields in... a LinkedIn comment(?!) in a response to @Matt Doar

Matt Doar we automatically expand to show the full work item create form in this case. And it’s always available by clicking the expand button in the top right corner of this view.

The fields available in this view will always prioritize required fields, and if there are fewer than 3 required fields, we intelligently show the 3 fields we believe are most likely to be filled. We also check for “field reauired” workfow validators in addition to the field config.

We are currently testing this experience in limited cohorts.

Hrm, not that limited anymore I guess. :-/

(h/t to @Alex Ortiz for finding this new feature and posting about it.)

Ross Angelov

I am glad that according to the article there will be a way to disable this feature:

Note: 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.”

We have Forge apps that integrate with the Create issue screen, where we have default and custom fields that are populated by the apps.

Would this change interfere with such custom implementations?

Kanad Dagaonkar

@Dave Mathijs : Thanks, for the interest shown! JSM/JPD are not part of this rollout; we’ll share updates separately as soon as timelines firm up.

Kanad Dagaonkar

Thanks @Julia Foden, this is helpful feedback.

On Summary appearing as Title: this is a Create-screen label change only. JQL, APIs, dashboards, and integrations still use summary. In our end-user research, users found “Title” clearer at create time, so we made that tradeoff intentionally.

A few of your other points are already addressed live:

The space icon is accompanied with the space key, work type shows the full name;
Users who prefer the full form can set it to always open by default.
The Description field uses placeholder text and slash commands rather than a persistent label.

Appreciate the early feedback.

Kanad Dagaonkar

@Ross Angelov and @Lorenzzi Bassoto : Forge/custom create extensions: Full Form opens by default when Forge UI modifications are present. Please let us know if you still run into problems and we would take care of it!

Kanad Dagaonkar

@Cornelia Jeppsson : The Full Form load automatically if your work item has more than three required fields

Thanks @Darryl Lee for covering up

Kanad Dagaonkar

@Itamar Ben Sinai : Please find my comments -

We are pre-fetching the fields that are marked required from field validator in create workflow and showing them in Required field section upfront
There is a "Required" label and a vertical separator between Required and Optional fields in Quick Create. In Full form mode, there is an asterisk (*) on every required field.
No fields are lost in the Full Form layout. It has been designed to reduce the scrolling

Kanad Dagaonkar

@Apryl Harris : This will be part of Bundled Release

Atlassian CoreIT

It's a shame that you don't let users name their summary whatever they want. I fill in the title, I search for the summary, no it's not confusing for users at all.

Susan Hauth _Jira Queen_

Why? Stop messing with the UI and Field names every single release! As an admin, I have to now worry about people not finding "Summary" OR they can't see all the fields on create.

Thankfully you put in a TURN OFF option for this one and you should run some stats to see just how many people don't want this feature.

Go look at JAC and fix some of the issues/items in there. There are literally NO request for changing summary to title, or messing with the create screen. In fact there are literally NO requests for messing with the UI. Just STOP and put out something useful instead of this constant stream of moving things around and renaming them. We don't want them!!!

Rick Westbrock

While I have not seen this in action yet I have to wonder why Atlassian thought they needed to force this on users because screens are already customizable so if a space's create screen is too heavy with fields then the screen can be streamlined by the customer to remove fields.

Mark Baird

In the new create view, when you click the "Show more" button, a new "..." button appears with the tooltip label "More Options". When you click that one of the options you have available is to "Always open in this view" with a toggle interface. When clicking that to try to enable the toggle, so that the create view always opens in the "show more" state, the menu just closes and the toggle is never enabled.

I wouldn't mind this change so much if I could just get it to always open with all the fields visible. We have quite a few required fields and opening the create view with most of those fields hidden now just means I have to take one more action to show all those fields before I can actually enter a ticket.

You shouldn't have rolled this out to people with the "Always open in this view" option broken like this.

Josh

@Kanad Dagaonkar - With all the focus on the UI over the past year or so (including some notable rollbacks to customer revolts caused by the "improvements"), I'm disappointed to see that there wasn't any effort to provide admins with the ability to change how the GIC button (probably should update it to "GWIC" btw for consistency) works for Jira Service Management spaces.

The GIC is atrocious for JSM spaces; it allows the JSM portal to be bypassed and agents to pick the wrong request types, forms, etc. I would have love to see the effort spent on this change instead be spent fixing the JSM GIC experience to direct people to the JSM portal forms. The same is true for any Jira app / connector for things like MS Teams where users are presented with the agent creation screen instead of the JSM help center.

Most of the Jira feature updates have been pretty decent of late, but the larger UI changes have been questionable at best. Atlassian is feeling more and more disconnected from how users actually use the UI to get work done. Either that or they are prepared to completely infuriate all existing customers that have led to their continued success just so they can chase the next group of customers to increase their stock price.

Josh

One extra rant for good measure...

Many Jira users also use a combination of JSM or JPD. To make life easier for them and admins alike - please, please, please stop fragmenting the UI between products that have "Jira" in the name. I know different teams work on the products, but maybe there should be some UI / UX people that sit above the three teams and advocate for consistent user experiences. Otherwise, consider dropping "Jira" from the name of these products - they look and work less alike every day.

You don't have to take my word for it - @Wurm Peter has some excellent articles on the topic:

Daryl Lee [for some reason I can't @mention his correct account atm] also continues to call out the ill-advised UI changes with cold, hard facts.

These voices will only get louder until the Jira product teams take a cold hard look in the mirror and see what a bad decision splitting up the Jira suite team was for the long-term success of the product...

Rune Rasmussen

The Create Work Item Modal has felt old fashioned for quite a while, so I'm all for sprucing it up.
But will also point out that faster is not necessarily better. It's just faster.

The Summary/Title idea strikes me as a very poor decision.
I can totally see how if you asked someone who had never worked in Jira before that Title would be easier to understand than Summary, and if you were building the tool from the ground up calling it Title could make sense.
But fragmenting your terminology in an existing and well established system won't be doing anyone any favours. Except for maybe your competitors when new teams/customers has to deal with the inconsistent nonsense of the same field not having the same name everywhere.

Rich text fields causing the create model to expand strikes me as odd since the Description field is also a rich text field.
It would also be great if the formatting bar was permanently shown, rather than having to be summoned.
Jeeves, fetch me my Formatting Bar™ post haste.
From the last year or twos worth of UI changes, I understand that Atlassian is actively developing for 800x600 13" monitors, but the rest of us have moved on to at least 1920x1080, and anything smaller than 24" will make you the joke of the day.
We've got enough spare room for the formatting bar to be permanently affixed.
Alternatively it could be a user-level-toggle.

When you say that Custom Create Screens will expand the create modal, do you mean if the Create operation has a different Screen than Edit and View, or is it any Screen that we have created ourselves?

Beyond all that, you guys already have a very good solution in the Proforma Forms in JSM. It has conditional magic and everything. It's pretty great. Why that wasn't the tool of choice for improving the Create Modal is beyond me.

Kanad Dagaonkar

Hi @Mark Baird

Thank you for the detailed write-up, and genuinely sorry for the frustration. You're right, and it's a fair callout: the "Always open in this view" toggle wasn't persisting your preference, which is exactly the kind of thing that shouldn't slip through — especially when it means clicking through to your required fields on every create. That's a real daily annoyance and I don't want to downplay it.

The good news: we've identified the cause and shipped a fix. The toggle should now save your preference and hold it across sessions. You may need to refresh (or give it a short while to roll out to your site) — if it's still not sticking for you after that, please reply here and I'll chase it down directly.

Really appreciate you taking the time to lay out the exact steps — that repro is what let us pin it down quickly. 🙏

Kanad Dagaonkar

When you say that Custom Create Screens will expand the create modal, do you mean if the Create operation has a different Screen than Edit and View, or is it any Screen that we have created ourselves?

Hi @Rune Rasmussen — good question, and there's one subtlety worth making explicit, because I think it's the bit you're circling.

What triggers the full form by default is the screen mapped to the Create operation specifically — not whether you have custom screens in general. So:

If the screen handling Create for that issue type is a custom screen, Create opens in the full form with the configured fields — and it doesn't matter whether that screen is one of Jira's system-built ones or one your admin created.
If you've built custom screens but they're only assigned to Edit/View, and Create still points at the default screen, that create flow will use the streamlined view.

So it's not conditional on Create being different from Edit/View either — it's simply: is the Create operation backed by a custom screen? If yes, full form. Hope this answers 🙂

Hrafnhildur Olga Hjaltadóttir_p6xmg8

The expand option does not work and does not even show up. This is horrible for me since I need to be able to put in images and information bubbles when I creat the tickets due to our workflow.

Why has this change been forced and how do we change the admin settings so we can expand to have the old version again?

Currently I have to create the issue blank and then go in and modify it which does NOT save time and in fact makes my job harder

Yatish Madhav

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.

Let see as this rolls out to us...

Thanks again
Yatish

Filip Klouček

Yes. But why? Thanks for adding more problems. Thanks god for Settings > System > General Configurations, "Simple Create as Default" to off.

Kanad Dagaonkar

Update: We're rolling "Summary" back

Hi everyone — an update, and a genuine thank you.

When we introduced the new create experience, we renamed the Summary field to Title — 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 use summary). We read all of it.

So we've started rolling "Summary" back as 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.

Thanks for speaking up!

Yatish Madhav

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

Thank you
Yatish

Apryl Harris

Thanks for the rollback to "Summary", Atlassian. But I'll keep this feature toggled off when it gets to the instance I represent.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

issue-create

create