Solve the Problem, Not the Ticket: Getting to Yes on Jira Configuration Requests

[#1]

A request comes in for a new custom field. It's specific: the name, the field type, which screens it should appear on. The requestor has done the diagnosis and the design work before ever contacting you. All that's left, as far as they're concerned, is to click "create."

Every Jira admin knows what happens next. Approve it, and you've inherited a field nobody will remember the purpose of in eighteen months. Deny it, and you've become the department of no, the team that slows people down for reasons they don't bother to explain. Neither response is really a decision about the field. Both dodge the only question that matters: does this actually solve anything?

That question gets skipped more often than it should, and skipping it isn't a failure of process. It's a failure of framing.

---

Why requests arrive as solutions

People don't come to Jira admins with problems; they come with solutions, because that's how they think about their work. "I need a field called Root Cause." "Add a status named Waiting for <something>." "Give my team admin rights to this project." Each is a proposed implementation for a diagnosis nobody asked them to explain.

This is the classic XY problem, and it shows up constantly in platform support: someone solves step one, what's actually wrong, privately, then asks you only for step two, how to build the fix. In most contexts, that's harmless enough. In Jira, it's expensive. A field, a workflow status, or a permission scheme isn't a private fix. It's shared infrastructure that future projects inherit. Approve the literal ask often enough and you get the sprawl every Jira governance conversation warns about: six fields that mean the same thing, a workflow with four synonyms for "done," a permission model nobody can fully explain anymore. Reject it reflexively, and the underlying need doesn't disappear, it just moves into a spreadsheet, a rogue automation rule, or a shadow Confluence table that nobody governs at all.

---

The questions that get you to the real problem

The fix isn't a heavier approval process. It's one clarifying conversation before the yes-or-no decision — four questions, five minutes:

• What decision or action changes once this exists? This separates a genuine functional gap from a cosmetic preference.

• Walk me through the last time you needed this and didn't have it. A concrete scenario reveals the actual workflow gap, not the imagined fix for it.

• What are you doing today instead? This often surfaces an existing field, status, or report that already covers the need, just under a name nobody remembers.

• Who else needs this? The answer tests whether you're looking at one team's preference or a genuine cross-team gap, which changes what a right-sized solution looks like.

None of this requires a formal intake form. It requires the discipline to ask before you build.

---

Why this gets you to yes, not just away from no

Here's the part that matters most: once you understand the actual problem, you almost always have more than one way to solve it. Some options fit inside your existing governance guardrails — reusing a field, adjusting a permission scheme, adding a saved filter or a dashboard. Some genuinely require something new. Either way, you're no longer approving or denying a ticket. You're matching a real need to the most sustainable solution available, which is a fundamentally different job than gatekeeping.

Take the "Waiting for <something>" status request, one of the most common requests a Jira admin receives. The “<something>” being waited for could be resources from another team, an approval, a review, a response to a question, or any one of a number of things needed before work can continue. Taken literally, it's a new status in a shared workflow, or creating a custom workflow for one project, and could become a gap in reporting where the new status has not been considered. Ask why, and the real problem is usually visibility: nobody can see what a ticket is actually waiting on. Solve that using the pre-existing “Blocked” status, linked-issue view and a dashboard filter for blocked dependencies, and the underlying problem is fixed without fragmenting the workflow other teams rely on or creating another custom workflow applicable to only one team.

A flat “no” protects the platform and costs you trust. A flat “yes” protects the relationship and costs you the platform. Diagnosing before deciding is how you protect both at once.

---

What this looks like in practice

This doesn't replace formal governance — steering committees, request-type matrices, SLAs still matter. It happens before all of that, and it's often what determines which category a request belongs in to begin with. Build it as a habit, not a policy: every request requires answering one clarifying question before the decision to approve or deny the request can be made.

It's also, not coincidentally, the muscle we spend the most time building with clients during governance engagements. Frameworks and approval matrices matter, but they don't hold up until the people running them ask better questions by default.

---

The five-minute conversation that changes the outcome

Back to that new custom field request. Ask the question, and the requestor tells you they're actually trying to track which issues need legal sign-off before release. That's a real problem — and a five-minute conversation just replaced a field nobody would remember in a year with a solution that addresses what they were actually asking for.

Good governance isn't measured by how many requests you turn down. It's measured by how often you can say yes to the right thing.

[Leonie C_ Breitmoser]

This hits the nail on the head — and honestly, it's what separates a well-maintained instance from a chaotic one in the long run.

Users sometimes don't understand why I won't just add a new field, status, or whatever they're asking for — and that's completely fair. But I always make sure to sit down with them, listen to what they actually need, and work through it together. More often than not, they end up happier with the solution we find than they would have been with their original request, because it genuinely fits their process. And the instance stays clean. Everybody wins! 😊

[Julia Foden]

Excellent article @Trudy P Claspill , thank you, especially the four questions. I normally go back to requesters asking what they want to accomplish / what is the problem they want to solve. Your 4 questions are a great enhancement. 

My general rule re adding new custom fields or statuses or issuetypes is that I'll only add one if it's sufficiently generic that it can be reused. So if they ask for 'Number of Users Impacted', I'll suggest 'Number of Users' instead so that the field can be reused in other projects for number of users invited or processed or whatever. 

[Mykenna Cepek]

Fantastic topic, @Trudy P Claspill

Ticket-focused teams can fall into this pattern if they focus on SLA/SLE metrics at the expense of accumulating tech debt, excessive customization, or feature sprawl. Which do we want to incent: a fast fix that creates future problems, or the right fix that doesn't? Leaders can help teams with this.

The one thing I would disagree about is suggesting the "pre-existing 'Blocked' status" for requests to help with blocked work. I recommend teams explore the Flag feature for blocked work items instead. It's easy, it encourages a comment to describe the blockage, and it radiates natively on the board. I also find work can be blocked at any stage in a workflow, and the Flag complements that (whereas a Blocked status overrides/loses the current work item status).

[Trudy P Claspill]

@Mykenna Cepek 

That is another good option for identifying blocked work! What I included in the article was meant only to illustrate how something that already exists versus something new and custom may solve the need. There is often more than one solution to problem.