Atlassian’s Project Field in Jira: What Admins Must Know

Atlassian announced on June 18 that a new “Atlassian Project” field is coming to Jira Cloud in the July Summer release. The field links individual Jira work items to entries in Atlassian Projects — the platform’s high-level status and communication layer. In theory, that’s a useful integration. In practice, the way it’s being deployed has already generated significant pushback from the admin community, and if you haven’t heard about this yet, you need to.

I want to be clear about this – so I’m using Atlassian’s own words. “This field will…be added to screens by default, so it may become visible to teams as the rollout reaches your site.” Not as an opt-in. Not staged by project type. Whether you want it or not.

For some admins, that’s a Tuesday-afternoon cleanup. For others, it’s an unplanned governance problem landing in their lap. Here’s what you need to know and what you can do about it right now.

What Is Atlassian Projects, and What Does This Field Actually Do?

If you’ve been heads-down in Jira for the last few years, there’s a reasonable chance you’ve heard “Atlas” or “Atlassian Projects” mentioned but haven’t dug into it. They’re the same thing — Atlassian rebranded Atlas as Atlassian Projects, and it serves a specific purpose: it’s the platform’s layer for high-level project visibility.

It’s not where work happens. It’s where you communicate about work. Think of it as the executive-facing status layer — a place to post project updates, surface risks, and give stakeholders a clear picture of what’s happening across initiatives without expecting them to parse Jira boards and backlogs. You use it to say “this initiative is on track” or “this one is at risk,” and the relevant people can see that without digging into the details.

What this new Jira field does is create a direct link between individual work items in Jira and those Atlassian Projects entries. If you’re tracking an initiative in Atlassian Projects, you can now explicitly connect the Jira epics or tasks that belong to it. The Projects app then has a clearer picture of what’s actually in flight beneath the status updates.

In concept, I understand the problem this is meant to solve. The gap between work tracked in Jira and progress communicated in Atlassian Projects is real. You’re either manually reconciling the two or just hoping people trust the status update without evidence, and a native field does close that gap. But my issue is proportion. I’m not convinced Atlas/Projects is widely enough used to justify force-adding a field to every screen in every instance just to serve it. This is using a thermonuclear weapon to kill a fly. Sure, the fly dies, but look at what you flattened to get there.

Three Things Called “Project.” One Ecosystem. Good Luck.

Before we get to screens, I need to flag something that I genuinely think is going to cause widespread confusion, because it’s already showing up in the community thread.

Atlassian now has three distinct things that all use the word “project”:

Jira Spaces — what most of us still mentally call “Jira Projects.” The containers where your issues work items, boards, backlogs, and automations live. Atlassian renamed these “Spaces” but the migration has been slow and the muscle memory is stubborn. And it isn’t only muscle memory: the rename never reached the layer admins actually work in. In JQL the clause is still project, as in project in ("ABC"), and the REST API and automation rules say the same. The label on the tin changed. What’s inside it still reads project.

Atlassian Projects — the Atlas successor. The executive status communication layer described above. Distinct from Jira Spaces in purpose, audience, and where it lives in the platform.

The “Atlassian Project” field — the new addition now appearing in Jira work items, linking to the above.

Three uses of the same root word, three different things, all visible to your users in the same product. Someone is going to open a Jira issue, see the “Atlassian Project” field, and ask whether that’s the same as the Jira project they’re already working in. The answer is no — but explaining why requires knowing the Atlas/Projects history and the Spaces rename, which is a lot to ask of someone who just needs to log a bug.

I don’t expect this confusion to slow the rollout, but I do expect it to generate a steady stream of helpdesk tickets in larger organizations. Worth getting ahead of it with internal documentation before the field is live.

Why Admins Are Reacting

The community notice went up on June 18, 2026. The thread filled up fast — roughly a dozen comments inside the first day, almost all of them expressing some version of frustration.

Dennis Grochowski, a Community Champion who works in complex enterprise environments, said what a lot of admins are probably thinking: “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… I don’t see this as benefit to be honest — more likely to be additional technical debt.”

That’s not a fringe reaction. Anyone who’s spent time trying to maintain field hygiene in a large Jira instance — keeping screens clean, reducing cognitive load for users, managing the overhead of configuration drift — knows that every field added to every screen is work to undo later if it’s not wanted.

Justin Shum landed two complaints in one breath: his company has hundreds of screens, and they don’t need a field bringing yet another confusing use of the word “project” onto them. Joe Decker took that further: his org runs a product model rather than a project model, the project framing has never landed with his users, and he asked Atlassian for the ability to relabel the terminology the way Aha! allows. That’s a reasonable ask the rollout doesn’t currently accommodate, and it’s the same naming problem from a different angle.

Julia Foden reported that the field has already been added to screens in her instance — before the official July release. Digging in, she found something messier: two locked fields both named “Project,” both of field type “Project,” with one of them carrying the legacy “Atlas Project Searcher” and already attached to a long list of screens (not yet visible to users). That’s a strong tell that this isn’t a clean new field so much as the old Atlas linking plumbing resurfaced under a new name. So for some organizations, this isn’t a future concern, it’s a current one.

Matt Doar — one of the sharper Atlassian community voices around — responded dryly by suggesting someone ask Rovo to generate a Python script to remove the field from all screens via the REST API. Which, depending on your screen count, is not actually a bad plan.

Michael Holian raised a different and very practical problem: he wanted to test this in a sandbox before it reaches production, but there’s no sandbox version of the Projects app available to evaluate against. That’s a real gap, because Atlassian’s own seasonal-release pitch leans on admins previewing changes in their sandbox a month ahead — which is hard to do when the thing you’d be testing isn’t there to test.

The core community question is straightforward: why opt-out instead of opt-in? Atlassian chose to add this field everywhere and leave it to admins to remove it where it’s not wanted. The inverse approach — make it available, let admins decide where to enable it — would have generated almost none of this friction.

Update: Atlassian responded the next day. Shilpa Airi acknowledged that the default-on behavior is creating unnecessary admin overhead, especially for large instances and teams that don’t use Atlassian Projects at all, and said the team is actively looking at ways to give admins more control over whether and where the field appears. She committed to updating the thread once they’ve worked through the options. That’s a fast and responsive reply, and it’s worth crediting. It is not a fix yet. There’s no opt-in switch, no answer on the new-screen behavior, and no timeline. But the specifics admins raised were explicitly noted: screen scheme impact, terminology confusion, and the sandbox gap.

How to Remove It From Your Screens

If you want to check whether this field has appeared in your instance, or get ahead of the July rollout, here’s the current path:

1. Go to Jira Settings → Work Items → Fields
2. Find “Atlassian Project” in the field list
3. Click “Add field to screen” (the label is a bit counterintuitive — this is actually the screen association management panel, not just an add button)
4. Deselect every screen where you don’t want the field to appear
5. Click Update

One scoping caveat: this is a company-managed-project mechanism. Screens and screen schemes don’t work the same way in team-managed projects, so Atlassian’s own removal guidance is framed around company-managed projects specifically — if your instance leans heavily team-managed, the surface you’re cleaning up looks different.

Julia Foden confirmed that you can deselect all screens in a single pass — you’re not clicking through them one at a time. That’s at least something.

The open question I don’t have an answer to yet: what happens to new screens you create after you’ve done this cleanup? If you build a new screen configuration next month, will the field be added to it automatically? Atlassian has now responded to the thread in general terms, acknowledging the overhead and saying they’re working on giving admins more control, but they haven’t answered this specific question yet. I’d want that answer before declaring the problem solved, and I’ll update this post when they do.

If your screen count is high enough that the Settings UI approach isn’t realistic, the Jira REST API gives you a programmatic path to strip the field in bulk. It’s a two-step pattern: enumerate every screen the field lives on with GET /rest/api/3/field/{fieldId}/screens, then remove it from each screen tab with DELETE /rest/api/3/screens/{screenId}/tabs/{tabId}/fields/{id}. Matt Doar’s suggestion about pointing Rovo at that job is genuinely sensible if you’re looking at hundreds of screens — it’s a well-scoped, idempotent operation that’s a reasonable task for an AI-assisted script.

A Pattern Worth Naming

I want to say something about the deployment choice here, because I think it matters beyond this one field.

The admin community’s frustration isn’t really about this specific field. It’s about a pattern: when Atlassian ships something that touches existing configurations, the default is increasingly opt-out rather than opt-in. The feature gets enabled everywhere, admins clean up what they don’t want, and the cost of that cleanup — in time, in governance overhead, in tickets from confused users — lands on the people running the platform.

Here’s the part that actually annoys me: this opt-out is hard to read as simple convenience. The apparent motive looks more like distribution. Forcing a field into every instance of your most popular product is an effective way to put a far less popular one in front of people who never asked for it. Atlas has been around long enough for the market to form a view, and the enthusiasm never really materialized. Defaulting it onto every Jira screen reads, at least to me, less like a feature and more like an attempt to manufacture the adoption it hasn’t earned on its own.

There’s an extra layer of irony in the timing. Field Schemes — Atlassian’s new unified field-management model, the one explicitly pitched as reducing field bloat and even auto-removing unused field associations — hit general availability and began its progressive rollout earlier this month. So in the same stretch of days, admins are being told the field model is getting leaner while a brand-new field is force-added to every screen. The two messages don’t strictly contradict each other, but landing them together is tone-deaf scheduling. (I broke down what Field Schemes actually changes in a separate post if you want the deeper background.)

That cost is real and it compounds. Every org has admins who are already stretched managing field hygiene, permission scheme drift, and the accumulation of “we’ll clean that up later” decisions. An unexpected field on every screen isn’t a catastrophe, but it is an interruption, and in a mature environment it can take real effort to untangle cleanly.

I’ll be straight about where I land: I’m not convinced this is the net positive Atlassian seems to think it is. When I demoed and trialed Atlas previously, I didn’t see much real appetite for it. And in 2026, most people are going to point the Atlassian MCP and their LLM of choice at the actual Jira and Confluence data and summarize it directly, bypassing the curated status layer entirely. I’d still have preferred an opt-in rollout, and the early signs are that the community feedback is already pushing Atlassian to rethink the approach for rollouts like this. But that’s a longer conversation. For right now, the practical path is the one above: find the field, deselect your screens, and wait for Atlassian to clarify the new-screen behavior.

There’s a bigger question lurking under all of this, and it deserves its own post: whether Atlassian Projects is worth the screen real estate at all. It’s a work-about-work layer in a category full of graveyards and entrenched incumbents, from Meta’s shuttered Workplace to Microsoft’s Viva Engage, and it asks teams to spend time narrating work they already documented in Jira and Confluence. I think Projects is facing a very steep climb, and I’m considering expanding on that thought on a future date.

Wrapping Up

A new “Atlassian Project” field is arriving in Jira Cloud this July, and for some instances it’s already there. It connects work items to Atlassian Projects — the platform’s strategic status layer — and the underlying capability is reasonable on paper. What’s generating community friction is the deployment decision: opt-out by default, added to all existing screens, with no pre-rollout notice that would have let admins prepare.

The cleanup path is straightforward: Settings → Work Items → Fields → Atlassian Project → deselect your screens → Update. The open question of how new screens are handled going forward is still unanswered, though Atlassian has now acknowledged the broader concern and says it’s working on giving admins more control. I’ll update here when they share specifics.

I’m also curious what your reaction is to the naming situation. Three things called “project” in the same ecosystem is the kind of thing that sounds minor until you’re explaining it to a user who’s just confused about why there’s an “Atlassian Project” field in their Jira issue. If you’ve already hit this in your instance, I’d genuinely like to hear how your users have responded.

Until then, this is Rodney, asking: have you updated your Jira issues work items today?