Why can't I add more than 100 category fields at the issue level?

[Maité Sedeyn]

Hi,

We currently use the Category fields to group our public tender clients. Each client is assigned to a specific category, allowing us to filter tasks by category and efficiently manage our to-do lists. This workflow has proven to be highly effective for our team.

However, following the 2026 updates, the number of available Category fields appears to be limited to 100. As we manage significantly more than 100 public tender clients, this limitation prevents us from organizing all of our files as intended.

Would it be possible to increase the maximum number of available Category fields or provide an alternative solution that supports a larger number of categories?

Thank you in advance for your help!

[Gor Greyan · Accepted solution]

Hi @Maité Sedeyn

As far as I'm aware, the limit of 100 Categories is currently a hard limit and isn't configurable. It was introduced as part of Atlassian's Cloud data limits and guardrails, and there isn't an administrator setting to increase it.

I also wasn't able to find an existing JAC suggestion requesting an increase to this specific limit. If supporting more than 100 categories is important for your use case, I'd recommend raising a new feature request in Atlassian's public issue tracker (JAC). That also allows other customers with the same requirement to vote and watch the request.

In the meantime, you may want to consider an alternative such as a custom select field (if it better fits your use case).

[Maité Sedeyn]

Thanks! We'll raise a feature request. 

[Dave Mathijs · Accepted solution]

Hi @Maité Sedeyn Are you using the default Category system field (LOCKED) or have you created a custom field named Category?

Normally, there is a guardrail/threshold of 20,000 options/values per field (as from September 2026), see Data limits and guardrails 

[Gabriela - LeanZero]

Dave's question is the one that settles this. If you mean the Category on a business project, that's Atlassian's own field, type jwm-category, an option field carrying a separate context per project. If you mean space categories from the admin side, those group spaces rather than work items, so they only reach your tasks through the project they sit in.

On the 100 though. I went through the data limits and guardrails page looking for it and there's no category limit on there at all. Zero mentions, and I checked the raw page rather than the article text. The only 100 it carries is priorities per space. The work item field limits page doesn't mention categories, and neither does the space categories page. So the ceiling is real for you, it isn't documented where it's been attributed, and a request citing that page will get bounced on the first read. Say what you observed instead, with the project and the number.

The custom select route has figures you can quote from that same page. 10,000 options per field across all contexts today, 20,000 per field from September.

[MeghnaP_LogicLemur Labs]

I think this thread also highlights an important distinction: it helps to separate an observed product limitation from a limit that is officially documented as a Jira Cloud data limit or guardrail.

As Jira Cloud introduces more documented limits and thresholds, keeping track of the ones that apply to your Jira instance can help teams identify potential constraints before they affect an existing workflow.

Full disclosure: I work with the team behind QuoteWatch. We built it around this broader challenge of helping Jira teams get better visibility into relevant data limits and usage.

For this specific Category limit, though, I agree that the first step is to confirm exactly which Category field is being used and whether the 100-item ceiling is an officially documented limit or product-specific behaviour.