No modelo de segurança do Dataverse, a maioria dos times começa resolvendo tudo com security roles e business units. Mas há uma categoria de problema que roles não resolvem bem: o acesso por exceção, caso a caso, a registros específicos — aquele \"preciso que fulano veja só este projeto\", ou \"esta oportunidade foi passada para outro vendedor manter\". É aí que entram o record sharing e os access teams, duas mecânicas que compartilham acesso granular sem reescrever o desenho de roles. O problema é que ambas têm armadilhas de performance e governança que só aparecem em escala.
\nComo o sharing funciona por baixo
\nQuando você compartilha um registro (manualmente na UI, via GrantAccessRequest no SDK ou via Power Automate), o Dataverse cria uma linha na tabela de sistema PrincipalObjectAccess (POA). Cada linha POA associa um principal (usuário ou team) a um registro específico, com um conjunto de direitos (Read, Write, Append, AppendTo, Assign, Share, Delete). Esse acesso é aditivo ao que a security role já concede — o sharing nunca tira acesso, só soma.
O ponto crítico: a POA cresce com o número de combinações registro × principal. Compartilhar um registro com 1 team de 200 pessoas gera 1 linha POA (o acesso é resolvido via membership do team). Compartilhar o mesmo registro individualmente com 200 usuários gera 200 linhas. Em cenários de compartilhamento em massa — por exemplo, um flow que compartilha cada novo caso com meia dúzia de usuários — a POA pode chegar a milhões de linhas, e aí toda query que precisa avaliar acesso (praticamente todas) fica mais lenta, porque o engine precisa resolver a POA no plano de execução. Esse é um dos gargalos de performance mais difíceis de diagnosticar no Dataverse, justamente porque a tabela é invisível no modelo de dados.
\nOwner team, access team e o modo automático (access team template)
\nTeams no Dataverse vêm em dois sabores, e confundi-los custa caro:
\nE há a variante poderosa: o access team template. Você define, por tabela, um template com um conjunto de direitos (ex.: Read + Write) e habilita um subgrid de \"team members\" no formulário. Quando um usuário é adicionado ao subgrid de um registro, o Dataverse cria sob demanda um access team invisível para aquele registro e compartilha com os direitos do template. Quando o último membro sai, o team é removido. Isso dá acesso por registro com uma UX limpa, sem explosão de teams manuais — mas cada membership ainda vira linha POA, então o volume continua importando.
\nQuando usar cada mecanismo
\nUm roteiro prático de decisão:
\nGrantAccessRequest/ModifyAccessRequest com cautela de volume — prefira compartilhar com um team em vez de N usuários, e revogue o acesso (RevokeAccessRequest) quando a condição deixa de valer, para não deixar POA órfã acumulando.Armadilhas que aparecem em produção
\nShare propagam o compartilhamento para registros filhos. Em hierarquias profundas, um único share pode gerar uma cascata de linhas POA que você não contou.Fechamento
\nSharing e access teams são as ferramentas certas para acesso por exceção no Dataverse — desde que usados como exceção, não como arquitetura. Quando viram o mecanismo principal de autorização, a PrincipalObjectAccess silenciosamente se torna o maior gargalo de performance do ambiente. A regra de ouro: estrutura em roles e business units, exceção em access teams, e todo compartilhamento programático com revogação planejada.
\nSe sua empresa opera model-driven apps ou Dynamics 365 em escala e já sente lentidão difícil de explicar, ou precisa redesenhar um modelo de segurança que virou uma teia de compartilhamentos, a Dynamic Soluções pode ajudar a auditar a POA, racionalizar roles e teams e definir um padrão sustentável de autorização.
\nIn the Dataverse security model, most teams start out solving everything with security roles and business units. But there's a class of problem roles don't handle well: exception-based access, case by case, to specific records — the \"I need this one person to see only this project,\" or \"this opportunity was handed off to another rep to maintain.\" That's where record sharing and access teams come in, two mechanisms that grant granular access without reworking your role design. The catch is that both carry performance and governance traps that only surface at scale.
\nHow sharing works under the hood
\nWhen you share a record (manually in the UI, via GrantAccessRequest in the SDK, or through Power Automate), Dataverse creates a row in the system table PrincipalObjectAccess (POA). Each POA row ties a principal (user or team) to a specific record, with a set of rights (Read, Write, Append, AppendTo, Assign, Share, Delete). This access is additive to what the security role already grants — sharing never removes access, it only adds.
The critical point: POA grows with the number of record × principal combinations. Sharing a record with 1 team of 200 people generates 1 POA row (access is resolved through team membership). Sharing the same record individually with 200 users generates 200 rows. In mass-sharing scenarios — say, a flow that shares every new case with half a dozen users — POA can reach millions of rows, and then every query that needs to evaluate access (nearly all of them) gets slower, because the engine must resolve POA in the execution plan. This is one of the hardest Dataverse performance bottlenecks to diagnose, precisely because the table is invisible in the data model.
\nOwner team, access team, and the automatic mode (access team template)
\nTeams in Dataverse come in two flavors, and confusing them is costly:
\nAnd there's the powerful variant: the access team template. Per table, you define a template with a set of rights (e.g., Read + Write) and enable a \"team members\" subgrid on the form. When a user is added to a record's subgrid, Dataverse creates an invisible access team on demand for that record and shares it with the template's rights. When the last member leaves, the team is removed. This gives per-record access with a clean UX, with no explosion of manual teams — but each membership still becomes a POA row, so volume still matters.
\nWhen to use each mechanism
\nA practical decision guide:
\nGrantAccessRequest/ModifyAccessRequest with volume caution — prefer sharing with a team rather than N users, and revoke access (RevokeAccessRequest) when the condition no longer holds, so you don't leave orphaned POA accumulating.Traps that show up in production
\nShare propagate sharing to child records. In deep hierarchies, a single share can generate a cascade of POA rows you didn't account for.Closing
\nSharing and access teams are the right tools for exception-based access in Dataverse — as long as they're used as the exception, not as the architecture. When they become the primary authorization mechanism, PrincipalObjectAccess silently becomes the environment's biggest performance bottleneck. The golden rule: structure in roles and business units, exceptions in access teams, and every programmatic share with a planned revocation.
\nIf your company runs model-driven apps or Dynamics 365 at scale and is already feeling unexplained slowness, or needs to redesign a security model that has turned into a web of shares, Dynamic Soluções can help audit POA, rationalize roles and teams, and define a sustainable authorization standard.
"}},"pageContext":{"slug":"/blog/dataverse-sharing-access-teams-escala/","previousPost":null,"nextPost":{"frontmatter":{"title":"Power Automate: concurrency control e ApplyToEach em paralelo sem corromper dados"},"fields":{"slug":"/blog/power-automate-concurrency-control-apply-to-each-paralelo/"}}}},"staticQueryHashes":["2269431855"]}