A few months ago I was skimming a planning board, doing what many of us do: eyeballing the "Owner" and "Leader" fields to see who I needed to chase.
One ticket jumped out. The Owner was someone I knew had left the company.
Assignee: Name (Deactivated)
Owner (custom user field): Same Name, no warning, nothing.
To everyone else, it looked like a perfectly healthy, owned work item. In reality, it was an orphan. That tiny inconsistency sent me down a rabbit hole that I think a lot of Jira admins and project leads will recognize.
The 10-second version
If you only read one section, make it this one:
- System fields like Assignee/Reporter clearly show when a user is deactivated (for example, "Jane Doe (Deactivated)").
- Custom User Picker fields (for example, "Owner", "Leader", "Objective Owner") often do not – they just show the name, and you only see "Account deactivated" on hover.
- That means your boards, backlogs, and reports can quietly lie to you about who actually owns what – especially after layoffs or reorgs.
If that makes you slightly nervous about your own Jira instance… good. Let's talk about it.
What Jira is really doing (in plain language)
Here's what we saw in Jira Cloud, simplified.
System user fields (Assignee, Reporter)
When a user is deactivated:
- Jira appends a clear label: "Name (Deactivated)".
- You see that in:
- The issue view
- Boards
- Issue search / JQL results where those fields are shown
That's exactly what you'd hope for. It's obvious, consistent, and hard to miss.
Custom User Picker fields
Now take the same user in a custom User Picker field – say, "Owner" or "Objective Owner":
- The issue view still just shows the name (for example, "Jane Doe").
- There's no visible "Deactivated" label or badge.
- The only hint is a hover tooltip like "Account deactivated" – which most people will never see.
So we've effectively taught people to trust "(Deactivated)" in one place… and then silently not show it in the other place where ownership actually lives.
Why this matters more than a "little UX bug"
Under normal conditions this might be annoying but survivable. In today's reality of frequent org changes and layoffs, it's riskier:
- You run ownership reviews, thinking you're validating that every initiative has an active human attached.
- Your JQL filters and dashboards slice by custom owner fields.
- Leadership asks, "Who owns these 20 things?" and your report happily shows a clean list of names.
Except some of those names belong to people who left months ago.
The result:
- Misrouted questions and escalations ("I pinged the owner and they never responded…").
- Orphaned work items that look "green" in reports.
- Governance blind spots – especially if you rely on custom ownership fields for portfolio or strategy layers.
This isn't just UI polish. It's about whether your planning, risk, and accountability model is grounded in reality.
Quick test: does your Jira do this too?
You can check in a couple of minutes:
- Create a custom field of type User Picker (single user is fine) and add it to a screen.
- On a test issue, set:
- Assignee = User A
- Your custom field = User A
- Deactivate User A in Atlassian Admin (or temporarily use a known deactivated user if you already have one).
- Reopen the issue and compare.
You'll likely see:
- Assignee -> "User A (Deactivated)"
- Custom field -> "User A" (looks active unless you hover for "Account deactivated")
If that's what you're seeing, you're in the same boat.
What we asked Atlassian for
Through our Jira admin team we raised this with Atlassian and tied it to related public issues around inactive/deactivated user display (for example, JRACLOUD-67953 and JRACLOUD-74382).
Our ask was pretty simple:
Give custom User Picker fields the same "at-a-glance" deactivated treatment as system fields.
That could look like:
- Showing "Name (Deactivated)" in both system and custom user fields, or
- Adding a clear "Deactivated" badge/icon next to the name in custom fields, visible in:
- Issue view
- Board cards
- Search / JQL views that surface those fields
If changing the visible text risks breaking integrations that parse field values, a non-textual badge that doesn't alter the stored value would still be a big step forward.
What you can do today (while we wait on the product backlog)
While Atlassian works through their bug/feature policies, admins and teams aren't totally powerless. A few patterns we've found useful:
1. Treat deactivated owners as a thing you actively monitor
- Build reports or filters that surface custom User Picker fields pointing to deactivated accounts and make them part of a regular cleanup routine.
- Decide who owns that cleanup: project leads, portfolio ops, or a central admin team.
2. Add a team-level safety net
For your highest-stakes work:
- Pair person fields like Owner/Leader with a team field like Owning Team, so even if the person leaves, the team remains accountable.
3. Be upfront about the limitation
- Add field descriptions/help text to important user picker fields explaining how deactivated users currently show up (or don't).
- Include a screenshot or short Loom in your internal docs so people recognize the pattern instantly.
None of this is as good as a native fix, but it reduces the chance you'll be blindsided by zombie owners in your portfolio.
Let's compare notes
I'm sharing this here because I doubt we're the only ones who:
- Use custom User Picker fields for real ownership
- Have gone through reorgs/layoffs recently
- Need to trust that Jira is telling the truth about who owns what
If this sounds familiar:
- How do you model ownership – primarily people, teams, or both?
- Have you found better workarounds for keeping custom user fields aligned with active users?
- Are you tracking or championing any related JRACLOUD issues that others should be voting on?
Drop your patterns, horror stories, and wish-list items in the comments. The more real-world examples Atlassian sees, the easier it is to justify treating this as more than a tiny UX quirk.
Because at the end of the day, a backlog full of "owned" work that nobody actually owns is just… a very well-formatted illusion.
