A Atlassian passou a impor limites de dados no Jira Cloud. Desde março de 2026 vale o limite de 700 campos por espaço, calculado com base nos campos incluídos nos esquemas de configuração de campos associados a ele, e o de 150 tipos de trabalho por espaço. A partir de setembro de 2026 entra um conjunto adicional, que inclui 20.000 opções por campo, 150 workflows por esquema, 200 status por workflow e 100 prioridades por espaço, entre outros. A documentação é explícita ao distinguir dois conceitos: guardrails são limiares recomendados, boas práticas não obrigatórias, enquanto limites são limiares que não podem ser excedidos. E é igualmente explícita sobre a consequência, que é menos dramática do que o alarme sugere: configurações existentes que excedam os limites continuam funcionando e nenhum dado é apagado, mas o espaço fica impedido de associar campos ou tipos de trabalho adicionais até que a redução aconteça. O ponto deste artigo é outro: o limite é o sintoma, e a causa é que campo customizado é decisão de modelagem de dados tomada em quinze minutos por quem não modela dados.

O que muda, e quando

Vale registrar os números com precisão, porque circulam versões imprecisas. A tabela abaixo reproduz o que a documentação de limites e guardrails do Jira Cloud estabelece. Uma observação de vocabulário: a documentação atual usa espaço onde antes se dizia projeto, e item de trabalho onde antes se dizia issue.

O que a documentação afirma sobre a consequência, e que vale reproduzir sem exagero: configurações existentes que excedam os limites permanecem funcionais, nenhum dado existente é apagado, e exceder limites não degrada diretamente a performance, ainda que possa tornar a gestão e a investigação de problemas mais complexas. O efeito prático é o impedimento de associar campos ou tipos de trabalho adicionais ao espaço até que a redução ocorra.

O limite é o sintoma. A causa é outra.

A leitura natural de um anúncio como esse é tratá-lo como tarefa de administração: alguém precisa limpar campos antes que o teto seja atingido. Essa leitura resolve o problema uma vez e garante que ele volte, porque não toca no mecanismo que produz campos.

O mecanismo é simples e não envolve má prática. Um time precisa registrar uma informação nova. Pede um campo. O administrador cria em minutos, porque criar é fácil e negar exige argumento. Ninguém, nesse fluxo, faz a pergunta que a própria Atlassian coloca na sua orientação de governança de campos: se o dado não é usado para trabalhar no item ou para relatório, você não precisa dele. É uma pergunta de propósito, e propósito é matéria de modelagem, não de configuração.

A tese deste guia: cada campo customizado criado é um atributo novo no modelo de dados da empresa, criado sem tipo acordado, sem domínio de valores definido e sem propósito declarado. Isso tem nome em qualquer disciplina de dados, e o nome é dívida. Quem trata a proliferação como faxina remove campos e o problema retorna em seis meses. Quem trata como governança de dados coloca um contrato na entrada, e o problema para de nascer.

A conta chega em três lugares, e só um deles é o Jira

O limite de plataforma é a conta mais visível e a menos cara. As outras duas raramente são associadas à mesma causa.

1 · A conta de plataforma

Além do limite por espaço no Cloud, a documentação da Atlassian para Data Center descreve efeitos concretos do excesso de campos: aumento do tempo de reindexação, lentidão na criação e edição de itens e degradação de performance de busca, com orientação de manter o número abaixo de determinado patamar. Vale a ressalva de que os patamares de Data Center não se confundem com o limite por espaço do Cloud: são realidades de produto distintas, com números próprios. O que as duas compartilham é o diagnóstico de que campo em excesso custa desempenho.

Há ainda um efeito documentado que costuma passar despercebido e que é relevante para quem opera integrações: alterações em campos afetam o índice de busca do Jira, e a recomendação é reindexar após mudanças de configuração, porque até que o índice seja reconstruído algumas consultas podem retornar resultados incorretos.

2 · A conta de pipeline

Aqui está o elo que quase ninguém faz. Cada campo criado no Jira nasce como um atributo que, no momento em que a instância passa a alimentar uma plataforma analítica, vira coluna. E a maior parte dos campos criados sob demanda tem duas características que os tornam colunas ruins: são esparsos, porque se aplicam a poucos projetos, e são ambíguos, porque nasceram sem definição de domínio.

O efeito prático aparece na camada intermediária do refino, aquela em que o dado é validado, deduplicado e conformado numa visão de empresa. É ali que alguém precisa decidir o que fazer com quarenta campos que significam variações da mesma coisa em projetos diferentes. Cada campo sem contrato na origem vira uma regra de conformação no destino, e regra de conformação é código que alguém mantém para sempre. É a mesma lógica do acordo sobre qual versão vale que tratamos no artigo sobre dados mestres, aplicada agora a atributos em vez de entidades.

3 · A conta de confiança

A terceira conta é a mais cara e a menos mensurável. Campo criado sem propósito declarado tende a virar campo obrigatório em algum momento, porque alguém quer garantir preenchimento. Campo obrigatório sem propósito é preenchido por obrigação, e preenchimento por obrigação produz dado que parece válido e não é.

O indicador construído sobre ele mente com aparência de precisão, e a descoberta disso costuma acontecer numa reunião de diretoria.

A orientação de governança da própria Atlassian antecipa parte disso ao recomendar não criar campos de opção que precisem ser atualizados com frequência, citando o exemplo de uma lista de seleção com nomes de usuários, que se desatualiza à medida que as pessoas mudam de função.

Como identificar o que sobra, segundo a própria documentação

A definição de campo não usado não precisa ser inventada, porque está documentada. A Atlassian identifica como não usados os campos sem contextos definidos, os que não aparecem em nenhum espaço e os que não estão associados a telas no Jira. Essa é a lista por onde começar.

O caminho de verificação também está descrito: nas configurações, em itens de trabalho, os esquemas de configuração de campos mostram o número de campos incluídos no site, e há a ação de otimizar esquema, recomendada mesmo para quem ainda está abaixo do limite. É possível revisar ações para remover campos não usados, criar uma variante de esquema contendo apenas os campos atuais e em uso, e redefinir o esquema para agrupar espaços que usam campos semelhantes. Para planos Enterprise e Premium, o otimizador de site ajuda a escopar campos globais para projetos específicos, identificar campos não usados e criar configurações direcionadas. Em plano Standard, a orientação é revisar detalhes de uso nos esquemas de configuração e recorrer a APIs REST ou scripts para auditorias mais detalhadas.

Um ponto de atenção que a documentação da Atlassian levanta e que merece destaque na hora de planejar: não existe caminho fácil para reduzir o número de campos depois que eles já estão em uso, e o processo exige cuidado para que nenhum dado crítico se perca. Isso reforça o argumento central deste artigo, porque a remoção é sempre mais cara que a prevenção.

O contrato na entrada: o que faz o problema parar de nascer

Prevenção aqui não é burocracia, é a definição de quatro coisas antes de qualquer campo existir. São perguntas rápidas, e a maior parte dos pedidos morre honestamente na primeira delas.

•     Propósito declarado. Este dado será usado para trabalhar no item ou para relatório? Se a resposta for nenhum dos dois, o campo não deveria existir, e é a própria orientação da Atlassian.

•     Domínio de valores. Que valores este campo aceita? Sem isso, texto livre vira o padrão, e texto livre é o que gera dado incompatível entre espaços e regra de conformação no destino analítico.

•     Escopo real. Quais espaços de fato usam? A documentação registra que contexto global torna o campo disponível para todos os projetos e o inclui em cálculos e indexação relacionados a eles, o que afeta performance. Escopo amplo por padrão é o hábito mais caro dessa história.

•     Reuso antes de criação. Já existe um campo que atende? A orientação oficial para permanecer dentro dos limites começa exatamente por reutilizar campos globais existentes e excluir os obsoletos.

Essas quatro perguntas cabem num formulário de solicitação, e é aí que o processo encontra a ferramenta. Quando o pedido de campo entra como requisição com solicitante, propósito, domínio e escopo declarados, e passa por aprovação registrada, a criação deixa de ser operação de minutos e passa a ser decisão com histórico. O Jira Service Management oferece os elementos para isso, e a elegância está em usar a própria plataforma para governar a própria configuração.

Por que esse desenho exige duas leituras ao mesmo tempo: quem só domina o lado Atlassian enxerga o limite e resolve com limpeza periódica, e o problema volta. Quem só domina o lado analítico enxerga colunas ruins e não tem acesso à origem que as produz. A correção sustentável combina configuração de instância, contrato de atributo e disciplina de solicitação. A CSP Tech opera as duas pontas, como Atlassian Gold Partner na origem e especialistas Databricks no destino, o que permite tratar campo customizado pelo que ele de fato é: um atributo do modelo de dados corporativo que nasce numa ferramenta de trabalho.

Quando isso não é prioridade

•     Instância pequena e distante dos limites. Se os espaços operam com dezenas de campos e não há integração analítica, o esforço de formalizar solicitação supera o ganho. Vale revisitar quando a instância crescer ou quando o dado passar a ser consumido fora.

•     Antes de mapear o uso atual. Estabelecer contrato de criação sem saber quais campos existem e quais são usados produz processo para o futuro e deixa o passado intacto. A verificação de uso vem primeiro, e as ferramentas para isso já estão na plataforma.

•     Quando a urgência é o limite e não a causa. Se um espaço está prestes a bater o teto e travar a associação de campos novos, a limpeza imediata é legítima e prioritária. O erro é encerrar o assunto ali, sem tratar o mecanismo que produziu o excesso.

Perguntas frequentes

Qual o limite de campos customizados no Jira Cloud em 2026?

Desde março de 2026 vale o limite de 700 campos por espaço, calculado com base nos campos incluídos nos esquemas de configuração de campos associados a ele. Campos na lixeira não contam para esse total, e não há limite para o número total de campos customizados no site. Também vale o limite de 150 tipos de trabalho por espaço, e para campos de lista de seleção há limite de 10.000 opções por campo em todos os contextos.

O que acontece se o meu espaço exceder o limite de campos?

Segundo a documentação da Atlassian, configurações existentes que excedam os limites permanecem funcionais e nenhum dado existente é apagado. O efeito prático é que o espaço fica impedido de associar campos ou tipos de trabalho adicionais até que a redução aconteça. A documentação também registra que exceder limites não degrada diretamente a performance, ainda que possa tornar a gestão e a investigação de problemas mais complexas.

Qual a diferença entre limite e guardrail no Jira Cloud?

A documentação distingue os dois com precisão. Guardrails são limiares recomendados de dados, apresentados como boas práticas e não como obrigação, cujo desrespeito pode afetar a performance do site. Limites são limiares que não podem ser excedidos. Entre os guardrails estão 18 milhões de itens de trabalho por site e 8.400 espaços por site; entre os limites estão os 700 campos e os 150 tipos de trabalho por espaço.

Como identificar campos customizados que não são usados no Jira?

A Atlassian identifica como não usados os campos sem contextos definidos, os que não aparecem em nenhum espaço e os que não estão associados a telas. Nas configurações, em itens de trabalho, os esquemas de configuração de campos mostram o número de campos do site e oferecem a ação de otimizar esquema, recomendada mesmo para quem está abaixo do limite. Planos Enterprise e Premium contam com o otimizador de site para escopar campos globais e identificar não usados; no plano Standard, a orientação é revisar os esquemas e usar APIs REST ou scripts para auditoria detalhada.

Próximo passo

Há um teste rápido antes de qualquer projeto: peça a alguém que abra os esquemas de configuração de campos e conte quantos dos campos listados alguém consegue explicar para que servem. A diferença entre esse número e o total é a sua dívida, e ela cresce toda vez que um pedido é atendido em quinze minutos. Solicite um diagnóstico de dados no seu Jira com a CSP Tech e receba o mapa do seu caso: onde os espaços estão em relação aos limites, quais campos atendem à definição de não usados, quais viram colunas problemáticas no destino analítico e que contrato precisa existir na entrada.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas Atlassian e de dados da CSP Tech (Atlassian Gold Partner, parceira Databricks, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).



Fontes (oficiais, acesso set/2026): Atlassian Support, “Data limits and guardrails”, documentação de administração do Jira Cloud (support.atlassian.com/jira-cloud-administration/docs/data-limits-and-guardrails), consultada em texto integral, da qual provêm a distinção entre guardrails e limites, os limites vigentes desde março de 2026 e o conjunto adicional de setembro de 2026 com seus valores, os guardrails de volume do site, a base de cálculo por esquemas de configuração de campos, a informação de que campos na lixeira não contam e de que não há limite para o total de campos no site, a declaração de que configurações existentes permanecem funcionais e nenhum dado é apagado, o efeito de impedimento de associar campos adicionais, a definição de campos não usados e o caminho de verificação e otimização, incluindo as diferenças entre planos Enterprise, Premium e Standard. Atlassian, documentação Enterprise para Jira Data Center, quanto aos efeitos do excesso de campos sobre tempo de reindexação, criação e edição de itens e performance de busca, e quanto à inexistência de caminho fácil para redução após o uso; os patamares de Data Center citados nessa documentação não se confundem com o limite por espaço do Jira Cloud, e o texto declara essa distinção. Atlassian, orientação de governança de campos customizados, quanto à verificação de propósito, ao reuso de campos existentes e à recomendação de não criar campos de opção que exijam atualização frequente. Atlassian, documentação de administração quanto ao efeito de alterações de campos sobre o índice de busca e à recomendação de reindexação, e quanto ao impacto de contexto global na performance. Databricks Documentation (docs.databricks.com), quanto à arquitetura medalhão e ao papel da camada intermediária na conformação do dado. A leitura da proliferação de campos como dívida de modelagem de dados e a organização em três contas são formulação editorial da CSP Tech. Nenhum número não constante das fontes citadas foi utilizado.