Item Limit
This feature is not yet available to all customers. It is currently part of our Early Access Program. Follow our release notes to get notified when it become available to everyone.
By default, structures have a 10,000 item limit. This limit can be increased up to 30,000 items - but please do so with caution. Increasing the item limit may may impact overall performance - not just for the individual structure, but for the entire Jira instance. The larger the item limit, the more strain it can put on your instance.
A high item limit could result in:
Longer load times for larger structures.
Increased load on the Jira instance leading to further performance problems with other apps and Jira itself. At 30k items, this excess load could be significant.
Less frequent syncing, which could result in outdated data appearing in the structure.
Decreased or paused inline editing and action handling.
Best Practices
When creating new structures, there are a number of steps you can take to improve the performance or usability of the structure. In the following document, we've gathered some of the best tips from our users and developers for getting the most out of Structure.
Use Group generators instead of flex items (folders)
If you're creating structures with several flex items, each with its own Insert generator to add issues, ask yourself this question: Can I use a single Insert Generator for the entire structure, and then use a Group generator to organize my issues by a specific field?
Let's see how this can work. If you're using Structure to track upcoming sprints, you could:
Less Optimal Approach
Create a flex item for each sprint
Add an Insert generator to each flex item, adding issues assigned to that sprint
This approach requires adding several generators, which may lead to slower performance.
Better Approach
Add an Insert generator to the top of the structure that adds all the issues you need to track
Add a Group generator that groups issues by Sprint
This approach only requires two generators, improving performance. And if you ever need to reassign issues to a different sprint, this approach allows you to drag them from one Sprint group to another!
Be specific with your Insert generators
If you're using an Insert generator (or more than one Insert generator) to add ALL the issues from a project or a board (or your entire Jira), and then using a Filter generator to see just the ones that interest you, you're making Structure do twice the work. First it needs to add all those issues, then it needs to remove all the issues that don't fit your filter.
For smaller Jira instances, this might not amount to much. But if you have a larger instance, that could mean using multiple Insert generators to pull in thousands of issues, even when you only want to see a few hundred in your structure.
Better Approach
Use a JQL Insert generator and be specific about exactly which issues you want to see. This does the insert and filter all in one step - which will lead to better performance!
Workarounds for the Insert generator issue limit
If you find you need to use multiple Insert generators because the issue limit per generator isn't high enough, consider using a JQL Insert generator with more specific requirements. In many cases, this will prevent the need to add a Filter generator to view specific issues (see above) and can improve the performance of larger structures.
If a single Insert generator doesn't add all the issues you need to see, try using an Extend generator to add related issues, such as linked issues or sub-issues. If you're already using an Extend generator with multiple Insert generators, chances are you have some duplicates in your structure - this approach will help reduce those.
Build single-focus structures
If you've attempted to build a single structure to be used by several teams or for several different projects, chances are it's quite large, probably requires multiple Insert generators, and maybe even several flex items to differentiate between the different teams/projects/etc. For example, you might have a flex item for executives, containing all the issues they care about; a flex item for each team, with all the issues they need to track; and a flex item just for you.
Such structures may take longer to open or feel slow when trying to work in them, and they can be very difficult to navigate or search.
Better Approach
Build multiple structures with narrower focuses. For instance, you might create separate structures for each team, or for each project. You can create as many structures as you need, and by focusing on specific objectives, they will open faster, run smoother, and be much easier for users to navigate.
Use generators to build dynamic structures
In order for a structure to update automatically based on changes in Jira (and for Jira fields and links to be updated when you move issues in a structure), the structure should be built using generators.
If you've built a structure using the Search & Add tool, the structure won't update dynamically. You will, however, still be able to edit most Jira fields if they are included as columns in the structure.
Limit Dashboard gadgets to a single structure (with 1 Insert generator)
As we mentioned above, if you're creating a structure that consists of multiple flex items, each with their own Insert generator, it's better to use a single Insert generator. In some cases, you can use Group generators to accomplish the same things as the flex items did. In other cases, you should consider creating more than one structure.
This advise is particularly important for structures used in Dashboard gadgets. Every time someone views a dashboard with a structure gadget, the entire structure has to load. Because most users see the dashboard every time they open Jira, those structures get loaded more frequently (and by more users) than other structures - so an inefficient structure used in a dashboard gadget can have a far greater impact on system performance.