Custom Jira Field Works in JQL but Doesn’t Show Up in Dashboard Gadgets
This came up while trying to build basic charts and statistics on a Jira dashboard using a populated custom field. The field itself was fine — it returned correct results in JQL and could be used reliably in filters and searches. From a data perspective, everything looked good.
The blocker appeared when moving to dashboards. The custom field simply wasn’t available in native gadgets for grouping or charting. That meant no way to visualise counts or trends based on that field, even though the data clearly existed. For reporting use cases, this effectively made the field unusable.
The impact is more than cosmetic. When a field can’t be used in dashboards, teams fall back to manual exports or one-off workarounds, and reporting logic becomes fragmented and hard to maintain.
Why Native Approaches Break Down
Jira dashboard gadgets expose only a subset of fields, and custom field availability is constrained by gadget implementation rather than by whether the data exists or works in JQL. Even well-configured, populated fields can be excluded from gadget configuration entirely.
Because gadgets decide field usability at the UI level, there’s no way to override or extend this behaviour. As a result, reporting becomes dependent on which fields gadgets happen to support, not on what teams actually track in Jira.
A Practical Approach That Worked
The approach that worked was to stop depending on gadget-level field support and instead treat custom fields as first-class reporting dimensions in a separate reporting layer.
Using Visionade, custom fields are explicitly selected and indexed as part of the data model. Once indexed, the field’s values are materialised and available for grouping and aggregation in reports, regardless of whether Jira gadgets support them.
This works because field usability is defined at the data-model level, not at the dashboard gadget level. As long as the field is indexed in the data source and included in a dataset, it can drive charts and statistics like any standard field.
Setup Approach
Select the required custom field in the Jira Data Source configuration along with core fields like Issue Key and Status. Example: Story Point. Index the custom field so its values are available as a reporting dimension for grouping and aggregation.
Create a Data Set using the same JQL where the custom field already works, ensuring the reporting scope matches the intended use case.
Preview the Data Set to confirm that the custom field values are populated consistently across issues.
Create a Report from the Data Set and place the custom field in Rows or Columns to control how charts are grouped. Add Issue Key or another suitable field to Values and apply a Count or similar aggregation for statistics.
Choose the appropriate chart type and add the report to a Jira dashboard so it renders without relying on native gadget field support.
Result
After setting this up, the custom field became usable for dashboard reporting without changing how Jira itself was configured. Charts and statistics reflected the real data, and reporting no longer depended on which fields gadgets happened to expose.
The main takeaway is that just because a field works in JQL doesn’t mean it’s usable for reporting in Jira dashboards. When reporting logic is defined at the data-model level instead, those limitations stop being blockers. Hope this helps others running into the same issue.
I’m from the Visionade team, and this content was written with the assistance of AI. I’d be genuinely interested to hear how others approach reporting in Jira so if you have any questions, please don't hesitate to comment.
If you’d like to explore this approach further, you’re welcome to try Visionade - we hope it provides a useful and positive experience: Visionade: Reports, Dashboards, Graphs, and Charts for Jira