Is there a maximum number of issues that can be assigned to an Epic Link? To Linked Issues?

[Charles Amschel]

We have a company-managed service desk project and a software project.

We want to quickly identify for reporting purposes service desk tickets categorized by product (such as Epic Link), and potentially also further categorized by the type of issue the service desk tickets are linked to (such as a specific issue within the Epic).

Is there a maximum number of service desk tickets that can be assigned to the same Epic Link? Is there a maximum number of service desk tickets that could be linked to an Issue/Task within that Epic?

I can't imagine this being the case but wanted to check the theory and practicality before suggesting this as a potentially solution. Will the Epic get bogged down if there's three thousand tickets linked to it? Will scrolling to the Epic's or Linked Issue's comments become a chore? Should Epic Link always be filled in or is Linked Issue enough?

I'm open to alternatives, though I would prefer using Jira default fields (not all of which are being fully utilized) over custom fields. Maybe there's a better way to do this without software project Epic Links and Linked Issues?

Thanks.

[Trudy Claspill · Accepted solution]

Hello @Charles Amschel 

Linking an issue to 3000 other issues will impact your ability to view the issue. There is a limit to how many Child issues will be displayed when viewing a given Epic, and that limit is 100. There is supposed to be a link to allow you to see the remaining issue through the Search Issues screen, but the results of a search itself are limited to 1000 issues.

These limits are in place to provide better performance for the system. Attempting to load more issues, whether they are children of epics, subtasks, linked issues, or generic search results, impacts system performance.

I would advise against using forms of issue linking if you think that you are going to be creating hundreds or thousands of links from one issue to other issues.

Other alternatives for categorizing issues would be to use the Components field and/or Labels field. The values that can be selected in the Components field are managed by Project Administrators and are Project specific. The values that can be selected in Labels fields can be created by anybody and are global rather than Project specific. You could also use custom Select List fields allowing either single or multiple selections per issue, or even cascading Select List values. Values available in Select Lists would have to be managed by your Jira Administrators.