Bem-vindos ao Microsoft Knowledge Nuggets. Eu sou o Mopetes. O tópico de hoje é algo que muitas vezes confunde as pessoas. O que exatamente é o Dataverse? É um banco de dados, um aplicativo ou algum serviço oculto do Dynamics 365 que só o pessoal de TI precisa entender? Aqui está a definição mais simples. O Dataverse é a base de dados compartilhada por trás de muitas experiências do Dynamics 365. Pense no Dynamics 365 como um prédio comercial. Vendas, atendimento ao cliente e outros aplicativos são as salas onde as pessoas trabalham, enquanto o Dataverse é o sistema de arquivos e as regras por trás das paredes. Ao final deste episódio, você saberá onde residem os dados do Dynamics e como uma atualização de cliente pode aparecer no trabalho de vendas, automação e relatórios. Mas antes de falarmos sobre nomes de produtos, vamos começar pela bagunça nos negócios. Isso resolve o problema. Um local compartilhado.

Em vez de cópias separadas. Imagine uma empresa com uma equipe de vendas, uma equipe de suporte e uma equipe financeira. Vendas mantém detalhes dos clientes em uma planilha. Suporte trabalha uma ferramenta separada. Financeiro tem os nomes dos clientes em seu próprio sistema. Alguém salva tópicos de e-mail em uma caixa compartilhada, enquanto outra pessoa mantém notas em uma pasta que ninguém mais consegue encontrar. O mesmo cliente agora existe em cinco lugares. Essa configuração parece normal no início, porque cada equipe vê apenas a parte do trabalho à sua frente. Mas o ponto é o seguinte. Assim que um cliente muda seu número de telefone, endereço, nome da empresa ou contato principal, os problemas começam. Vendas atualiza a planilha. Suporte não vê a mudança. Financeiro continua enviando documentos para endereço antigo. Então alguém exporta uma lista, limpa manualmente, envia por e-mail e, de repente, três pessoas acreditam que suas cópias são as corretas.

Em qual lista você deve confiar? Essa pergunta desperdiça mais tempo do que você pode imaginar. A equipe para procomparar registro. Gerentes perguntam por que um relatório não coincide com o sistema de vendas. Um agente de suporte abre um chamado para um cliente cujos detalhes já existem em outro lugar, apenas ligeiramente diferentes. Ninguém está tentando criar uma bagunça. A bagunça vem da escola. Há 20 anos, sistemas separados significavam servidores separados, bancos de dados separados e equipes separadas mantendo suas próprias informações. Conectá-los exigia trabalho personalizado, importações agendadas e muita verificação manual. Uma mudança em um lugar poderia chegar a outro sistema amanhã, na próxima semana ou nunca. O Dataverse oferece aos aplicativos de negócio um local compartilhado para esse tipo de informação. Em termos simples, o Dataverse é a plataforma de dados em nuvem da Microsoft para informações de negócios.

Ele armazena essas informações em tabelas estruturadas, para que os dados tenham um formato claro, em vez de viverem como notas aleatórias, arquivos soltos e guias de planilha desconectadas. Pense nisso como um arquivo da empresa, mas que várias ferramentas aprovadas podem usar ao mesmo tempo. O cliente aparece apenas uma vez no Dataverse. Esse cliente pode aparecer no Dynamics 365 Sales quando um vendedor trabalha em uma negociação. Os mesmos detalhes do cliente podem aparecer no Dynamics 365 Customer Service quando um agente atende a um pedido de suporte. Powered App pode usar as mesmas informações do cliente para um técnico de campo ou gerente de conta sem que ninguém precise copiar os dados para um novo app antes. Uma linha de cliente, um ponto de referência compartilhado. Isso não significa que todas as equipes vejam tudo de repente. O acesso ainda precisa de regras e chegaremos nisso em breve.

Significa que os aplicativos aprovados podem trabalhar com as mesmas informações de negócio em vez de criar suas próprias versões concorrentes. Por isso que o Dynamics 365 e o Dataverse se encaixam tão naturalmente. Aplicativos do Dynamics 365, como Sales e Customer Service, usam o Dataverse para armazenar e proteger os dados com os quais trabalham. Mas aqui está a questão. Quando alguém fala sobre integrar o Dynamics 365 ao Dataverse, geralmente imagina dois produtos separados que precisam de um conector entre eles. Para muitos aplicativos do Dynamics 365, os dados já vivem no Dataverse. Você não está extraindo uma lista de clientes do Dynamics 365, copiando-a para outro banco de dados e esperando que ambos os lados fiquem atualizados. Você pode construir sobre a mesma base, usando as mesmas informações de negócios que o Dynamics 365 já utiliza. Isso muda a conversa. Em vez de perguntar, como sincronizamos essas duas listas de clientes?

Você pode perguntar quais pessoas e aplicativos precisam trabalhar com este registro de cliente e o que cada um deve ter permissão para fazer. O Dataverse não substitui todos os sistemas que uma empresa possui. Uma empresa ainda pode usar software financeiro, ferramentas do setor, sistemas de armazém, sites ou aplicativos mais antigos que mantêm seus próprios dados. O Dataverse não é uma cola mágica que remove todos os sistemas externos da noite para o dia. O que ele oferece é um local comum para os dados de negócio que os aplicativos conectados precisam compartilhar. Detalhes do cliente, trabalho de vendas, trabalho de suporte, tarefas e acompanhamentos. Esses registros podem conviver juntos com uma única fonte que as ferramentas aprovadas podem ler. Então, abre esse arquivo comigo. Ao ver como o Dataverse organiza as informações, toda a conexão do Dynamics 365 se torna muito mais fácil de entender.

As tabelas, linhas, colunas e relacionamentos do arquivo. Vamos abrir esse arquivo. Dentro do Dataverse, as informações ficam em tabelas. Pense nisso com um arquivo real, com gavetas separadas. Uma gaveta guarda empresas, outra guarda pessoas e uma terceira guarda pedidos de suporte. Você não joga cada papel em uma gaveta enorme, esperando que alguém consiga organizar tudo depois. Cada gaveta tem uma função. No Dataverse, uma tabela armazena um tipo de informação de negócio. Uma tabela de contas geralmente armazena as empresas com as coisas de trabalho. Uma tabela de contatos armazena pessoas físicas. Uma tabela de leads armazena clientes em potencial antes que se tornem clientes reais. Uma tabela de casos armazena solicitações de suporte, enquanto uma tabela de atividades pode rastrear trabalhos como chamadas, e-mails, compromissos e tarefas. Essas são as tabelas padrão. A Microsoft as inclui, porque a maioria das empresas precisa acompanhar clientes, pessoas, trabalhos e conversas.

Você não precisa começar inventando uma nova tabela para algo comum quando uma tabela padrão já serve ao propósito. Mas cada empresa também tem o seu próprio trabalho. Uma empresa de treinamento pode precisar rastrear cursos e certificados. Uma empresa imobiliária pode precisar de edifícios, unidades e inspeções. Uma fabricante pode rastrear verificações de equipamentos ou visitas de seguro. Nesses casos, você pode criar tabelas personalizadas que correspondam ao trabalho que sua empresa realmente faz. Pense em uma tabela personalizada como adicionar uma nova gaveta ao armário e dar uma etiqueta clara. Agora, cada tabela contém linhas. Uma linha é um item dentro dessa gaveta. Por exemplo, uma linha na tabela de contatos poderia representar a Maria Gomes uma pessoa, em uma empresa cliente. A linha dela mantém seus próprios detalhes, separados de todos os outros contatos no sistema. Colunas descrevem os detalhes que você deseja manter para cada linha.

A linha de contato da Maria pode ter colunas para nome, sobrenome, endereço de e-mail, número de telefone, cargo, empresa, proprietário do registro e status. Uma coluna define o tipo de informação que pertence a que lugar. Portanto, uma coluna de e-mail espera o endereço de e-mail e uma coluna de status pode conter as opções de status aprovadas. É assim que as informações de negócio ganham uma forma de confiar. Sem colunas, uma pessoa pode digitar um número de telefone em uma caixa de notas. Outra pode adicioná-la a um campo de nome e outra pessoa pode nem inseri-lo. Com uma tabela de contatos clara, todos trabalham com o mesmo conjunto de detalhes nos mesmos lugares. Essa estrutura também ajuda os aplicativos a entenderem os dados. Um formulário pode mostrar as caixas certas, um relatório pode agrupar contatos por status e uma automação pode reagir quando um proprietário muda. A informação não é apenas armazenada, ela possui rótulos que dizem as ferramentas conectadas o que cada parte significa.

Comece com as tabelas padrão sempre que elas corresponderem às necessidades do seu negócio. Se você vende para empresas, contas e contatos já descrevem um padrão que a maioria das pessoas entende. Se você lida com suporte ao cliente, os casos oferecem um ponto de partida. Então, adicione tabelas personalizadas apenas quando sua empresa tiver informações que não se encaixam nos padrões integrados. Isso evita um problema comum. Criar cinco tabelas diferentes que significam a mesma coisa, cliente. Uma equipe chama de cliente, outra chama de cadastro de clientes, uma terceira chama de contato de parceiro IU. Logo, as pessoas não sabem qual tabela devem usar. Tabelas padrão claras e tabelas personalizadas bem nomeadas mantêm o arquivo compreensível à medida que mais pessoas utilizam. A próxima parte é onde essas gavetas começam a trabalhar junto. Um contato pertence a uma conta. Maria trabalha para a Contoso Luta.

Em vez de digitar o endereço, o telefone principal e os detalhes da empresa da Contoso na linha da Maria novamente, o Dataverse pode criar um relacionamento entre a tabela de contato e a tabela de conta. Maria está vinculada à Contoso, e esse vínculo é importante porque as informações da empresa permanecem com a empresa. Se a Contoso mudar o endereço do escritório, alguém atualiza a linha da conta apenas uma vez. Cada contato relacionado ainda pode apontar para a mesma empresa sem carregar sua própria cópia desatualizada. Os relacionamentos também conectam um caso de suporte ao cliente que o abriu. Eles podem conectar uma oportunidade de vendas a chamadas, e-mails, reuniões e tarefas relacionadas a esse negócio. Quando o vendedor abre uma oportunidade, ele pode ver a atividade conectada a ela, em vez de pesquisar em notas e calendários não relacionados. As informações têm contexto. Você não está apenas olhando para um número de cara.

Você pode ver a qual cliente ele pertence. Você não está visualizando apenas um contato. Você pode ver a empresa conectada a essa pessoa. Esses links mantêm os dados úteis sem a necessidade de digitar repetidamente os mesmos fatos em vários lugares. Uma pequena observação sobre nomenclatura antes de você ler guias ou assistir a vídeos mais antigos. Você pode ouvir as palavras entidade, campo e registro. Esses são termos mais antigos da tabela. A Microsoft agora usa a tabela em vez de entidade, coluna em vez de campo e linha em vez de registro. O significado não mudou. Um guia mais antigo que diz para você criar uma entidade está falando sobre criar uma tabela, um campo é uma coluna e um registro é uma linha. Conhecer ambos os conjuntos de palavras evita que você pense que encontram um produto diferente. Portanto, as tabelas organizam as informações e os relacionamentos as conectam. Mas um arquivo bem organizado ainda precisa de controles.

Alguém deve decidir o que as pessoas podem inserir, alterar e acessar com segurança. As regras e a recepção por trás dos dados. Dados compartilhados só funcionam quando as pessoas certas podem trabalhar com eles com segurança. Um representante de vendas precisa do cliente. Um agente de suporte precisa do histórico de casos. Um gerente precisa de uma visão mais ampla. E um parceiro externo pode precisar de acesso apenas a uma pequena parte do processo. Eles não devem ver todos a mesma informação. Pense em um registro de cliente com uma nota de contato privada, preço negociado e um caso de suporte aberto. Dar acesso total a cada usuário criaria riscos rapidamente. Restringir todos tão rigidamente que não consigam trabalhar cria um problema diferente. O Dataverse oferece controles para isso. O primeiro controle começa com a identidade. Ao entrar com sua conta corporativa, o Microsoft EntraID identifica você.

Pense no EntraID com uma recepção na entrada do escritório. Você chega, mostra seu crachá e o recepcionista verifica quem você é antes de permitir a entrada. O Dataverse usa essa identidade para saber qual usuário está trabalhando com os dados. Ele não para ao perguntar se essa pessoa tem permissão para entrar. Ele também pergunta o que essa pessoa pode fazer depois que entrar. É aí que entram as funções de segurança. Uma função de segurança é um conjunto de permissões vinculado a um cargo ou responsabilidade. Você pode criar uma função para a equipe de vendas, outra para agentes de atendimento e outra para gerentes. Cada função pode controlar o acesso a uma tabela. Por exemplo, um representante de vendas pode ter permissão para ler, criar e atualizar contas, contatos, leads e oportunidades. Eles podem não ter permissão para excluir informações importantes de clientes. Um agente de suporte pode criar e atualizar casos, mas não alterar uma oportunidade de vendas.

As permissões podem cobrir a leitura, criação, alteração e exclusão de linhas. Isso significa que o acesso não depende de alguém se lembrar de quais botões ocultar em cada aplicativo. As permissões residem nos próprios dados. Portanto, as mesmas diretrizes se aplicam onde quer que esses dados do Dataverse apareçam. Então, você pode restringir o acesso ainda mais. A segurança em nível de linha decide com quais linhas individuais uma pessoa pode trabalhar. Um representante de vendas pode ver apenas os clientes que possui, enquanto um gerente de vendas pode ver as linhas de clientes de toda a sua equipe. Ambas as pessoas usam a mesma tabela de contas. Elas apenas não veem a mesma parte dela. Essa configuração ajuda as pessoas a focarem em seu trabalho, dando aos gerentes a visão necessária. Também reduz a chance de alguém abrir informações de um cliente que não precisa acessar. Algumas informações precisam de uma proteção ainda mais rigorosa.

A segurança em nível de coluna pode proteger colunas individuais dentro de uma tabela. Talvez um usuário possa abrir a linha de um cliente, mas não deva ver o identificador pessoal, salário, dados bancários ou notas financeiras privadas. A linha do cliente permanece disponível para o trabalho que precisam fazer. A coluna protegida permanece restrita. Para empresas maiores, as unidades de negócio podem criar divisões entre partes da organização. Uma empresa pode separar regiões, divisões ou subsidiárias que trabalham com grupos de clientes diferentes. As unidades de negócios ajudam a definir como o acesso funciona entre essas divisões. Isso não significa que toda empresa tem segurança complicado. Uma equipe pequena pode precisar apenas de algumas funções, claro. Uma empresa maior pode precisar de mais camadas, porque suas equipes, regiões e responsabilidades diferem. A questão é que o Dataverse pode combinar o acesso à forma como a empresa realmente funciona.

O controle de acesso protege quem pode alcançar os dados, mas as regras também protegem a qualidade dos dados em si. Uma regra de negócios pode exigir que alguém insira um número de telefone antes de salvar um novo contato. Ela pode verificar uma condição, como exige o motivo quando um caso é encerrado. Ela também pode alterar o que os usuários veem, com base nas informações que eles inserem. A mesma regra se há aplicativos que usam essa tabela. Isso é importante porque você não quer que um aplicativo aceite dados incompletos enquanto outros rejeita. A regra pertence às informações de negócios, não a uma tela que por acaso exibe. O Dataverse também pode executar lógica nos bastidores para ajudar a manter os processos de negócios consistentes. O detalhe que você precisa lembrar é simples. Os dados vêm com regras, não apenas armazenamento. Portanto, a base inclui as informações das pessoas autorizadas a trabalhar com elas, as regras que as mantêm utilizáveis.

Como o Dynamics 365 funciona nessa mesma base, ele não precisa de uma ponte tradicional apenas para acessar seus próprios dados de negócios. O que a integração do Dynamics 365 realmente significa? A maioria das pessoas ouve integração do Dynamics 365 com o Dataverse e imagina dois sistemas separados conectados por um conector. Um sistema mantém os dados do cliente, outro sistema precisa de uma cópia, então alguém configura uma sincronização, espera ela ser executada e torce para que nada falhe no caminho. Essa imagem faz sentido para muitos achamentos. Mas aqui está a questão. Para o Dynamics 365 Sales e o Dynamics 365 Customer Service, a conexão é muito mais próxima do que isso. Esses aplicativos usam o Dataverse como sua base de dados compartilhada. Eles não são bancos de dados separados, trocando linhas de clientes apenas para se entenderem. Eles trabalham com as mesmas informações de negócio desde o início.

É o seguinte,

você é um vendedor e cria uma nova empresa no Dynamics 365 Sales, adiciona o contato principal e começa a trabalhar em um possível negócio. Esses detalhes tornam-se imediatamente parte dos dados compartilhados que o aplicativo usa. Mais tarde, esse cliente entra em contato com o suporte. O agente de suporte trabalhar com exatamente a mesma empresa e detalhes de contato. Ninguém precisa exportar uma lista de vendas ou criar o cliente novamente em uma ferramenta de suporte separada. O agente simplesmente conecta o caso de suporte a esse cliente e vê o histórico que o ajuda a entender o que está acontecendo. É, o time de venda gosta. O time de suporte vê o caso e ambas as equipes trabalham em torno do mesmo cliente. Isso não significa que toda tela seja idêntica ou que toda equipe siga o mesmo processo. Vendas precisa de leads, oportunidades, chamadas e reuniões. O atendimento ao cliente precisa de casos, filas e histórico de serviço.

Cada aplicativo do Dynamics 365 oferece às pessoas função. Quantas informações de negócios subjacentes podem se conectar onde for a informação? Essa base compartilhada é o que as pessoas costumam querer dizer ao falar sobre a integração do Dynamics 365 e Dataverse. Não se trata apenas de mover dados do ponto A para o ponto B. Trata-se de aplicativos trabalhando com as mesmas linhas, relacionamentos, regras e controles de acesso. Desde o início, vamos acompanhar uma jornada de venda simples. Um lead chega por meio de um site ou de um evento. Um vendedor trabalha com esse lead, aprende mais sobre a pessoa e transforma o lead em um relacionamento com o cliente e em uma oportunidade. Chamadas, e-mails, compromissos e tarefas podem se conectar a esse trabalho. Assim, a equipe não precisa procurar em ferramentas separadas para montar a história. Se o cliente precisar de ajuda mais tarde, um caso de suporte pode se conectar de volta ao mesmo cliente.

O agente de suporte não vê apenas um nome e um endereço de e-mail. Eles podem trabalhar dentro do contexto do relacionamento com o cliente já identificado. Enquanto isso, a equipe de vendas pode ver que o cliente tem um problema de serviço aberto e evitar uma conversa de renovação sem saber sobre esse problema. O único relacionamento com o cliente pode suportar diferentes tipos de trabalho. Isso é muito mais útil do que simplesmente manter um nome de cliente correspondente em dois sistemas. E você também pode ouvir a frase Common Data Model, às vezes abreviada como CDM. Não deixe que o nome faça isso parecer mais misterioso do que realmente é. Significa simplesmente que a Microsoft fornece padrões comuns de tabelas de negócios para itens que muitas empresas rastreiam, como contas, contatos, atividades e casos. Esses padrões dão ao Dynamics 365 e aos aplicativos baseados no Dataverse, uma linguagem inicial compartilhada.

Uma conta significa uma empresa. Contato significa uma pessoa. Uma atividade rastreia o trabalho em torno de um relacionamento comercial. Você pode ajustar a configuração para a sua empresa e adicionar suas próprias tabelas, onde necessário, sem precisar começar do zero toda vez. Quando um aplicativo entende uma tabela de conta e outro aplicativo usa essa mesma tabela, ambos os aplicativos se referem ao mesmo tipo de informação comercial. Isso também muda o que você pode construir. Suponha que sua equipe de campo precise de um aplicativo simples para pesquisar um cliente, confirmar uma visita e adicionar uma nota após o compromisso. Você pode criar um Power App que funciona com as mesmas tabelas do Dataverse já utilizadas pelo Dynamics 365. Não há necessidade de exportar os clientes para uma nova lista apenas para esse aplicativo. O trabalhador de campo abre o aplicativo, encontra o cliente e atualiza as informações da visita.

Os dados permanecem conectados ao relacionamento com o cliente que as equipes de vendas ou atendimento ao cliente já utilizam, sujeitos às regras de segurança que abordamos anteriormente. Para trabalhos de negócios mais estruturados, você pode criar um aplicativo baseado. Um aplicativo baseado em modelo começa com um modelo de dados. Você escolhe as tabelas do Dataverse, define seus relacionamentos, configura formulários e exibições e aplica funções de segurança. Power Apps usa essa estrutura para criar uma experiência de aplicativo de negócio funcional. Pense nisso como organizar uma bancada de trabalho com as ferramentas e os materiais que sua equipe realmente usa. As tabelas descrevem o trabalho. Os relacionamentos conectam as partes. Os formulários oferecem um local para as pessoas inserirem e revisarem dados. As exibições ajudam a encontrar as linhas que precisam de atenção. Segurança decide o que cada pessoa pode abrir ou alterar.

Um aplicativo baseado em modelo pode coexistir com o Dynamics 365, pois ambos trabalham com o Dataverse. Talvez o Dynamics 365 Sales gerencie todo o processo de vendas, enquanto um aplicativo baseado em modelo menor ofereça aos gerentes de contrato um local focado para acompanhar os acordos com clientes. Ambos podem trabalhar com dados relacionados de clientes sem criar um segundo banco de dados de clientes. É claro que esse acesso ainda requer cuidado. Só porque um aplicativo pode trabalhar com uma tabela do Dataverse não significa que cada usuário deve editar cada linha ou ver cada coluna. O acesso a linhas por função e as regras de negócio ainda controla o que acontece. Um aplicativo de campo pode fornecer a alguém exatamente os detalhes e ações do cliente de que precisa sem expor o restante dos dados da empresa. Portanto, a integração do Dynamics 365 com o Dataverse não é mais um cabo conectando duas salas distantes.

Aplicativos do Dynamics 365, aplicativos personalizados e processos de negócio podem operar a partir da mesma vez que você compartilha. Uma vez que você entende isso, a próxima pergunta se torna clara. O que mais pode usar é essa mesma atualização de cliente em toda a plataforma conectada da Microsoft. Como a plataforma conectada funciona no trabalho real? Uma atualização de cliente compartilhada torna-se útil quando as ferramentas ao seu redor podem responder. Power Automate cuida do trabalho de acompanhamento monitorando uma alteração em uma linha do Dataverse e iniciando uma ação quando essa alteração ocorre. Por exemplo, um novo lead entra no Dynamics 365 Sales. Um fluxo pode notificar o vendedor designado, postar uma mensagem no Teams ou criar uma tarefa de acompanhamento. Ninguém precisa ficar monitorando uma caixa da operadora. O lead é alterado e a próxima etapa é iniciada automaticamente.

Power Automate não precisa de uma cópia separada do lead, apenas para realizar esse trabalho. Ele pode reagir à linha no Dataverse, usando os mesmos detalhes de cliente e de propriedade que o aplicativo de vendas usa, mantendo a automação próxima ao processo de negócio, em vez de depender de alguém para exportar um arquivo e iniciar uma corrente manual de e-mails. Depois há o Power BI. Um gerente de vendas pode querer ver o pipeline atual. Um gerente de atendimento ao cliente pode precisar ver quantos casos chegaram esta semana, quais permanecem abertos ou quais clientes entram em contato com o suporte com mais frequência. Power BI pode gerar relatórios sobre dados de negócios do Dataverse, para que as equipes vejam o trabalho acontecendo sem precisar criar planilhas toda sexta-feira à tarde. O relatório utiliza os dados de negócios que as pessoas já usam. Isso significa que um gráfico de funil pode mudar à medida que as oportunidades...

O painel de casos pode mostrar a carga de trabalho atual conforme os agentes atualizam o chamado. O objetivo não é que um painel substitua as pessoas verificando os detalhes. Ele oferece uma visão mais clara do trabalho antes que decidam o que precisa de atenção. Power Apps adicionam outro caminho ao mesmo processo. Imagine um trabalhador de campo chegando ao local de um cliente. Eles não precisam da experiência completa do Dynamics 365 Sales. Talvez só precise encontrar o cliente, revisar os detalhes da visita, confirmar o que aconteceu e adicionar uma nota ou foto. Um Power App focado pode oferecer a eles essa experiência mais simples. Uma equipe de contas pode precisar de um aplicativo para revisar contratos de clientes. Um gerente pode precisar de um aplicativo simples para aprovar uma solicitação. Cada aplicativo pode focar em uma tarefa trabalhando com as mesmas informações controladas do Dataverse nos bastidores.

A pessoa vê a ferramenta que se adapta ao seu dia. A empresa mantém as informações conectadas. Às vezes essas informações começam fora do Dataverse. Uma empresa pode ter uma lista de uma fonte online que precisa se tornar parte de seus dados de negócio. Power Query pode trazer dados de fontes online suportadas, limpá-los durante a importação e carregá-los na tabela correta do Dataverse. Isso é útil quando uma fonte externa contém informações que suas ferramentas do Dynamics e da Power Platform precisam usar. Você ainda precisa decidir o que pertence ao Dataverse e como isso deve se conectar às tabelas existentes. Importar dados sem esse planejamento simplesmente move a confusão para um novo local. Vamos colocar as peças em um fluxo cotidiano. O novo lead entra no Dynamics 305. Uma regra de atribuição verifica quem deve ser o responsável por esse lead, talvez com base na região. O responsável recebe uma mensagem do Teams por meio de um fluxo do Power Automate para saber que há trabalho esperando.

Conforme o vendedor atualiza o lead e o move pelo processo de vendas, o painel do Power BI muda para mostrar a equipe o funil atualizado. Uma atualização inicia um trabalho útil em vários lugares. Power Automate move o trabalho de uma etapa para a próxima. Power BI ajuda as pessoas a visualizar o trabalho. O Power Apps oferece às equipes específicas uma focada de participar. O Dataverse mantém as informações da empresa organizadas seguras enquanto as ferramentas realizam seus trabalhos. Essa diferença é importante. A automação não é o sistema de arquivos e um painel não é o banco de dados do cliente. Cada ferramenta tem uma função diferente, mas todas podem trabalhar a partir da mesma forma. Saber disso ajuda você a escolher a ferramenta certa em vez de tratar toda a planilha ou lista simples como se devesse gerenciar um processo do negócio inteiro. Quando o Dataverse se encaixa, o que ele não substitui?

A questão é a seguinte. Acolha o Dataverse quando várias pessoas e aplicativos precisarem trabalhar com dados de negócio conectados. Você precisa de regras de acesso claras e processo repetível. O Dataverse lida com isso, mas ele não substitui todo o resto. O Excel continua sendo sua escolha ideal para análises pessoais e listas rápidas. As listas do SharePoint funcionam bem para acompanhamento simples de aqui. E se você é um desenvolvedor que precisa de controle profundo, o SQL continua sendo uma escolha sólida. Então, quando o Dataverse realmente se encaixa? Quando seus dados precisam se conectar entre o Dynamics 365, aplicativos, automações e relatórios sem criar outra cópia? É aí que ele brilha. Agora, uma conclusão, uma base em muitas ferramentas de negócios. Então, aqui está o resumo. O Dynamics 365 e o Dataverse funcionam melhor quando todos os seus dados, regras, segurança, aplicativos, automações e relatórios compartilham uma base comum.

Inscreva-se no Microsoft Knowledge Nuggets, no M13CB5FM, para mais guias em linguagem simples sobre Dynamics 365 Power Platform e Microsoft 305. Pois assista ao nosso episódio sobre aplicativos baseados em modelo para ver como as tabelas do Dataverse se transformam em um aplicativo de negócios funcional. E aí