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.

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

[Matt Doar]

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

[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

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

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

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

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

[Ryan Gillespie]

Greg, in that case we have the workflow set the resolution to Canceled. Anywhere there is a status for Canceled, the resolution gets auto set to that when it moves there. When users cancel something, they don't set the resolution, the system does. As a Jira admin, we already are obligated to manage the resolution list. We don't let people suggest new resolutions though unless it truly makes sense system wide. I don't think we've added more than 5 past the defaults.

[Greg D]

@Ryan Gillespie heard. The thing is, in the use-case I described the team would want to only use the Canceled status along with the resolution when they were the ones that decided the work item was not going to be worked and an integrated automation may set that resolution and leave the status unchanged in an "In Progress" category in the scenario where a customer canceled or something while the team was still intending to work it.

Just saying I prefer a way to clean up the inevitable mess no matter how it is set up with guardrails and keep as much customization available as possible. I agree that Atlassian should set a starting point for everything as a default, then Org/Site admins should have full control to change that default, then space admins should be able to change it from there, then end-users. That provides good guidance all the way down for people to understand and warnings/guidance for why certain changes are not preferred along the way.

[Ryan Gillespie]

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.

[James O_Connor]

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

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

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

[Becker_ Rene]

I got an answer from Atlassian for this. I posted it here (page 2): https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Why-is-deleting-Organisations-so-painful/ba-p/3251800

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

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

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

[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! 🙈

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

[James O_Connor]

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

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

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

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

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