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

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.