Jira: Leveraging Native JQL to Reuse Filtered Results Without Add-ons

Can native JQL reuse one query’s results in another? For example, Query A lists Epics with specified priorities while Query B attempts to fetch Stories linked to these Epics. Any native solutions?

Based on my experience working with native JQL, there is no direct method to reuse one query’s results in another. While it might seem intuitive to start with a list of epics with specific priorities and then query all linked stories through that list, JQL in its native form doesn’t support that kind of chaining. I’ve often had to work around this by essentially duplicating the query criteria for both parts of the request, which can be error-prone and hard to maintain. For more advanced scenarios, add-ons have been the only viable option so far.

In my experience, native JQL does not offer a built-in mechanism to chain query results to another query directly. I have frequently encountered scenarios where information from one filter could be beneficial in another context, such as linking epics to stories. The typical workaround is to replicate the filtering criteria across separate queries or rely on saved filters. This approach can be tedious and error-prone, especially in dynamic environments. I’ve monitored how some teams manage this by adjusting their workflows, but ultimately the native functionality does not support cross-query reuse.

nativ jql dont let u reuse filtered result. u have to copy same search critria in a new query. kinda annoying but thats how it is now.

In my experience, native JQL really falls short when it comes to reusing filtered results between queries. I’ve encountered similar challenges when trying to link issues across different hierarchies without resorting to third-party add-ons. My approach has been to refine the criteria as much as possible and maintain consistency in filters, but the lack of built-in chaining capability makes things cumbersome, especially when the underlying conditions evolve over time. It would be beneficial if future iterations of JIRA integrated more flexible query functionalities to address this recurring issue.