Dynamics do Zero ao PRO · Lição 12 de 48 · Módulo 2

LIÇÃO 12Relacionamentos entre Tabelas

Dados isolados em tabelas separadas não servem para nada. Relacionamentos são o que conecta um Caso a um Contato, um Contato a uma Conta, e uma Conta a seus Produtos. Esta lição cobre os três tipos de relacionamento do Dataverse e quando usar cada um.

📅 Módulo 2 — Dataverse ⏱ 18 min de leitura 🎯 Nível: Intermediário ✍️ Pablo Maruk
🎯

Resultado desta lição

Ao final, você terá criado um relacionamento 1:N entre Account e Produto Atendido, explorado um relacionamento N:N entre Cases e Contatos, e entenderá como cada tipo de relacionamento gera subgrids e lookups nos formulários.

Os 3 tipos de relacionamento

1:N, N:1 e N:N — quando usar cada um

1:N e N:1 são o mesmo relacionamento: A diferença é de perspectiva. Criado na tabela Conta como 1:N (uma conta para muitos contatos), aparece na tabela Contato como N:1 (muitos contatos para uma conta). O Dataverse cria os dois lados automaticamente ao criar um relacionamento.
Mão na massa

Passo a passo — criando e explorando relacionamentos

  1. Crie o relacionamento 1:N entre Account e Produto Atendido

    Vamos vincular os Produtos Atendidos diretamente à Conta — além do relacionamento com o Caso que já existe.

    → Tabela Account → aba Relationships
    → + New relationship → One-to-many
    Related (many) table: Produto Atendido
    Lookup column display name: Conta do Produto
    Relationship behavior: Referential

    Clique em Done → Save Table.

    Relationship behavior: Referential — ao deletar a Conta, os Produtos Atendidos ficam órfãos (sem Conta vinculada). Parental — ao deletar a Conta, todos os Produtos Atendidos relacionados são deletados também. Use Parental com cuidado: a deleção em cascata pode remover dados importantes.

  2. Verifique o subgrid na Conta

    → make.powerapps.com → Tables → Account → Forms
    → Abra o formulário principal da Conta
    → Adicione um subgrid de Produto Atendido

    Após publicar o formulário, abra qualquer Conta no Customer Service Hub. O subgrid "Produtos Atendidos" aparece — mostrando todos os produtos vinculados àquela empresa cliente.

    Subgrid não apareceu? Verifique se o formulário foi publicado corretamente. No Power Apps, após adicionar o subgrid, clique em Save and Publish e aguarde a confirmação antes de testar no Customer Service Hub.

  3. Explore o relacionamento N:N nativo — Cases e Contatos

    O Dynamics já tem um relacionamento N:N nativo entre Cases e Contacts — o campo "Contact" no caso é na verdade uma referência a um relacionamento N:N (um caso pode ter múltiplos contatos relacionados, além do cliente principal).

    → Tabela Case → aba Relationships
    → Filtre por tipo Many-to-many
    → Observe o relacionamento incident_contacts

    Este relacionamento gera a seção "Contatos Relacionados" no formulário de Caso — onde você pode adicionar múltiplos contatos envolvidos no chamado, além do cliente principal.

  4. Crie um relacionamento N:N customizado — Casos e Produtos

    Um caso pode envolver múltiplos produtos. Um produto pode estar em múltiplos casos históricos. Isso é um N:N.

    → Tabela Case → Relationships → + New relationship → Many-to-many
    Related table: Produto Atendido
    Relationship name: pm_incident_produtoatendido

    Clique em Done → Save Table. O Dataverse cria automaticamente uma tabela intermediária pm_incident_produtoatendido para gerenciar os vínculos.

    Por que o N:N cria uma tabela intermediária? Relacionamentos N:N precisam de uma tabela para armazenar os pares (ID do Caso, ID do Produto). Você nunca vê essa tabela diretamente na interface — o Dataverse a gerencia automaticamente. Mas ela existe no banco de dados e pode ser acessada via OData ou Power Automate.

  5. Vincule Produtos a um Caso via subgrid N:N

    → Formulário do Caso no Power Apps → adicione subgrid de Produto Atendido (via relacionamento N:N)
    → Publique o formulário

    Abra um Caso no Customer Service Hub. No novo subgrid, clique em + Add Existing Produto Atendido. Você pode vincular múltiplos produtos ao mesmo caso — sem duplicar os registros de produto.

    Add Existing vs. + New: Em subgrids N:N, o botão padrão é Add Existing — você vincula um produto que já existe. Em subgrids 1:N, o botão é + New — você cria um produto novo já vinculado ao caso. Essa diferença de UX é reflexo direto do tipo de relacionamento.

  6. Teste a integridade referencial

    Tente deletar uma Conta que tem Produtos Atendidos vinculados (com behavior Referential).

    → Abra a Conta "Indústria ABC Ltda."
    → Clique em Delete na barra de comandos

    O Dynamics vai alertar que existem registros relacionados. Com behavior Referential, ele permite a deleção mas deixa os produtos órfãos. Com Restrict, bloquearia a deleção enquanto houvesse produtos vinculados.

    Não delete a Conta: Este é apenas um teste de observação do comportamento. Cancele a deleção — você vai precisar da Conta nas próximas lições.
Revisão

Checklist

Vale saber

Cascade Delete — cuidado com deleção em cascata

O comportamento Parental ativa a deleção em cascata: ao deletar o registro pai, todos os filhos são deletados. Isso parece conveniente, mas pode ser catastrófico em produção.

Exemplo de risco:
Um usuário deleta acidentalmente uma Conta. Com Parental ativo em todos os relacionamentos, são deletados automaticamente: todos os Contatos, todos os Casos, todas as Atividades e todos os Produtos Atendidos daquela Conta.

Recomendação: Use Referential como padrão. Ative Parental apenas quando tiver certeza absoluta de que os dados filhos não têm valor independente.
Foto de Pablo Maruk
Pablo Maruk
Analista Funcional de Dynamics · 16 anos de TI · EUA & Europa