What is the one jira or JSM issue that wasted the most of your time before you finally fixed it?

[Himanshu Tiwary]

Hi Everyone,

I though this will be a fun and useful discussion.
What is the one Jira or Jira Service Management problem that looked simple at first, but ended up taking way more time than expected before you solved it?

It could be anything:

automation rules

permissions

email requests

Assets

workflows

notifications

integrations

custom fields

For me, some issues start as “this should take 5 minutes” and somehow turn into a full debugging session.

I’d love to hear:

what the issue was

what made it tricky

what finally fixed it

and what you wish you had checked first

I feel posts like this help everyone because the small lessons usually save someone else hours later.

Looking forward to hearing your stories.

[Gregory Kneller]

In my experience many of these “5-minute problems” are actually technical Jira configuration debt.

Everything looks simple at first — a new custom field, one more workflow status, another permission tweak, a quick automation rule.

But over time these small changes accumulate and start interacting with each other: workflows, permissions, automations, notifications, Assets, integrations.

 Then a small change suddenly turns into hours of debugging because the real issue is hidden configuration complexity.

 The fix is often not debugging the symptom but cleaning up the architecture:

fewer workflows, fewer custom fields, standardized schemes.

[Himanshu Tiwary]

The solution for such spontaneity is to keep policies stabilise the schemas and reuse things in the instance instead of adding new also limiting access is also a bullet points that one must follow when there are multiple stakeholders running the same instance 

[Gregory Kneller]

Limiting jira-administrators group is the first and main step to stop the practice. But then the rest jira-administrators shall have and follow a set of rules and limitations that may not be technically enforced out of the box 

[Chris Rainey]

Definitely custom fields.

Custom fields always start out with good intentions, but without a consistency-focused strategy around them, they'll always spiral out of control and the immense amount of tech debt they can create is astronomical, left unchecked.

When I first took over managing the Atlassian Suite at my organization, everything was in complete disarray - and the custom fields were the worst part. To "fix" it, I essentially pulled all of the custom fields and their information and wrote it all down in Confluence. Things like how many screens they're on, when was the last date they were used, what are the options, etc. 

Then, I met with all of the key stakeholders at my org and we talked through each and every one, marking ones that we needed to keep and ones that we could get rid of. And for each that we marked as "need to keep", I double and triple-checked that it was absolutely necessary to have them around. If we still needed to keep them, I proposed ways to make them more general so they fit more use cases than the specific use case they were made for.

It was a lot of work and we did NOT get everything 100% correct, but we've now gotten to a place where we're all speaking the same language when working with Jira.

---

Honorable mention: team-managed spaces - an admin's worst nightmare.

[Himanshu Tiwary]

Hi @Chris Rainey ,

Absolutely agree custom fields are one of the biggest sources of Jira admin debt.

What you described is exactly the right approach audit everything, review with stakeholders, remove what is no longer needed, and standardize what remains. It is a lot of work, but getting everyone aligned on shared field usage makes a huge difference long term.

And yes, honorable mention to team-managed projects/spaces for making governance even harder