nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Empowering Jira admins to optimize usability at scale

Mel Policicchio

Introducing new limits, guardrails, and data management tools for the Jira Cloud family of apps to make it easier than ever to manage your data

Hello, Atlassian Community!

We’re excited to announce several new ways to improve working in the Jira Cloud family of apps at scale.

The newly published guardrails, upcoming data limits, and fresh data management tools for Jira, Jira Service Management, and Jira Product Discovery are here to help you manage your data shape and environment.

As your Jira sites grow, so does the complexity and volume of your data. Over time, things like custom fields, work types, and statuses can accumulate and make it harder for users to find what they need amidst all the content. This growing data can also lead to slower performance, making it harder for teams to be efficient.

To address these challenges and support your growth, we’re rolling out:

New limits: Starting February 2026, the Jira Cloud family of apps will enforce new hard limits on certain data types, including custom fields and work types per project. These limits are designed to prevent performance slowdowns and ensure a smoother user experience.
New published guardrails: By popular demand, we’ve released new guardrails—recommended thresholds for data volume and configuration. These best practices help you keep your sites healthy and high-performing.
Enhanced data management tools: We've launched improved data cleanup tools, available for all customers, to help you find and easily manage unused or outdated data. Use these new tools to archive old work items in bulk, clean up unused custom fields, and remove outdated projects.
- Optimize field configuration schemes
- Optimize work types in a work type scheme
Site Optimizer for Premium customers: Now available to enterprise and premium customers, Site Optimizer provides actionable insights and recommendations for cleaning up your site.

Limits vs guardrails: What’s the difference?

Limits are software-enforced ceilings for data usage. If you reach a limit, the Jira apps will prevent further actions until you remediate.
Guardrails are recommended best-practice thresholds that, if exceeded, are likely to impact performance. These are not enforced, but we strongly advise staying within them for optimal performance.

What are the new limits and guardrails?

Type	Entity	Limit or Guardrail Value
Limit (enforced starting Feb. 2026)	Fields per project	700
Limit (enforced starting Feb. 2026)	Work types per project	150
Guardrail (best practice; not enforced)	Work items per site	18,000,000
Guardrail (best practice; not enforced)	Projects per site	8,400

Adhering to the limits and guardrails

Customers on the enterprise and premium plans can easily view their data usage and clean up unused entities using Site Optimizer.

Additionally, we have recently rolled out new data management tools in the Jira Admin screen to help all customers understand their site usage.

The new field configuration schemes page, seen above, will show the number of fields included in your site. It will also let you know if you're approaching the limit, and offer ways to clean up unused data across projects. We have also released this feature for managing work types.

Improving usability at scale

As sites grow, well-managed data reduces search time and increases productivity; no more scrolling through endless custom fields or scrubbing duplicate work types to find what you need. We’re pleased to share these updates as new ways to improve the Jira Cloud family of apps' usability and make teams more efficient. And, for scaling enterprises, limits and guardrails ensure your Jira sites can grow with your organization, especially at 100k users, without sacrificing speed or reliability.

Limits and guardrails are two sides of the same coin, both focused on delivering a scalable, user-friendly, and performant experience. We encourage all admins to review the new documentation, assess your current data, and take action to clean up your sites ahead of the limit enforcement next year.

Thank you for partnering with us to improve the Jira apps for everyone. We’re committed to helping you scale confidently and keeping your teams moving fast!

Comments

Hubert Kut_tg1xyl

We know how important data governance is and how crucial it is to keep Jira instances in good shape as they scale.

That’s exactly why we built Doctor for Jira 🩺 — to help customers with a full instance analysis in just one click, showing all objects across projects and allowing you to clean them up automatically.

Our goal is to support admins in keeping their environments healthy, compliant, and ready for growth. 🚀
You can even try it out with a free 30-day trial and see the impact yourself.

Joerg

Hey,

I like it a lot.

Over the last decade or so, we always had the problem of having a need for multiple Jira admins, sometimes with different philosophies when it comes to customfield governance and specifically naming (naming genericism vs. naming clarity).

A few migrations later (Datacenter to Cloud, and Cloud to Cloud), and we have a huge mess on our hands.

Although to really make informed decisions about removing customfields, there is important information missing in the customfield optimizer:
Creation date and author.

Example: A field that was created 3 years ago and still does not hold any data, can probably be safely deleted, but a field that was created yesterday or a month ago might obviously be missed if deleted. Knowing who created the field can give it additional context as well.

Fernando Eugênio da Silva

Hi @Mel Policicchio , super thanks for this article the these instructions are very necessary and helpful when we are talking about performance and scale.

One question here, please: For Fields per Project limit, you're assuming that each project has their own Field Configuration Scheme, is that right?

If there is a case of many projects uses the same field configuration and the number of fields added into this field configuration is higher than 700. What would happen? All associated projects it will be limited to add more fields at their scopes? How can we measure and evaluate this?

Thank you!

Anwesha Pan

Thanks for sharing this article @Mel Policicchio Very informative

Pavel V

Hi @Fernando Eugênio da Silva, the limit is applied on a field configuration scheme level, meaning you won't be able to add more than 700 to a single field configuration, or a single field configuration scheme.

We are now rolling out UI changes where you will see a preview of what exactly is going to happen in February and what will be limited.

Pavel

Pavel V

Thanks for the feedback @Joerg, I will see if we can surface this information. P

Joël Kemnitzer

Hi @Mel Policicchio

thanks for sharing this.
How about team-managed projects and their created custom-fields?
Does they count against the limit, too?

Thanks in advance,
Joey

Josh

Hi @Mel Policicchio . I'm all for sensible limits that will ensure usability and performance at scale.

This JAC ticket plays into what you're trying to achieve: [JRACLOUD-64188] Ability to unlock system field, to Configure it

For customers that have a mixture of JSM projects and Jira projects, all SLA fields configured for the JSM projects will be included on Jira field configuration schemes and cannot be removed.

If we were able to remove JSM SLA custom fields from the field configuration schemes of completely unrelated Jira projects, we'd be able to drastically cut back on the fields associated with each configuration scheme.

Would you be able to work with @Carol Low on this?

Pavel V

Hi @Joël Kemnitzer, fields created in team-managed projects cannot be associated with field configuration schemes and so do not contribute towards their limit.

The limit is applied for each scheme. The overall amount of custom fields on your site remains unlimited.

@Josh thanks for your comment, we're working on the SLA field problem (and other fields too). I don't have any dates yet but it's not going to be before the current limits go into effect.

Pavel

__ Jimi Wikman

This is going to be fun for all those platforms where contexts for custom fields are not seen as important and all the thousands of custom fields are global

I wonder if anyone have tried the software limits legally, since they are causing a denial of service and do not just block adding more fields. I assume this will shut down the entire project from showing work items if you add 701 custom fields or 150 work item types?

This will also affect filters, so the project will be rendered inoperable until the limits are met? This can cripple an organization, especially if this affects a JSM where someone add another SLA because it is not locked down, potentially affecting tens of thousands of customers?

Pavel V

@__ Jimi Wikman, in case of hitting a limit, Jira admin will prevent adding more fields to the field configuration scheme. All work items, and all projects, will continue working same as before.

Filters are unaffected. All projects remain operable. One can add new SLAs even after reaching the limit.

Pavel

__ Jimi Wikman

@Pavel V it would be good if we can get exactly what the limitation will entail so we know. If it is only the field configuration scheme that is limited, then this sounds great, but what does that really mean?

You can't add a custom field with a project context to a project with 700 fields (and this is all fields, or just custom fields?) and if so, what happens when you add a custom field with a global scope? It will just not be added to the field configuration scheme of that project (and any other project related to it)?

I know a lot of customers that only have one field configuration scheme, and several of them have a lot more than 700 fields in it. When this is rolled out, nothing will happen with those projects then other than that you can't add more fields to projects where the field configuration scheme?

No impact on existing filters, boards, lists and so on and even with 2000 fields the uses can still add hundreds of new SLAs without anything happening?

Just asking because in the past entire boards have been shut down when too many work items are in it, which is a horrible solution. Not being able to add more sounds like a very good solution in comparison!

May I also ask why these limits are implemented?

Do custom fields on project levels have a higher impact than the total number of custom fields? Or is this a first step to prevent lockups due to massive index queries?

Josh

Thank you for the prompt response, @Pavel V .

Imposing the limit without addressing the SLA situation will pose a hardship for us.

Adding onto @__ Jimi Wikman's comments, if one project's scheme in an instance is maxed out at 700 fields, will that prevent the creation of other locked "system" fields like SLAs or those created by marketplace apps?

Pavel V

@__ Jimi Wikman you should already see the UI changes on your instance (if it has more than 700 fields it will warn you). I hope that helps to understand what is going to happen in February.

For your questions

this is all fields, or just custom fields?

All fields

what happens when you add a custom field with a global scope

I am not certain here which scope do you have in mind. I guess it could be project/global scope as in "team-managed" and "company-managed". In which case the answer is that in team-managed projects, the sum of all fields will be counted towards the limit. This is different from current situation (where the limit only applies on project-scoped fields).

Or perhaps we are talking about custom field contexts (https://support.atlassian.com/jira-cloud-administration/docs/edit-a-custom-field-context/, also known as field config schemes - the naming is not helpful at all here, because this has nothing to do with field configuration schemes). In which case the answer is: custom field contexts do not interact with the limit at all.

It's all counted based on field configuration scheme (https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-field-configuration-schemes/).

I know a lot of customers that only have one field configuration scheme

We have rolled out scheme optimizer https://support.atlassian.com/jira-cloud-administration/docs/optimize-fields-in-your-project/ which can help breaking it down, have you tried it yet? I'd be interested to hear your feedback on that too.

When this is rolled out, nothing will happen with those projects then other than that you can't add more fields to projects where the field configuration scheme?

Correct.

No impact on existing filters, boards, lists and so on and even with 2000 fields the uses can still add hundreds of new SLAs without anything happening?

Jira gets slower the more fields you add so performance will decrease. Which is the main reason why we are adding the limits.

Do custom fields on project levels have a higher impact than the total number of custom fields?

There is no single answer that fits all because performance depends on many other factors.

I recommend to keep the fields you actually use and get rid of other unused fields:

- Use Site optimizer (Premium and Enterprise only): https://support.atlassian.com/jira-cloud-administration/docs/what-is-the-site-optimizer/ to identify and remove fields that are not used in any projects

- Use Optimize scheme (available for all editions, including Free): https://support.atlassian.com/jira-cloud-administration/docs/optimize-fields-in-your-project/ to identify and remove fields that are used in some projects but not others

Pavel V

@Josh

Imposing the limit without addressing the SLA situation will pose a hardship for us

If you went through the scheme optimizer (https://support.atlassian.com/jira-cloud-administration/docs/optimize-fields-in-your-project/) and your schemes are still over the limit, please raise a support ticket and we will find a solution.

if one project's scheme in an instance is maxed out at 700 fields, will that prevent the creation of other locked "system" fields like SLAs or those created by marketplace apps?

Locked and system fields are allowed to go over the limit. You will be able to install marketplace apps and let the apps create their fields.

Josh

Great news. Thanks so much for your help, @Pavel V !

Goran Dermeta

Hi all,

suggestion to the team, @Mel Policicchio and @Pavel V :

This feature works perfectly, but i can not use it because of just one simple reason, it doesn't show which work types and/or fields are unused.

Please include a link or list. Or at least generate a list when you click on the option review actions.

Alternatively, when you click download details, you could generate a report there instead of unuseful message:
Scheme Name,"Entities removed"

Pavel V

Hello @Goran Dermeta, thanks for your comment. The message "Scheme Name,Entities removed" you are seeing are CSV headers. There's supposed to be a list right under it. We're looking into why did your report not generate.

Sorry for the inconvenience

Pavel

Charlene Freeman

Thanks for sharing @Mel Policicchio very informative!

Plaban Nayak

management data serivce of jira

Eric Hartway

We're migrating a data center JSM project with 817 in-use custom fields and ran into this limit today. Other than deleting fields to get under the 700 limit, I'm wondering if Atlassian has other best practices or recommendations for getting our project in compliance? I was hoping field context configuration would help here, but it does not since it's a space/project limit.

__ Jimi Wikman

@Eric R Hartway, check if you, by any chance, have all your custom fields in the field configuration scheme. By default, all your fields are added there (I think that will change now on April 1st), which is why you hit the limit.

Unless I am mistaken (this is before my first cup of coffee), you can create a field configuration specifically for your project and then only add the fields used in that project. This should bring you in under the cap for your projects, and all should be well.