Tracking downstream dependencies of Jira fields, how are you approaching this?

[joao zampa]

Hi Champions,

I'm working on a Jira field governance challenge and curious how others are tackling it.

The problem: when I want to modify or deprecate a Jira field (e.g., rename a value, change the field type, or remove it entirely), I can easily see where it's used, which projects have it on their screens or schemes. That part is straightforward.

What's much harder is understanding how the field data is being consumed downstream. A field might be referenced in:

• JQL — saved filters, board/backlog filters, dashboards, automation rules
• Exports — scheduled or ad-hoc exports where someone is expecting that column
• API integrations — internal tools or third-party apps querying by field name or value
• Reporting tools — BI dashboards pulling from Jira (e.g., via REST or a data connector)

Because of this, I'm exploring building a field dependency matrix, essentially a way for teams to register which fields they care about, how they use them, and how critical they are. Think of it as a self-service impact registry, so that before we make a change, we can notify the right people.

My questions for the community:

1. Is there a programmatic way to audit JQL usage across filters, boards, and automation rules at scale? The Jira API exposes filters but I haven't found a clean way to parse JQL across the entire instance.
2. Have you built anything like a field dependency registry — manual or automated? How did you get adoption?

Would love to hear how others are approaching Jira field lifecycle management at scale.

Thanks!

---

Want me to adjust the tone, trim it down, or post it directly if you have a community URL?

[Sami Shaik · Accepted solution]

Hello @joao zampa ,

Great question, and you have already found the actual boundary: where a field lives is easy, where its data flows is the hard part. Here is the approach that works, split by how auditable each consumer really is.

Question 1: yes, there is a programmatic way, and the piece you are missing is the JQL parse endpoint.

The pattern is a two-stage sweep:

1. Harvest JQL text from every source that stores it. The filter search API pages through every saved filter on the site with its JQL. Board filters resolve through the board configuration API (each board points at its saved filter, so auditing filters covers boards), and most dashboard gadgets ride on saved filters too, so one filter sweep covers more surface than it first appears.
2. Do not parse the JQL with regex. Send it to Jira's own parser. The platform API has a dedicated endpoint, POST /rest/api/3/jql/parse, which with strict validation returns the structured query tree for each JQL string. Walk the structure and extract every field reference cleanly, including inside nested clauses and functions. That is the "clean way to parse JQL across the instance" you were looking for: Jira parses it exactly the way Jira executes it. Reference: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-jql/

One normalization tip that matters at scale: JQL can reference the same custom field by name or by cf[ID], so resolve every extracted reference against the field inventory from the fields API before you count anything, or the same field shows up as two entries.

The honest boundaries, because they shape your registry design:

1. Automation rules have no clean field-usage API today, so they are the weakest link in any programmatic sweep. The practical mitigation is procedural: a deprecation runway (below) that lets rule owners surface themselves.
2. External consumers (BI connectors, scripts, integrations) are invisible from inside Jira. No API on our side can see what a data pipeline on their side expects. This is precisely why your dependency matrix is the right instinct: the only reliable record of an external consumer is the one its owner registers.

The rename scar worth designing around: saved JQL stores whatever the author typed. References by field name break when the field is renamed; references by cf[ID] survive. So publish a convention that integrations and long-lived filters use the cf[ID] form, and treat any name-based reference your audit finds as fragile by default. This single rule prevents most of the silent breakage that makes field changes scary.

Question 2: on the registry, three things that decide adoption.

1. Seed it from evidence, not from a blank form. Run the sweep above and generate the first draft of the matrix automatically, then ask teams to correct and claim entries. People will edit a mostly-right table; they will not fill an empty one.
2. Make registration the price of stability. The deal you offer: registered consumers get advance notice and a migration window before any field change; unregistered ones get whatever happens. That converts the registry from admin homework into insurance people want.
3. Pair it with a deprecation runway instead of hard cuts. Announce, then rename the field with a clear DEPRECATED prefix, let it sit through a full reporting cycle so anything name-dependent surfaces, then remove. The prefix stage is what catches the automation rules and exports no API could see.

Field lifecycle management at scale ends up being one part tooling (the sweep) and two parts contract (the registry and the runway). You are already thinking in the right shape.

[joao zampa]

Wow, that was an awesome reply!

can’t wait to test all that, really appreciate it !

[Lucas Knorr]

An addition from my side regarding the automation rules:

You can export all existing automation rules as JSON. By searching the JSON for both the custom field ID and the custom field name, you should be able to identify all rules that are somehow using a specific field.

[joao zampa]

Brilliant 😍