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

If you could remove one Jira feature tomorrow...

zoltanersek _outpostlabs_dev_

If you could remove one Jira feature tomorrow, what would it be?

Maybe, not because it's bad, but because it causes more confusion than value for your teams.

For me, it's interesting how some features seem great in theory but end up being rarely used, misunderstood, or creating extra admin overhead.

I'm curious what you'd pick, and why.

Comments

Luke Gackle

The Share With field is a constant pain point and creates confusion for users:
https://jira.atlassian.com/browse/JSDCLOUD-10908

Ignacio Pulgar

The ability of creating custom fields with the same name than other existing ones.

Introduces confusion in several places: Search, Screens, Automation, Dashboard Gadgets...

The problem tends to become worse when you have team-managed spaces (hint: JPD spaces can just be this kind).

Jean Gordon

The changes to views that dont help with daily work as have to use more steps to get where need to.

Projects should be named projects not spaces which does not align with commonly used terminolgy

Viswanathan Ramachandran

If I could wish a magic and ask for Jira feature to save teams from endless confusion and administrative overhead, it would be Resolution as a field separate from Status.

Hear me out.

In theory, it makes sense:
- Status is in the lifecycle and Resolution is how it got there.
In practice? It is the single biggest source of "Why is this ticket still showing up on my dashboard?" panic in the Jira universe.

It doesn't stop, the other one I count for is ability to block Add Status in Agile Simplified Workflow. For ex: There is existing existing status "In Dev", but its let you add "IN DEV". Instead ability to choose the existing ones.

The verdict:

It says Simplified Worflow, but it becomes Complex for Teams, large organisations.

Ryan Gillespie_k8xz6l

The ability for users to create their own organizations because Atlassian is desperate for them to. As a cloud org admin, we have one product at enterprise level, and the rest at premium. They only allow us to block rogue orgs from our Guarded users for the one single product. It should be from literally all of them. Instead we are stuck adding ourselves to user's organizations and going through a months long deletion process.

Now, this could be fixed in a couple ways. One, enable the ability to block all rogue app creation, Two, if they fixed the wording of their prompts so people who are looking for access to our stuff don't get guided through creating their own entire site. Most users aren't doing it maliciously it feels like. They want access to what they know we already have. They want the join the fold. Instead the prompts are not clear enough to non-users (at the time they do it) and they end up with their own organization.

Pretty sure I know a few other admins that would love to remove the 'feature' for your users of your claimed domains to make their own orgs. Fragmentation is pretty much the opposite of a Teamwork graph. But it is still allowed and seemingly encouraged.

Becker_ Rene

Anything that edges users to connect to

- devops

- onedrive

- googledrive

- miro

- notion

- mural

- other Atlassian apps

- other third party apps

- new features and force users to use them

... so basically everything that is not part of the defined company-scope. If we wanted it, we'd have it. Asking users to ask admins to connect other products (third or first) just causes frustration for admins and for users

It feels like Atlassian is livin on those affiliations and just loves to shove them in user's faces to have them annoy their admins, who are just trying to stay within Company Policy.

---

Anne Saunders

I half agree - I think It should be up to Admin to determine which services may be connected, then up to the user to make the connection. E.g., we use Google Drive and Figma as a company, so it's ok for users to connect those; we don't use Notion or Miro, so users should not be allowed to connect their personal Notion or Miro accounts to our Atlassian instance.

Suresh

In theory, it makes sense:
- Status is in the lifecycle and Resolution is how it got there.

Honestly, if they can do that magic of Resolution being applicable on only Terminal Statuses (Done Status Category), it would do a world of good. Especially federating workflow management by Project Admin and expecting them to be knowledgeable about Resolution and Status nuances, more so if Rovo is taking care of these Workflow steps for them. When Jira cares about Resolutions on only Done, what else is needed to block it from rest.

Million votes for "In Dev", but its let you add "IN DEV". Centralized Statuses and governance is the dream for Admins.

Brita Moorus

I would remove the habit of keeping every old configuration around forever.

Inactive workflows, screens, schemes, custom fields and automation rules - it becomes difficult to know what is genuinely unused, what can be safely deleted and what might still be connected somewhere unexpected.

I would replace it with proper archiving, dependency checks and clear “last used” information. Not exactly removing a feature but definitely removing a lot of admin anxiety! 🙈

Haddon Fisher

This is a bit of a stretch, but the "feature" I'd love to see Atlassian unwind is being a publicly traded company. The proof is all circumstantial, but it feels like this is the moment when they secretly changed the company value "Don't f&$@ the customer" to "Don't forget to fleece the customer."

Ryan Gillespie_k8xz6l

@Haddon Fisher I wouldn't say secretly. This is pretty much what has happened to all big tech companies. There is a reason the term Enshittification is a well known thing. The process where the system starts to focus more on extracting maximum wealth for investors over the benefits of the people and ecosystems in which it operates. Look at how many changes have sat open for a decade or more, and make perfect sense, vs how fast they rushed to AI all the things. At how many ads they have everywhere for little other services to get your users to bug you as an admin (Another user just mentioned this in a comment above, and its 100% true). You're dead on that their direction is more in keeping with the buzzwords rather than focused entirely on what makes sense and what people actually want.

The same can be said for the changes to the Champion program. All of the wording now for being a champion makes it look like they're more interested in free tech support for the community and influencers to sell their stuff than they are about people who actually want things to be better.

David Cowley

Oh, yes please! If we could have Atlassian stop advertising their other products to our user base that would reduce a huge burden. If they insist on doing it (as they do), they should at least provide us with the ability to customize the flow (even if it's just text written by us that appears somewhere) so that the request follow our internal processes instead of being forced to respond to the Atlassian flow (email the Org Admins, as though we don't have better things to do).

Haddon Fisher

To be fair, they always sat on a lot of very valid feature requests @Ryan Gillespie but I agree 100% with the rest. At least prior to going public there was a very obvious capacity problem - the change velocity has skyrocketed since going public, but its a firehose of hot garbage.

Matt Doar_fellaq

I so agree with this. Or at least warn admins who are creating fields. Or something!

James O_Connor_o89ye8

I'm definitely one of those other admins that would love to see this removed!

zoltanersek _outpostlabs_dev_

good call, duplicate names might be manageable with 20 fields, but with hundreds they make automation, JQL and reporting much harder to maintain

@Matt Doar love your idea of a warning

zoltanersek _outpostlabs_dev_

Resolution is one of those concepts that makes perfect sense once you know Jira... and confuses almost everyone before that. Restricting it to terminal statuses would probably eliminate a huge percentage of support questions.

zoltanersek _outpostlabs_dev_

I hadn't thought about it from the Enterprise admin side, but that's a really good point. The intent is probably to reduce friction for new users, but at enterprise scale it creates fragmentation instead.

zoltanersek _outpostlabs_dev_

I'd love a proper 'Configuration Health' view that shows last used, dependencies, and confidence that something is safe to archive. Cleaning up Jira shouldn't feel like defusing a bomb.

zoltanersek _outpostlabs_dev_

Admin-controlled allowlists would feel like a good middle ground. Users get a smooth experience with approved tools, while companies keep governance where it belongs.

michelle_bachmann

Atlassian's passive aggressive marketing style of placing new features and items on the quick launch. Most annoying, and even more annoying is when the feature is NOT available in our standard license level. Then, the feature displayed needs to be turned OFF in each individual project.

Also in the same theme, when new views in Boards appear that also need to be turned OFF in each individual project.

WHY? I think it's self explanatory.

Brad Fitzpatrick

Amen..... this is such a royal PAIN. What a waste of our time. Atlassian claims to be a metric driven organization, so would love to know if any of those orgs ever turned into something that generated income for them and how much time they waste supporting everyone's delete org requests.

James O_Connor_o89ye8

I love the Configuration Health idea @zoltanersek _outpostlabs_dev_ - that would be immensely helpful.

Greg D

There's an edge case where setting a resolution without a terminal status makes sense: think of a customer who cancels mid-build, say you're already in QA. The ticket won't be worked on further, but it never reached "Done" — you still want a record of how far it got before it stopped.

You could say "just use a different resolution for that," but then you're stuck managing a global resolution list and leaning on workflow properties to keep people from misusing it elsewhere.

So I'd frame it less as "restrict resolution to terminal statuses" and more as: full customization is the right default, with guardrails (warnings, cleanup tooling) for people who don't know what they're doing. An even better fix would be Atlassian building proper field/status/resolution merging tools with back-dating support — so when messes do happen, admins can actually clean them up instead of living with them forever.

Mandatory resolutions on terminal statuses for both company-managed and team-managed workflows would probably cover 95% of the pain either way.

Hana Kučerová

Team-managed spaces.

Ignacio Pulgar

I relate so much with this one!

I've heard some good news are on their way which will reduce our main concerns.

We will see!

Ignacio Pulgar

This is another good one.

The JQL:

labels != "abc"

Not returning work items with no labels.

This actually happens with all fields.

For getting all work items lacking the abc label, we currently must include:

(labels != "abc" OR labels IS EMPTY)