Como usar uma coluna calculada de SharePoint com retenção

Já me fizeram essa pergunta várias vezes de profissionais do SharePoint tentando traduzir sua configuração de Arquitetura de Informação existente/nova para o mundo da retenção.
Pergunta: “Você pode usar uma coluna calculada do SharePoint como condição para aplicar automaticamente um rótulo de retenção?”
Eu não sabia a resposta com certeza, então testei!
Resposta curta… sim, mas há algumas nuances/limitações importantes que você deve conhecer.
Situação
Uma coluna calculada do SharePoint criada selecionando a opção de tipo de dados Calculado (cálculo baseado em outras colunas):

A coluna calculada que você cria preenche dinamicamente fazendo referência a metadados no mesmo item com base em uma fórmula que você fornece. (Referência de fórmulas: exemplos de fórmulas comuns em listas)
O resultado da fórmula pode retornar 1 de 5 tipos de dados:

Se você estiver familiarizado com a Arquitetura de Informações do SharePoint, o que abordamos até agora não é novidade.
O que você precisa saber
Para aplicar automaticamente um rótulo de retenção a um item no SharePoint com base no valor de uma coluna, a propriedade rastreada gerada automaticamente para ele no esquema de pesquisa deve primeiro ser mapeada para uma propriedade gerenciada que pode ser consultada. Feito usando uma das propriedades gerenciadas do Refinable pré-criadas que correspondem ao tipo de dados da coluna, como RefinableString##, RefinableDate## ou RefinableInt##.
Mas… uma coluna calculada do SharePoint é diferente. Se você escolheu Linha única de texto, Número, Moeda, Data e hora ou Sim/Não como o tipo de dados da coluna calculada, todos eles armazenam como um valor de string no índice de pesquisa, conforme mostrado nos valores de amostra abaixo :

O que isso significa é que você deve mapear a propriedade rastreada para uma propriedade gerenciada RefinableString porque todas as colunas calculadas são armazenadas como texto no índice de pesquisa, independentemente do tipo de dados escolhido durante a criação da coluna. Isso afetará as opções de consulta KQL disponíveis para você. Os exemplos abaixo pressupõem que você mapeou a propriedade rastreada para RefinableString00:
Nota: em KQL, dois pontos significa ‘contém’, sinal de igual significa ‘igual exatamente’

Depois que a propriedade gerenciada RefinableString## for preenchida no índice de pesquisa, você faz referência a ela em uma consulta KQL para aplicar automaticamente um rótulo de retenção ao conteúdo do SharePoint que corresponda à condição.
Casos de uso
Para ser claro, as colunas calculadas do SharePoint existem há muito tempo. Eles atendem a um propósito comercial muito além de uma necessidade de retenção e continuarão sendo uma ferramenta no conjunto de ferramentas de um arquiteto de informações do SharePoint nos próximos anos sem usá-los para retenção.
Há casos em que você também pode querer usar um em uma condição de aplicação automática de rótulo de retenção para atender a um requisito de retenção? O fato de vários clientes me perguntarem se era possível me faz pensar que sim.
Embora eu ainda não tenha usado um, suspeito haver lugares para ajudar a simplificar a aplicação automática de rótulos de retenção ou acionar um evento de retenção. Estarei atento às oportunidades de fazer isso nos cronogramas de retenção do meu cliente, mantendo as limitações acima em mente.
Conclusão
Esta postagem demonstra porque é necessário ter uma compreensão profunda da arquitetura de informações do SharePoint e do esquema e índice de pesquisa do SharePoint para criar consultas KQL avançadas para algumas de suas necessidades de retenção. Veja também nosso artigo sobre maneiras de tornar seu site do SharePoint Online mais seguro.
Erick Alves de Moura é Head of Delivery e Arquiteto Principal da Trinapse, consultoria brasileira especializada em Microsoft 365. Acumula 14 anos de experiência em arquitetura e entrega de soluções sobre SharePoint, Power Platform, Microsoft Graph e Copilot, sempre em ambientes corporativos de grande porte.
Ver maisVer menos
Ao longo da carreira, conduziu migrações de SharePoint on-premises para o SharePoint Online, desenhou intranets corporativas, automatizou processos de negócio com Power Apps e Power Automate e, mais recentemente, projetou agentes de IA integrados ao Microsoft 365.
São projetos com milhares de usuários, regras de governança rígidas e integração com sistemas legados, o tipo de cenário em que a decisão de arquitetura importa mais do que a ferramenta.
Fluente em inglês, atende clientes globais e é o arquiteto responsável pela conta da Bayer nos Estados Unidos, no Brasil, atua junto a cooperativas de crédito, agronegócio e indústria, setores com forte exigência de conformidade e continuidade operacional.
Escreve no blog da Trinapse desde 2019. São mais de 240 artigos publicados sobre SharePoint, Modern Workplace, Copilot e agentes de IA, Power Platform e automação de processos, em dois formatos: tutoriais técnicos passo a passo e análises de decisão sobre arquitetura e adoção do Microsoft 365. Todo conteúdo nasce de projeto real entregue, não de documentação traduzida.



