Change a report's source

When creating a report, you can extend it by including parent and child issues. If you want to add or adjust how the report is extended—without changing the base source—you can use the Related issues section.

Available options:

• Parent issues: Includes the parent of each issue in the report source.

For example, if your source includes Stories, their parent Epics are added to the report.

• Siblings: Includes issues that share the same parent.

For example, this adds other issues under the same Epics, such as additional stories and their sub-tasks. This option is available only when Parent issues is enabled.

• Child issues: Includes child issues for each item in the report source.

For example, if your source includes Stories, their sub-tasks are added to the report.

Limitations after report creation:

The following options cannot be added or modified in the report sidebar after the report is created using the Issue Navigator:

• Use sibling issues in estimates only: Includes sibling values in rollup fields—such as ∑ Original Estimate, ∑ Time Spent, and ∑ Remaining Estimate—without adding those issues to the report.

For example, Epic-level totals include estimates from all related issues.

• Use child issues in estimates only: Includes child issue values in rollup fields without adding those issues to the report.

For example, Story-level totals include estimates from sub-tasks.

You can expand the report source by including parent, child, or sibling issues to find issues whose parent belongs to another project.

1. For example, a report source includes three projects, as shown in the screenshot above.

2. By extending the report to include Parent issues, a fourth project (Sample Scrum Project) can appear.

3. When reviewing the hierarchy in this project, you can identify issues whose parent belongs to another project by checking the issue key. If the letter prefixes differ between parent and child issues, they belong to different project.

You can add links, such as as Blocked by, in the Issue View to represent a relationship with a parent item in your organization and display it using a custom hierarchy in a report. Other organizations may use different links, such as Belongs to, for the same purpose.

Follow these steps to verify relationship links, extend the report source, and configure a custom hierarchy:

1. In this example, the report source references three projects using JQL. Click Columns.

2. Select or search for Linked Issues.

3. Identify the highest-level parent and determine the relationship type. In this example, Epic SKP-17 blocks Initiative SSP-32, which belongs to a project not included in the report source.

4. Enable Parent Issues to extend the report source.

5. Click Apply.

6. Click + Add Link Type.

7. Select a Parent Issue Type, Link Type, and Child Issue Types.

In this example, Initiative SSP-32 is blocked by Epic SKP-17. As a result, Initiative is the parent issue type and Epic is the child issue type.

8. Click Apply.

After completing these steps, the parent relationship appears in the hierarchy, as shown in the screenshot below.

Note that Epic SKP-17 is grouped under the project associated with its parent Initiative as part of the custom hierarchy.

For reports that reference thousands of issues or more, reloading the webpage usually takes longer than refreshing the data.

After you update or extend the report source, a red dot appears next to the Refresh icon, as shown in the screenshot above. Click this icon to refresh the report data.

This action works the same as clicking Apply in the Source sidebar tab after updating or extending the source.

A report’s source can include multiple projects. You can reference multiple projects when creating or modifying a report by using JQL or a filter from Jira’s Issue Navigator.

A Board that references multiple projects through JQL or a filter can also be used as a report source.

The report shown in the screenshot of the Cross Project demo report below is based on JQL referencing three projects.

When creating a report, the source you choose depends on the report’s goal. You may use it for retrospective analysis, such as a sprint or release report. You may also use it to present highlights, such as a monthly client report. In other cases, the report supports monitoring activities, such as tracking overspending or scope additions in an active project.

In each situation, the report’s focus—and therefore its source—may change as you gain new insights from the data.

For example, if you want to monitor scope changes in a project, set the source type to Project. Show up to 500 recently created issues and do not exclude resolved issues.

In the Issue structure tab, you can see the cumulative impact of these issues on the project's Original estimate. In this example, the most recently created issues added 1 day and 2 hours to the project estimate. This increase represents a scope addition.

To check whether an external source caused this change, add the Linked Issues column. This column helps you see whether dependencies come from outside the project. After adding it, a pattern appears: the most recently created issues include dependencies on another project.

Next, update the report source so it includes both projects. To do this, switch from a Project source type to a JQL source type.

Then open the Pivot tab. Here, you can review the status of issues across both projects by using Status Category as columns. To see how many issues are missing estimates, use Warnings as rows and Original Estimate SUM as values.

One project may cause new issues to appear in another through dependency links. However, the full impact of future scope additions and their dependencies becomes clear only after you estimate the effort required for active issues flagged by Warnings.

Yes. You can verify your access to a report source by following the steps in a separate article.

You can use Relates to, Belongs to, or another link type to show a parent relationship in a custom hierarchy. For example, an Epic may Belong to an Initiative.

For any link type:

1. Enable the link columns for both incoming and outgoing links.

2. Review these columns to identify which issues is the parent.

3. Check if the parent is in the same project; if not, extend the source to include parent issues.

4. Configure the custom hierarchy based on the identified parent.

If Pivot Report is missing from the top navigation bar, check if it is disabled by following the steps listed in a related article.

In the Issue Navigator, you can switch between Basic and Advanced (JQL) search modes.

If Basic mode is selected, click JQL to switch to Advanced mode.
If Advanced (JQL) mode is selected, click Basic to switch back.

On Data Center, the Basic option appears only when ‘JQL’ is selected. On Cloud, both options are visible at all times.

Yes. Reports can display more issues than a board or the Issue Navigator. However, loading time increases as the issue count grows.

Working with high issue count in Cloud

Atlassian notes that searches have no issue limit, but display limits apply:

• Boards and backlogs show up to 5,000 issues.

• The Issue Navigator shows only the first 1,000 issues.

A report can help you work around certain Jira limits, though it may increase loading time. For example, a board may fail to load if it reaches the maximum issue limit.

In contrast, you can create a report based on the board or its underlying source filter. However, this report may take longer to load compared to one linked to a board that has not reached the maximum limit.

Working with high issue count in Data Center

The display limit for the Issue Navigator can be increased using a documented workaround. A report does not require this workaround, although very large reports may load more slowly.

Similarly to prior example, a report linked to a board or its underlying source filter may take longer to load if the workaround was applied to increase the limit.

Yes. The number of issues in the report source directly affects Jira’s API performance, which determines the report’s loading time—not Pivot Report itself.

• To speed up loading, reduce the number of referenced issues or those added through extensions (parent or child issues).

• Also, specify which projects or boards Jira should search. A narrower search scope means fewer issues for Jira to process, resulting in faster results. Atlassian’s documentation offers additional JQL optimization tips.

In Jira Data Center, alerts help identify slow and complex JQL queries, including those with many custom fields. Atlassian provides detailed thresholds for these alerts in a separate article.

The error above appears when the report source is unbound, whether it uses a saved filter or a JQL query. Follow the steps in the related article to resolve it.

The screenshot above shows the statuscategory field underlined in red in the query entered in the JQL Request. However, the query is valid, as indicated by the green checkmark below the JQL Request.

The field is underlined because your browser's spell check does not recognize statuscategory as a correctly spelled word. You can prevent the field from being underlined by turning off spell check in your browser.

The following steps show how to turn spell check on or off in Chrome:

1. On your computer, open Chrome.

2. Click More > Settings > Languages.

3. Under Spell check, turn Check for spelling errors when you type text on web pages on or off.