No Dataverse, a maioria das discussões sobre segurança gira em torno de security roles, business units e sharing — ou seja, quem enxerga quais registros. Mas existe uma camada que opera em outra dimensão e costuma ser esquecida até a primeira auditoria de LGPD: a segurança por coluna (column-level security). Ela responde a uma pergunta diferente: dentro de um registro que o usuário já pode ler, quais campos específicos ele pode ver, editar ou nem saber que existem.
\nEste post cobre como o column-level security funciona de verdade, como os field security profiles se encaixam no modelo cumulativo de roles, e onde ele tem limites que você precisa conhecer antes de prometer conformidade para o compliance.
\nO que o column-level security realmente controla
\nQuando você habilita Enable column security em uma coluna (via maker portal ou metadados), ela sai do controle das security roles tradicionais e passa a ser governada exclusivamente por field security profiles. A partir daí, três permissões independentes passam a valer por coluna:
\n********) no formulário e nas views.O ponto crítico: sem um field security profile que conceda a permissão, ninguém vê o campo — nem quem tem security role de System Administrator. O admin precisa ser adicionado explicitamente ao profile (ou usar o profile padrão System Administrator, que vem com acesso total). Isso surpreende muita gente que assume que \"admin vê tudo\" como no resto da plataforma.
\nField security profiles: o container de permissões
\nUm field security profile é um objeto que agrupa:
\nAssim como security roles, os profiles são cumulativos: se um usuário está em dois profiles e um concede Read e o outro não, o usuário acaba com Read. Não existe negação explícita — a ausência de concessão é que nega. Isso tem uma consequência prática importante: você não \"tira\" acesso de alguém removendo uma permissão de um profile isolado; precisa garantir que nenhum profile ao qual ele pertence concede aquela coluna.
\nNa prática, o padrão que funciona bem é associar profiles a owner teams alinhados a cargos (ex.: \"RH - Dados Sensíveis\", \"Financeiro - Remuneração\") em vez de usuário por usuário, pela mesma razão que você usa teams para roles: manutenção e previsibilidade.
\nMascaramento: além do all-or-nothing
\nVersões mais recentes trouxeram column masking, que permite exibir o valor parcialmente em vez de esconder por completo. Em vez de ********, você pode mostrar ***-**-1234 para um documento, por exemplo. Isso é configurado por tipo de mascaramento na coluna e respeita o perfil: quem tem Read vê o valor cheio, quem não tem vê a versão mascarada em vez de bloqueio total. É útil para casos de suporte, onde o atendente precisa confirmar os últimos dígitos sem acessar o dado completo.
Onde o column-level security tem limites
\nEsta é a parte que separa quem configura de quem desenha arquitetura de conformidade:
\nUm roteiro de decisão prático
\nColumn-level security é uma das ferramentas mais subutilizadas e, ao mesmo tempo, mais mal compreendidas do Dataverse. Quando bem aplicada, resolve de forma limpa aquele requisito de \"o analista vê o cadastro do funcionário mas não a remuneração\" — sem duplicar formulários nem criar tabelas paralelas. Quando mal aplicada, gera falsa sensação de conformidade com campos vazando por integrações.
\nSe sua empresa precisa estruturar segurança de dados sensíveis no Dataverse com rastreabilidade para auditoria, a Dynamic Soluções pode ajudar a desenhar o modelo de roles, business units e field security profiles de ponta a ponta — incluindo as camadas de integração e Power BI que costumam ficar de fora do checklist de conformidade.
\nIn Dataverse, most security discussions revolve around security roles, business units, and sharing — that is, who can see which records. But there is a layer that operates on a different axis and tends to be forgotten until the first data-protection audit: column-level security. It answers a different question: within a record the user can already read, which specific fields can they see, edit, or not even know exist.
\nThis post covers how column-level security actually works, how field security profiles fit into the cumulative role model, and where it has limits you need to understand before promising compliance.
\nWhat column-level security really controls
\nWhen you Enable column security on a column (via the maker portal or metadata), it leaves the control of traditional security roles and becomes governed exclusively by field security profiles. From then on, three independent permissions apply per column:
\n********) on forms and views.The critical point: without a field security profile granting the permission, nobody sees the field — not even someone with a System Administrator security role. The admin must be explicitly added to the profile (or use the default System Administrator profile, which ships with full access). This surprises many people who assume \"admin sees everything\" as elsewhere on the platform.
\nField security profiles: the permission container
\nA field security profile is an object that groups:
\nLike security roles, profiles are cumulative: if a user is in two profiles and one grants Read while the other doesn't, the user ends up with Read. There is no explicit deny — it's the absence of a grant that denies. This has an important practical consequence: you don't \"remove\" someone's access by taking a permission out of a single profile; you must ensure no profile they belong to grants that column.
\nIn practice, the pattern that works well is associating profiles with owner teams aligned to job roles (e.g., \"HR - Sensitive Data\", \"Finance - Compensation\") rather than user by user — for the same reason you use teams for roles: maintainability and predictability.
\nMasking: beyond all-or-nothing
\nMore recent versions introduced column masking, which lets you display the value partially instead of hiding it entirely. Instead of ********, you can show ***-**-1234 for a document number, for example. This is configured per masking type on the column and respects the profile: users with Read see the full value, those without see the masked version instead of a full block. It's useful for support scenarios, where an agent needs to confirm the last digits without accessing the full data.
Where column-level security has limits
\nThis is the part that separates those who configure from those who design compliance architecture:
\nA practical decision guide
\nColumn-level security is one of the most underused and, at the same time, most misunderstood tools in Dataverse. When applied well, it cleanly solves that \"the analyst sees the employee record but not the compensation\" requirement — without duplicating forms or creating parallel tables. When applied poorly, it creates a false sense of compliance with fields leaking through integrations.
\nIf your company needs to structure sensitive-data security in Dataverse with audit traceability, Dynamic Soluções can help design the roles, business units, and field security profiles model end to end — including the integration and Power BI layers that often get left out of the compliance checklist.
"}},"pageContext":{"slug":"/blog/dataverse-column-level-security-field-security-profiles/","previousPost":null,"nextPost":{"frontmatter":{"title":"Power Apps Canvas: offline nativo com sincronizacao confiavel"},"fields":{"slug":"/blog/power-apps-canvas-offline-sincronizacao-dataverse/"}}}},"staticQueryHashes":["2269431855"]}