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; } } }

New field in Jira's July release: Atlassian Project - what you need to know

Shilpa Airi

Update from the Jira team [30th June 2026]

Thank you all for the detailed feedback on this thread. We've heard you clearly. We are making changes to the rollout plan:

The Atlassian Project field will no longer be added to screens by default. Teams that don't use Atlassian Projects won't see it on their screens.
However, the field remains available for anyone who wants to use it;
Customers who already use Atlassian Projects will not be disrupted; they can continue using Atlassian Projects. The admins can still remove it themselves or reach out to support.

We appreciate you taking the time to share feedback, which has shaped this decision. We are rolling out this change over the next few days.

Thanks,

The Jira Team

----------------------------------------------------------------------------------------

Hi everyone! I’m Shilpa from the Jira team, and I’m excited to share an upcoming update that brings Atlassian Projects and Jira closer together.

We’re rolling out a native Atlassian Projects integration in Jira (planned for the Jira Summer release in July), making it easier for teams to associate Jira work items with Atlassian Projects directly in Jira.

If you have used the Atlas Project linking experience in Jira before, you’ll notice we will now have a much more natively integrated experience.

What’s new?

A new Atlassian Project field will be available in Jira
The field will be added to screens by default
Users will be able to link work items to Atlassian Projects more easily on work items and Jira views
Teams will be able to group and filter by Atlassian Project in more Jira views
Projects in the Projects app will show linked Jira work more clearly

What does this mean for admins?

Admins will already notice a new field in Jira settings → Work items → Fields → Atlassian Project. This field will also be added to screens by default, so it may become visible to teams as the rollout reaches your site.

If you’re not ready to use it right away, you can remove it from screens for company-managed projects by updating the field’s screen associations. That gives you control over where it appears without needing to fully disable the feature.

Go to Jira settings → Work items → Fields
Open Atlassian Project
Select Add field to screen
Unselect the screens where you don't want it shown
Click Update

What does this mean for users?

Users will be able to connect work items to Atlassian Projects more naturally inside Jira, including in work item view, list view, boards, backlog, and other supported planning surfaces. This helps teams organise work around Atlassian Projects more consistently and makes it easier to track related work in both Jira and the Projects app.

We’d love to hear from you. Please drop your thoughts or questions in the comments below.

Update [19/06/2026]

Thank you for the detailed feedback. We hear you: the default-on behaviour for Atlassian Projects is creating unnecessary admin overhead, especially for teams managing large instances or who don't use Atlassian Projects at all.

Your feedback is already informing how we approach this. We're actively looking at ways to give admins more control over whether and where this field appears.

I'll update this post as soon as we've worked through the options. In the meantime, keep the specifics coming; the details you've shared (screen scheme impact, terminology confusion, sandbox gaps) are all noted. Appreciate your patience.

Comments

Dennis Grochowski_uvc1yp

I'm curious to understand why the default is to have this added to all screens instead of having space admins manage this themselves?

Every admin is fighting the restrictions for limited field configuration schemes in bigger environments and try to reduce the bloat and now this field comes automatically whereas people might not even use Atlassian Project.

As per your description, this is rolled out to every space but also to environments without Atlassian Project?

I don't see this as benefit to be honest - more likey to be additional technical debt.

Bernhard G_

Fully agree with @Dennis Grochowski
I can't understand why it's added by default? That just makes admins a lot of extra work to remove it from every single screen.
You should have learned in the meanwhile from other features that it's mostly not the best idea to roll out new features by default. Just give the admins the option to enable it, if needed. That would save a lot of work for admins and wouldn't confuse users because a new field is suddenly there.

Julia Foden

@Shilpa Airi

What do you mean by 'The field will be added to screens by default '?

Do you mean all new screens that are created when new spaces are created? Do you mean all existing screens? Do you mean all existing create/edit/view screens? Do you mean all new screens that we as admins create eg for a workflow transition (surely not!)

My preference would be for it not to be added to anything by default - let us decide for ourselves! - but can you please clarify what you mean.

You said 'That gives you control over where it appears without needing to fully disable the feature.'. So it seems that we will be able to 'fully disable the feature'? Is that correct? How will we do that? If we disable the feature will that remove the fields from any screens that it had been added to? Or will we still need to remove them manually?

Can you make it so that we have the option to enable the feature instead?

Filip Labarque

Please reconsider adding this field by default to all screens. Projects are not used in our company and now I will need to remove this field from all screens. Leave it up to the admins to decide if they want to use this field and in which screens.

Dagný Eva Magnúsdóttir

100p agree, I feel like this is creating unnecessary work.

I don't fully understand the value of this field either to be honest.

David Williams

Does this mean we can add more than one work item to the 'Where is this work tracked' field? And also as we use Initiatives (L2 in the hierarchy) we would need to be able to link those and not just Epics. Main blocker why we haven't tried to use them so far, I can see potential to use projects as a high level theme view of work.

Robert Eiser

Agreed, please do not add this new field to our screens by default. We sil’ need to evaluate and train our users before rolling our this new feature, and it may not be applicable in all spaces or work item types.

Julia Foden

I just found that the field has already been added to screens! Very annoying! My site now has two fields called 'Project', both are 'Locked' and both are of field type 'Project'. One of them is not on any screens. The other has searcher template 'Atlas Project Searcher' and this one has been added to A LOT of screens. It's not visible to users on the screens yet though.

At least it was easy to remove it from all those screens in one click, by deselecting all.

I'd still like to know how to disable it completely so it's not added to any future screens,

Joe Decker

We operate in a product model and not a project model. We want to give updates and track what is going on with our products. The project terminology has not been clicking with our users so far.

Please consider the ability to update the terminology. In Aha we had ability to rename the concepts, worked similar to translation. We want to make Product updates not project updates.

Michael Holian

@Shilpa Airi

This is something I would like to get a feel for in my sandbox, but I do not see the ability to designate sandbox when launching the Project app, and Project is not present in my sandbox menu. Is there a sandbox version of project that I'm missing?

Matt Doar _Adaptavist_

"Rovo, please create a Python script to use the Jira REST APIs to remove the Atlassian Project field from all screens in Jira"

Karen Sterkowicz

I'm interested in how this will work. Right now there's the Atlassian Project that can be linked to where you track your work and if it's Jira, then you can choose to sync the names together. The Atlassian Project About information can then be seen on the Jira card to view. Then there's Jira Product Discovery, for those that use it, that allow you to link your Jira work items as delivery links to the JPD item. Of course this still has limited reporting and that has it's own frustrations for the two being integrated. With this new Atlassian Project field, will it allow you to link each individual work item/epic, or is it a hierarchy as it's currently set at only one level? It's becoming confusing and I also agree that having it appear by default could cause some issues.

Darryl Lee

Why not have Rovo Studio make you a Forge App called "The Deprojectfiyer?" :-D

Shilpa Airi

Hi all,

Your feedback is already informing how we approach this. We're actively looking at ways to give admins more control over whether and where this field appears.

I'll update this thread as soon as we've worked through the options. In the meantime, keep the specifics coming; the details you've shared (screen scheme impact, terminology confusion, sandbox gaps) are all noted. Appreciate your patience.

Shilpa, Jira Product Team

Darryl Lee

You know, sometimes I'm envious of more agile (and perhaps younger) companies that see the latest shiny new thing from Atlassian like Goals and Projects (previously Project Central or Team Central or Atlas or Platform Experiences, so I guess it's not that shiny or new) and say "That looks awesome, we see how that can fit with the way we work (or we can change how we work to fit this cool new thing), let's DO IT!"

But that's not how my company works. I would posit that it's not how a lot of companies work.

And so, as @Dennis Grochowski already asked, are environments without Atlassian Project ALSO getting this? Because... we don't have it:

So @Shilpa Airi - will this new field be pushed out to sites that have not enabled Projects for any of their users?

If we contrast this with Goals, again, I have 0 Users using that as well.

The Custom Field Goals exists, but using the new "Spaces using this field" feature, I see it has NOT been added to every Project. In fact, I only see it in Jira Product Discovery projects. (And look! A company like mine can adopt a new thing, but it's nice that we can CHOOSE to do so, as opposed to having pushed upon us.)

[Oh man. I should probably learn how the new Field Scheme stuff works.]

It's interesting that for Goals I don't have the old "Contexts and default values" setting anymore, which I guess makes sense.

But yeah, will you be putting this field on sites that don't use Atlassian Project at all?

Darryl Lee

Oh, our posts crossed paths! This is great news - thank you!

Laura Jiménez Goicoechea_3xxbl3

In addition to what David said, it would also be very useful to link Jira Spaces. We use Atlassian Projects so our Project Managers are able to make shared regular updates about the project. Also, calculated custom fields and automation would be amazing to have (for instance, Remaining hours: Estimated hours - logged in hours).

s_gridnevskii

So it is a kind of an Initiative in terms of Agile? I think it just duplicates existing functionality confusing existing users. Since it does not relate to Atlassian and does not relate to Project.

In fact from what I see on screenshots it can be perfectly implemented as an Epic if atlassian agrees to add Stories to default work item types. Then Epic will have Stories and each story = 1 sprint. Story can have dedicated team and all other fancy fields from "Atlassian Project". It will work perfectly for most teams.

Rodney Nissen_94h1ow

@Shilpa Airi, thank you for stepping in so quickly. That kind of responsiveness on a busy thread doesn't go unnoticed, and I appreciate it.

I'll add my voice plainly, because I think it's worth saying directly: the opt-out approach is the part that sits wrong with me. Turning a field on across every screen by default and leaving admins to remove what they don't want puts the cost on the people least able to absorb it, especially in larger instances. Opt-in would have avoided almost everything you're reading in this thread.

My real hope is bigger than this one field. I'd love to see this become a turning point in how Atlassian rolls changes into existing configurations going forward. Default-on for anything that touches an admin's setup is a pattern worth retiring. Make new capabilities available, let admins decide where they live, and the goodwill takes care of itself.

Looking forward to the update once you've worked through the options. Thanks again for listening.

Wurm Peter

Right. Atlassian needs to finally understand one thing: organizations have vastly different approaches to project design. They can't simply impose their own model on everyone. That will only result in hardly anyone using it.

Projects (and goals) must be extremely flexible to be used by many organizations. Yes, there are some commonalities, but Atlassian needs to put a lot of thought into this – not just implement them haphazardly.

Atlassian has a major weakness: they don't do nearly enough conceptual work. It's always the same: We throw it out there and see how it's received.

Wurm Peter

Projects (and goals) have some serious conceptual problems. Please work on these first before linking them to the rest.

The biggest problem:

Most organizations don't use Jira the way Atlassian itself does. Most already have a hierarchy - something like this: project -> initiative/phase -> work package/epic -> task -> subtask

As "spaces" were "projects" not so long ago, many have that as their "project".
Others have created their own work item types that reflect a certain level. Atlassian even introduced "Initiative" as a work item type themselves. My company has introduced "phases". Going from an abstract "project" directly to epic/work package is an oversimplification. Nobody wants to have dozens to hundreds of epics directly connected to a project. That's just not enough organisation.

Albert Manuel

Please don't ! Don;t add it by default to all the schemas, let us choose, i don't want to work for some days to cleanup an field that is not necessary in all the projects! This is not adaption!

Rune Rasmussen

I'm a bit late to the party here, but...

Looking at the available Fields I can't help but wonder if maybe some of these could have been reused, or now exist in duplicate?

And when adding fields to an individual Screen Atlassian Project shows up twice, for some reason.

Matt Doar _Adaptavist_

Looks like they have different P and p

Josh

@Shilpa Airi thank you for the prompt course corrections here. I like the *option* to use this and appreciate that it's no longer getting enabled by default.

Chris Rogers

Also late to the party here, but I'll add my voice to the choir, this type of change needs to be an opt-out by default. Echoing the sentiments of other posters, Jira administrators are already dealing with the field configuration change in larger instances, and this just adds more work to the pile.

Alex Hall

This is among the types of updates I follow closely only to turn off immediately to reduce confusion to my end users. I waste a lot of time occasionally checking to see if this has been rolled out and any updates that may have come up.

As of today, I still don't see any evidence of this in our instance. I guess there's still one more day of July to roll this out?

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-admin