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.
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 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.
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.
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.
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.
If your Jira instance is drowning in fields, statuses, and permissions nobody remembers the reason for, we'd love to talk. Praecipio helps teams build the governance habits that get you to yes on the right thing, not just away from no.
Trudy Claspill is Senior Architect at Praecipio.