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

[Shilpa Airi]

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.

1. Go to Jira settings → Work items → Fields

2. Open Atlassian Project

3. Select Add field to screen

4. Unselect the screens where you don't want it shown

5. 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.

[Dennis Grochowski]

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.

[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. 

[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. 

[Tom Hudgins]

Jumping on the bandwagon - this should not be added to every screen by default. You don't know how I use my Jira projects - oops Spaces. Don't put fields on my screens that I don't need.

[Justin Shum]

My company has hundreds of screens. We do not need a field with yet another confusing use of the word "project" showing up on them.

[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.

[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.

[Laura Jiménez Goicoechea]

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).

[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"

[Darryl Lee]

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

[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.

[Shilpa Airi]

Hi all, 

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

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

[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?

[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]

@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.