What hundreds of Jira Cloud instances taught me about configuration drift

[James Bevan]

Quick disclosure up front: I work on a Jira Cloud configuration drift management product. Over the last few months I've had the chance to analyze configuration data across hundreds of Jira Cloud instances. This post isn't a pitch. It's the patterns I keep seeing, and where I think most governance conversations miss the point.

The thing that surprised me most is the gap between what admins think is configured and what's actually there. It's bigger than anyone expects. Not because admins are sloppy or anything like that, but because Jira doesn't surface this stuff in a way that makes the patterns obvious.

Here's what's showing up consistently.

Pattern 1: The field ceiling problem

The Atlassian platform limit for fields associated with a single Field Configuration Scheme is 700. I assumed that was a generous ceiling most people wouldn’t hit.

A lot of enterprise instances are over 800 custom fields total, and a meaningful share are pushing or breaking that 700-per-scheme limit. When that happens, things get weird. Configuration changes start failing silently and new fields don't show up where teams expect them. Admins spend hours debugging issues that aren't bugs. They're capacity limits.

The bit that matters, a chunk of those fields, up to 50% (or more), have effectively zero usage. (How I'm counting: no values populated on any issue in the last 12 months.) Enterprises are hitting a hard platform limit while carrying hundreds of fields nobody uses.

Before we scan, I usually ask the admin to guess their custom field count. The number they say varies. The interesting part is that they are usually short by half! Nearly double what they expected to be there.

One instance had a custom field called "Customer" (text), "Customer Name" (text), "Client" (user picker), and "Account" (paragraph). All four in active use. Different teams, different fields, same concept. None of the admins had any idea the other three existed. Multiply that pattern by a few hundred fields and you understand how instances cross 800 easily.

Atlassian's added some native views to help with field management, and they do help, but they show you what exists. They don't show you what's actually being used, where it's duplicated, or what's safe to remove. That's the gap that creates drift.

The "used" problem

Here's where Jira itself misleads you. Both the API and the admin UI treat a field as "used" if it's attached to a screen. That's not the same as active.

A field can be on a screen that nobody opens anymore. The screen is associated with an issue type in a project where all the tickets have been archived. No human has touched it in two years. Jira still calls that field used.

Usage in Jira isn't binary. There's a chain: project → issue type → screen scheme → screen → field. A field is only truly active if every link in that chain is active. Break any link, whether that's an archived project, a dormant issue type, or an abandoned screen, and the field is functionally dead even though Jira's reporting it as in-use.

Most admins start cleanup at the wrong end. They try to identify unused fields directly and get confused when "used" fields turn out to have no living data behind them. The actual cleanup order Jira wants you to follow is the reverse:

1. Audit screens first. Find the ones not associated with active issue types in active projects.

2. Delete the unused screens.

3. Now fields start showing up as unused, because the screen association has been broken.

4. Remove the orphaned fields.

Before you delete anything, take backups of the projects involved. Archive doesn't mean gone forever, but screen and field deletions can be much harder to recover from. The cleanup is reversible at the project level if you have the backup. It's not reversible at the field level if you don't.

Most admins don't know this is the order. They look at the field list, see 800 entries, see most of them flagged "used," and conclude there's nothing to clean up. There's plenty to clean up. It just doesn't surface until you work the dependency chain backward.

What to look for: total custom field count approaching or exceeding 700. Screens that haven't been opened in 12+ months. Screen schemes associated with archived or inactive projects. Fields with no values populated in the last year. Fields with near-identical names. Context sprawl, where one field carries 15 contexts when 3 would do the job.

Pattern 2: Permission scheme proliferation

Most enterprises don't need more than 10-15 distinct permission models. What I'm seeing is 40+ schemes per instance, sometimes well over 100.

The mechanism is always the same. 1) Team asks for a project. 2) They want slightly different permissions. Admin creates a project-specific scheme. 3) Repeat 40 times.

Now you've got 40 schemes that are 95% identical and nobody can tell you which projects use which.

This is the one I'd argue matters most for security. You can't audit what you can't see. When schemes are named after projects ("Marketing Q4 Project") instead of access patterns ("Confidential: Leadership Read Only"), every new hire and every org change turns into a permission archaeology project.

What to look for: schemes named after projects. Schemes that differ from each other by 1-2 permissions. Multiple schemes with identical permission sets but different names.

Pattern 3: Workflow drift

I'm seeing roughly 90-100 workflows per instance on average. Most started as sensible 5-state flows. They're now 15-state machines with transitions nobody remembers creating.

The mechanism: team needs an extra status. Admin adds it. Six months later, a different team needs a different status for basically the same idea. Admin adds it. Original team adopts the new one. Now both statuses are live.

Multiply by 50 teams over 3 years. You end up with 16 different statuses that all mean "Done."

Here's a quick diagnostic I run on every instance: count the statuses with category Done, then count the distinct Resolution values. Done is binary. The work is done, or it isn't. Resolution is where the nuance lives: Fixed, Won't Fix, Duplicate, Won't Do, Cannot Reproduce. When I see an instance with more Done-category statuses than Resolution values, I know exactly what happened. Teams kept adding statuses to express how something got done, when the right place for that distinction was Resolution. Once you see it, it's everywhere.

When status sprawl hits, reporting collapses. You can't build a "completed work" filter when "completed" has 16 spellings. In this process automation gets brittle and integrations break. You end up in a state where nobody is sure which status actually means "ready for deployment."

What to look for: multiple statuses with similar names. Workflows over 20 transitions. Post-functions added years ago that nobody can explain. Workflows with no documentation at all. More Done-category statuses than Resolution values.

Pattern 4: The inactive project problem

This one's the silent killer.

Roughly half the projects I scan haven't had activity in 6+ months. Not archived. Not closed. Just sitting there. Still carrying their permission scheme, workflow scheme, screens, fields, notifications.

Cleanup work compounds because of it. You want to remove a field, you have to check every project it's tied to. Half of those projects are dead, but the tooling doesn't know that, so the cleanup looks 2x bigger than it actually is. So nobody starts.

What to look for: projects with no issue activity in the last 6 months. Projects created for one-time initiatives that wrapped years ago. "Test" and "Sandbox" projects that survived their original purpose.

What I got wrong going in

I assumed workflow sprawl would be the worst problem. It isn't. Field sprawl is worse. It's harder to see, harder to clean up, and it bleeds into screens, search, and reporting in ways workflows don't.

Inactive project bloat surprised me more than anything else. It's invisible until you try to do cleanup work, and then it's the thing blocking every other improvement.

What governance actually needs to address

Most governance conversations focus on approval workflows for new changes, when the real problem is visibility into what's already there.

Four things that actually move the needle:

Know your baseline. You can't govern what you can't measure. Most teams genuinely don't have a current-state view of their config.

Define standards before growth. Decide what a permission scheme should look like. Decide when a new field is warranted versus reusing an existing one. Establish status naming conventions. Make those calls once and apply them consistently.

Track drift, not just change events. Config doesn't change in discrete tickets. It drifts. Fields appear. Schemes multiply. Projects go dormant. Governance has to catch drift continuously, not at audit time.

Bake cleanup into the process. Most instances have months of cleanup work sitting there right now. The debt already exists. Governance has to include scheduled cleanup, not just change control.

The hard part

The hardest governance question isn't "should we approve this change?" It's "what still depends on this thing before we delete it?"

Want to remove a field? Check every screen, every workflow, every automation rule, every dashboard, every filter. Want to delete a group? Check permission schemes, project roles, issue security, notifications.

That dependency mapping takes hours manually. So most teams either skip it and hope, or never get around to the cleanup at all. The debt stays.

So, where's your line?

Every instance has some drift. The question is when it crosses from acceptable to expensive.

When did you decide your instance had crossed it? What was the moment?

Happy to share more specific data if a particular pattern is useful to dig into.