WEEK 2 - “The JSM Meltdown: When SLAs Started Bleeding Red”

[#1]

A continuation of the real-life Atlassian cleanup journey.

Where We Left Off

We stabilized Jira.
Developers were finally working with clean workflows.
Reporting started to make sense.
For the first time in months, nobody was complaining.

Then Support called.

Not to appreciate improvements…
but because something broke on their side.

---

1. When the Helpdesk Suddenly Lost Its Voice

At 10:45 AM, the Support Manager messaged:

“Hey, SLAs aren’t working. Can someone check?”

A routine ask - or so we thought.

But we opened the queue and saw all red:

• SLA timers stuck and continuously breaching
• Closed tickets marked as overdue
• P1/P2 escalations triggering multiple times
• A backlog chart that made Support look negligent
• Aging reports that didn’t reflect reality

Agents weren’t frustrated - they looked defeated.

“We’re doing everything right… the system isn’t.”

---

2. First Assumption: A Simple SLA Misconfiguration

We ran through the usual checks:

• SLA targets? Correct.
• Business hours? OK.
• Calendar? Fine.
• Pause/stop conditions? All present.

Nothing seemed wrong.

So why weren’t SLAs stopping?

---

3. The Real Culprit: Workflow Cleanup Ripple

During Jira standardization, we renamed some statuses to simplify usage across all teams.

Old Status	New Status
Working	Work in Progress
Completed, Closed	Done
Paused	Pending

A small change for consistency.
A big impact for JSM.

SLAs don’t care about meaning.

They only read exact strings.

So, SLAs were still waiting for “Completed,” even when issues were marked as “Done.”
They never stopped.

That’s how resolved issues started appearing permanently overdue.

---

4. The Domino Effect Nobody Talks About

This wasn’t just a tech issue.

It affected credibility:

• False SLA breaches created fake emergencies
• Agents spent effort answering “breaches” they didn’t cause
• Customers assumed Support was slow
• Managers blamed delays that weren’t real
• Dashboards misrepresented team performance
• Compliance and audit reporting were at risk

A senior agent said it best:

“We’re working fast, but now we have to defend ourselves because of the tool.”

This wasn’t about Jira or JSM anymore.
It was about trust in the system.

---

5. Fixing the Mess the Right Way

We didn’t revert status names.
We aligned systems instead.

 Fix Approach

• Updated SLA stop conditions from “Completed” → “Done”
• Updated automation rules referencing “Working” → “Work in Progress”
• Fixed service queue filters tied to old statuses
• Audited post-functions that set legacy statuses
• Created a status mapping documentation sheet (finally)

By Day 3:

• SLAs were stable
• Escalations normalized
• Reports matched reality
• Support stopped firefighting

No dramatic rollback.
Just responsible sync.

---

6. The Learning Before Moving Forward

Key Lesson

A workflow cleanup doesn’t live in Jira alone.
JSM is directly dependent on exact status strings.

Changing a name isn’t cosmetic - it’s changing a data point used across multiple systems.

Better Way to Handle It

• Audit dependencies before renaming statuses
• Map old → new explicitly
• Validate against SLAs, automations, queues, reports
• Use a test environment
• Involve the Support Lead early
• Document decisions (or history repeats itself)

A Jira cleanup should be treated as a platform initiative, not an isolated Jira task.

---

Where We Thought It Ended…

Once the SLAs were fixed, everyone relaxed.
We validated our changes on a couple of tickets, just to be safe.

Then we noticed something strange:

• A ticket jumped from Work in Progress → Done
• No transition note
• No comment asking for closure
• Assignee restrictions didn’t stop it
• The workflow condition that should’ve blocked it… didn’t

A support agent swore:

“I didn’t close it. It closed by itself.”

At first, we assumed user error.

We checked another ticket.

Same thing.

And another.

There were transitions happening without validation - and without user action.

SLAs were fixed.
But the workflow behavior wasn’t normal.

We fixed what we could see.
Now we needed to find what we couldn’t see.

We didn’t just inherit messy workflows.
We inherited invisible logic.

---

To Be Continued…

WEEK 3 - “Invisible Hands: The Ghost Rules Inside Our Workflows”

Next week, we uncover:

• The hidden conditions inside transitions
• The post-functions that quietly override rules
• How old admins left behind logic no one knew existed

[s_gridnevskii]

A rule of a thumb: never rename statuses. If someone wants to change status name create a new status, relink everything from old to new and delete old status. 

Status names are global. If you change in any workflow it will change in all workflows. I think Atlassian should make a warning there in the editor.

BTW request names have exactly the same problem. If you rename a request in JSM chances are that you break some automation rules. This is what planning stage about. You should agree on names with stakeholders so that they know that changing them after implementation can cause problems.