Permissão em tabelas do Dataverse for Teams: o ponto em que o app deixa de ser só um protótipo

Você construiu um app no Teams com Power Apps, conectou as telas, publicou no canal e todo mundo do time consegue abrir. Parabéns: você tem um protótipo funcional. Mas se qualquer pessoa do time pode ver, editar ou apagar qualquer registro, você ainda não tem um app de verdade. Você tem uma planilha compartilhada com cara de app.

O que separa um protótipo de uma ferramenta que a empresa pode adotar sem susto é a permissão de tabelas. É sobre isso que quero falar hoje.

O modelo de segurança que vem de fábricaLink para esta seção

Quando você cria um app dentro de um time no Microsoft Teams, o Power Apps cria um ambiente Dataverse for Teams associado àquele time. A segurança vem pré-configurada com base nos papéis que o Teams já conhece: proprietários, membros e convidados (Microsoft Learn, "Granting permission to tables in Dataverse for Microsoft Teams" ((abre em nova aba))).

Por padrão, proprietários e membros têm acesso total a todos os registros. Convidados podem criar registros, mas não veem os de outras pessoas. Esse padrão é seguro para um protótipo, mas raramente serve para um app real. Um app de RH não pode deixar cada funcionário ver o salário de todo mundo. Um app de registro de ponto não pode deixar um colaborador apagar o registro do colega.

A boa notícia é que você pode mudar isso. E só proprietários do time conseguem fazer essa alteração (Microsoft Learn, "Granting permission to tables in Dataverse for Microsoft Teams" ((abre em nova aba))).

Os quatro níveis de permissãoLink para esta seção

O Dataverse for Teams oferece quatro níveis de permissão por tabela. Cada um resolve um cenário diferente.

Full Access é o padrão para proprietários e membros. Quem tem esse nível enxerga e edita todos os registros da tabela. Use com moderação: só quem realmente precisa de acesso irrestrito deve ter esse nível.

Collaborate é para cenários onde todo mundo precisa ver os registros de todos, mas só pode editar os próprios. Um exemplo clássico são os votos em um app de ideias: você quer que cada pessoa veja quantos votos cada ideia recebeu, mas não quer que ninguém mexa no voto alheio (Microsoft Learn, "Granting permission to tables in Dataverse for Microsoft Teams" ((abre em nova aba))).

Reference é o famoso "só leitura". A pessoa pode abrir e ver os registros, mas não cria, edita nem apaga nada. Perfeito para tabelas de categoria, lista de itens ou qualquer dado de consulta que não deve ser alterado por usuários comuns.

Private é o mais restritivo: cada pessoa vê, edita e apaga apenas os próprios registros. É o nível certo para denúncias, relatos de incidente, preferências pessoais ou qualquer dado que não deva ser exposto a outras pessoas (Microsoft Learn, "Granting permission to tables in Dataverse for Microsoft Teams" ((abre em nova aba))).

Um exemplo práticoLink para esta seção

Pense no app Bulletins, que vem como template no Power Apps para Teams. Nele, a tabela "Bulletin" recebe permissão Reference: todo mundo pode ler os comunicados, mas ninguém (além de quem administra) pode criar ou editar. Já a tabela "Bulletin Read Receipts" recebe Private: cada pessoa marca que leu um comunicado, e ninguém mais vê ou mexe nessa marcação (Microsoft Learn, "Granting permission to tables in Dataverse for Microsoft Teams" ((abre em nova aba))).

Percebe como a mesma aplicação combina níveis diferentes para tabelas diferentes? É assim que se desenha segurança de verdade.

E quando o app precisa sair do timeLink para esta seção

Até aqui falei de pessoas que já são membros do time no Teams. Mas e quando você precisa que o app seja usado por gente que não está naquele time específico? O Dataverse for Teams permite compartilhar o app com um grupo de segurança do Microsoft Entra ID. Essas pessoas entram na categoria "Colleagues with access" e você define as permissões de tabela para elas separadamente (Microsoft Learn, "Set permission and share apps with colleagues" ((abre em nova aba))).

É o que a Microsoft chama de "Broad Distribution". Por exemplo, você construiu um app de inspeção dentro do time da qualidade, mas quer que os inspetores de toda a fábrica usem o app sem precisar adicionar cada um como membro do time. Você compartilha o app com o grupo de segurança "Inspetores" e define que eles têm acesso Reference à tabela de checklist e Private à tabela de inspeções. Pronto: eles preenchem as próprias inspeções sem ver as dos colegas e sem poder alterar o formulário (Microsoft Learn, "Granting permission to tables in Dataverse for Microsoft Teams" ((abre em nova aba))).

Onde o Dataverse for Teams encontra o limiteLink para esta seção

É importante ser honesta sobre o que o Dataverse for Teams não faz. Ele não tem field-level security (proteger coluna específica), não tem auditing, não tem hierarquia de segurança, não tem compartilhamento de registro individual e não tem API access para desenvolvedores (Microsoft Learn, "How are Dataverse for Teams and Dataverse different?" ((abre em nova aba))). O modelo de segurança dele é deliberadamente simples: quatro níveis, aplicados por tabela, mapeados nos papéis do Teams.

Se o seu cenário exige que um gerente veja registros do time inteiro mas um analista veja só os próprios, ou que uma coluna de salário fique invisível para quem não é de RH, o Dataverse for Teams não atende. Nesse ponto, a saída é fazer o upgrade do ambiente para o Dataverse completo, que oferece esses recursos (Microsoft Learn, "How are Dataverse for Teams and Dataverse different?" ((abre em nova aba))). O upgrade está disponível e é o caminho natural quando o app supera a capacidade do ambiente de time.

Antes de publicar, pare e penseLink para esta seção

Na minha experiência, o momento de configurar permissão de tabelas não é depois que o app vaza dados. É antes, na primeira publicação. Sente com o time, desenhe as personas de quem vai usar o app, identifique quais tabelas cada persona precisa ver, quais precisa editar e quais não deveria nem saber que existem. Depois traduza isso nos quatro níveis que o Dataverse for Teams oferece.

Se o desenho de segurança couber nos quatro níveis, ótimo: você tem um app pronto para produção dentro do Teams. Se não couber, talvez seja o momento de planejar o upgrade para o Dataverse. Mas não deixe para descobrir isso depois que alguém apagar uma tabela inteira por acidente.

No seu tenant, confirme quem são os proprietários dos times que têm apps publicados. Se você não for proprietário, peça para um ser. E antes de compartilhar o app com mais gente, abra as permissões de tabela e verifique se cada uma reflete o que aquelas pessoas realmente precisam fazer. Pode ser a diferença entre um app útil e um problema trabalhista.