Disclosure: Snapbytes is the developer of SnapJQL.
Hierarchy is where basic search becomes manual
Jira work is rarely flat. An initiative contains epics, an epic contains stories, stories can contain subtasks, and teams often introduce additional hierarchy levels. The moment the question crosses more than one level, users start opening parent issues and manually following children.
That is manageable for five issues and painful for five hundred.
SnapJQL adds hierarchy functions and indexed properties
SnapJQL extends Jira Cloud with functions and properties for children, parents, and recursive descendants. The goal is to keep the search inside Jira’s JQL workflow while giving users a way to traverse relationships that native queries do not easily express.
For example, hierarchy functions can start from a scope query or a known issue and return children or parents across multiple levels. A site-wide default traversal depth can be configured, and an explicit depth in the JQL can override it when a particular search needs a different range.
Example: find every unfinished descendant under an initiative
Instead of opening the initiative, then each epic, then each story, build a query that resolves the hierarchy and combine it with standard Jira criteria such as status category or priority.
The result is useful for release readiness, program reviews, migration checks, or any situation where “show me all work underneath this parent” is more important than the immediate parent-child pair.
Indexing is part of the answer
SnapJQL stores enriched hierarchy and relationship data so these searches can work. New and updated issues are indexed automatically after installation, but historical issues may need an initial indexing run before you expect complete results.
If a hierarchy query looks incomplete, check data coverage before rewriting a correct query.
If hierarchy questions still turn into manual clicking, explore SnapJQL on Atlassian Marketplace and test a recursive search against one real epic or initiative structure.
