Cross-project epic/tasks backlog visibility

[Amruta]

Hi all, new member here.

Scenario: I have multiple projects, Project-A (main project), Project-B, Project-C.

In Project-A, I have created Epics. I’ve linked tickets (Improvements/Bugs) from Project-B and Project-C to these Epics in Project-A using the Epic Link field.

The linked issues correctly appear under “Issues in Epic”. However, these issues do not show up in Project-A’s backlog or board view.

I want all issues linked to Project-A epics (even from other projects) to:

• Appear in the Project-A backlog
• Be visible in the board/whiteboard view

Question:

1. Is this possible with native Jira configuration?
2. If so, what is the correct way to set up the board filter or JQL?

[John Funk · Accepted solution]

Hi Amruta - Welcome to the Atlassian Community!

A couple of things - first, you should be using the Parent field instead of the Epic Link field as that field has been deprecated. 

Second, the board being used must have a board filter that includes all of the projects. Something like project in (Project A, Project B, Project C) ORDER BY Rank

[Amruta]

Thank you for your response, John.

If I do project in (Project A, Project B, Project C) ORDER BY Rank then I also see Epics from the other projects which I don't want.

I only want to see the tickets from ProjectB and ProjectC linked to ProjectA Epics.

[John Funk]

Then exclude the epics from the other projects in your JQL. 

Project = Project A OR (project in (project B, project C) and issuetype != Epic)

[Amruta]

It works! Thank you so much John. :)

[John Funk]

Great! Glad to hear - and you are welcome!

[Arkadiusz Wroblewski · Accepted solution]

Hello @Amruta 

Jira boards are driven by their JQL filters, not epic relationships. Linking Project B and C issues to a Project A epic won't automatically display them on Project A's board. Simply expand your board's filter JQL to include the other projects (e.g., project in (PROJECTA, PROJECTB, PROJECTC)).

Just ensure you have permissions for those projects and that their statuses are mapped to your board columns so they can render.

Best,

Arkadiusz🤠😎

[Amruta]

Thank you for your response, Arkadiusz.

Yes I have permissions for other projects. However, I dont want to see the Epics of other Projects, instead I only want to see the tickets from ProjectB and ProjectC linked to ProjectA Epics.

[Arkadiusz Wroblewski]

Hello @Amruta 

To isolate Project A and its cross-project child issues, you must list the specific epic keys directly in your JQL:

project = PROJECTA OR (project in (PROJECTB, PROJECTC) AND parent in (PROJECTA-123, PROJECTA-456))

Native JQL cannot dynamically find "all children of any epic in Project A," so manual tracking is required. To avoid updating this filter constantly, use Jira Automation to sync a unique label from the epics down to their children, or look into a Marketplace app for advanced JQL.

Best,

Arkadiusz🤠😎

[Rahul_RVS]

Hi @Amruta 

Welcome to the community !!

As suggested by everyone, a mktplace app can help here. If you are open to try out one to view issues (cross project as well) take a look at,

Agile Tools

The app allows you to view your issues in a list view along with the linked issues shown as child issue. Also you can filter your child issues with multiple criteria. 
The app can be added as a dashboard gadget too, so you don't need to navigate to every project board view to track your issues.

Do give it a try.

Disclaimer : I am one of the app team member

[Paul Glantschnig _Appfire_]

@Amruta, welcome to the community.

Backlog and board are JQL-filter-driven, and JQL has no way to say "all children of any epic in Project-A" without enumerating epic keys or running automation to copy a label down to the children.

If you're open to solutions from the Atlassian Marketplace, this kind of cross-project rollup is something JXL for Jira handles directly. JXL is a spreadsheet-style view of your Jira data with configurable hierarchies. You'd scope a sheet to your Project-A epics (e.g. project = ProjectA AND issuetype = Epic) and enable the parent/child hierarchy. The sheet then expands each epic with its real children, including the ones in Project-B and Project-C, without you having to enumerate them.

From there you can sort, filter, and bulk-edit those child issues, or add sum-ups (e.g. story points per epic across projects). It doesn't put those issues back into the native board or backlog (no app can; that's a board-engine constraint), but it gives you a single live view of Project-A's epics with all their work, no matter where it lives.

Disclosure: I work for the team that builds JXL.

BR, Paul

[Shivam Sharma - Optimizory]

Hi @Amruta ,

Welcome to the Atlassian Community

You've actually hit one of Jira's real limitations here. The backlog and board are filter-driven, not relationship-driven, so even with the Parent field set correctly, Jira has no native concept of "show me everything linked to Project-A's epics." Any JQL approach ends up either hardcoding epic keys, which actually breaks the moment someone adds a new epic, or you can try syncing labels via automation, which does your work but feels like duct tape.

If you're open to a different angle, one thing from my side that solves this kind of cross-project visibility properly:

One Jira add-on, Report X lets you filter across multiple projects in one go and view the hierarchy in table or card layouts, so all the improvements and bugs from Project-B and Project-C sitting under your Project-A epics show up together, structured under their parent epics, not as a flat list.

One thing to be upfront about: it won't push those cross-project issues back into Project-A's native board or backlog; Jira doesn't let any app do that cleanly. What it gives you instead is a dedicated cross-project report view that's fit for purpose, which in most cases is what teams actually wanted from the board to begin with.

Docs if you want to look: https://optimizory.atlassian.net/wiki/spaces/RJC/pages/1373569079/Cross+Project+linking+Filtering

Happy to walk through it against your actual epic structure if useful.