Bem-vindo ao Microsoft Knowledge Nuggets. Eu sou o Mico Pit. O tópico de hoje é algo que costuma confundir 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. E que 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 escritório. Vendas, atendimento ao cliente e outros apps 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 os dados do Dynamics residem e como uma atualização de cliente pode aparecer no trabalho de vendas, automação e relatórios. Mas antes de falarmos de nomes de produtos, vamos começar com a confusão empresarial que isso resolve. Um lugar compartilhado.

Em vez de cópias separadas. Imagine uma empresa com uma equipe de vendas, uma equipe financeira. Vendas mantém detalhes de clientes em uma planilha. Suporte trabalha uma ferramenta chamada separar. O financeiro tem nomes de clientes em seu próprio sistema. Alguém salva tópicos de e-mail em uma caixa de entrada compartilhada enquanto outra pessoa mantém anotações em uma pasta que ninguém mais encontra. 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 é, assim que um cliente muda seu número de telefone, endereço, nome da empresa, contato principal, os problemas começam. Vendas atualiza a planilha. Suporte não vê alteração. O financeiro continua enviando documentos para o 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 se imagina. Há equipe para comparar registro. Gerentes perguntam por que um relatório não bate com o sistema de vendas. Um agente de suporte abre um chamado para um cliente cujos detalhes já existem em outro lugar, apenas e geralmente diferentes. Ninguém está tentando criar uma bagunça. A bagunça vem das cópias. 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 muitas verificações manuais. Uma mudança em um lugar poderia chegar a outro sistema amanhã, na próxima semana ou nunca. Dataverse dá aos aplicativos de negócios um call compartilhado com 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 abas de planilhas desconexas e abas de planilhas desconexas. Pense nisso como arquivo da empresa, mas que pode ser usado por várias ferramentas aprovadas ao mesmo tempo. Um cliente aparece apenas uma vez no Dataverse. Esse cliente pode aparecer no Dynamics 365 Sales quando o vendedor trabalha em uma negociação. Os mesmos detalhes do cliente podem aparecer no Dynamics 365 Customer Service quando um agente atende a uma solicitação de suporte. Um Power App pode usar as mesmas informações do cliente para um funcionário 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 veem tudo de repente. Acesso ainda precisa de regras e falaremos sobre isso em breve.

Significa que apps aprovados podem trabalhar com as mesmas informações de negócios em vez de criar suas próprias versões concorrentes. É por isso que o Dynamics 365 e o Dataverse se encaixam tão naturalmente. Apps do Dynamics 365 como Sales e o Customer Service usam o Dataverse para armazenar e proteger os dados com os quais trabalham. Mas o ponto é, quando alguém fala em integrar o Dynamics 365 ao Dataverse, geralmente imagina dois produtos separados que precisam de um conector entre eles. Para muitos apps do Dynamics 365, essa não é a situação. Os dados já residem 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 se mantenham atualizados. Você pode construir sobre a mesma base, usando as mesmas informações de negócio 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 apps 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 estoque, 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 lugar comum para os dados de negócios que os apps conectados precisam compartilhar. Detalhes de clientes, trabalhos de vendas, tarefas de suporte, pendências e acompanhamentos. Esses registros podem conviver juntos e uma única fonte que ferramentas aprovadas podem ler da atualização. Então abre esse arquivo comigo. Depois de ver como o Dataverse organiza as informações internas, toda a conexão com o Dynamics 365 se torna muito mais fácil de entender.

O arquivo, tabelas, linhas, colunas e relacionamentos. Vamos abrir esse arquivo. Dentro do Dataverse as informações ficam em tabela. Pense nisso com um arquivo real com gavetas separadas. É. Uma gaveta guarda empresas, outra guarda pessoas e uma terceira guarda solicitações e suporte. Você não joga todo o papel em uma gaveta enorme esperando que alguém possa organizar depois. Cada gaveta tem uma função. Portanto, no Dataverse uma tabela armazena um tipo de informação de novo. Uma tabela de contas geralmente armazena as empresas com as coisas que estão. Uma tabela de contato armazena pessoas físicas. Uma tabela de lead armazena clientes em potencial antes que se tornem clientes reais. Uma tabela de caso armazena solicitações e suporte, enquanto uma tabela de atividade pode rastear trabalhos com chamadas, e-mails, agendamentos e tarefas. Essas são tabelas padrão. A Microsoft as incluiu, porque a maioria das empresas precisa controlar 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 toda empresa também tem seu próprio trabalho. Uma empresa de treinamento pode precisar rastrear cursos e certificados. Uma empresa do setor imobiliário pode precisar de prédios, unidades e inspeções. Uma fabricante pode rastrear verificações de equipamentos ou visitas de serviço. 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 arquivo e colocar uma etiqueta clara nela. Agora, cada tabela contém linhas. Uma linha é um item dentro dessa gaveta. Por exemplo, uma linha na tabela de contato poderia representar a Maria Gomes, uma pessoa, uma empresa cliente. A linha dela armazena 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 àquele local. Portanto, uma coluna de e-mail espera um endereço de e-mail e uma coluna de status pode conter opções de status aprovado. É assim que as informações de negócio ganham uma estrutura confiável. 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 alguém pode nem inseri-lo. Com uma tabela de contato 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 exibir as caixas certas, um relatório pode agrupar contatos por status e uma automação pode reagir quando o proprietário é alterado.

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 atenderem a sua necessidade de 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. Em seguida, adicione tabelas personalizadas apenas onde 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 e uma terceira de contato de parceiro e eu. 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. Contato pertence a uma conta. Maria trabalha para Contoso. 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 contatos e a tabela de contas. Maria se vincula a Contoso e esse vínculo é importante porque as informações da empresa permanecem com a empresa. Se a Contoso mudar de endereço, alguém atualiza a linha da conta uma vez, se todos os contatos relacionados ainda podem apontar para a mesma empresa sem carregar sua própria cópia antiga. Relacionamentos também conectam um caso de suporte ao cliente que o abriu. Eles podem conectar uma oportunidade de venda às ligações, e-mails, reuniões e tarefas relacionadas a que negócio. Quando um vendedor abre uma oportunidade, ele pode ver as atividades conectadas a ela, em vez de pesquisar em notas e calendários não relacionados.

A informação tem contexto. Você não está apenas olhando para o número de casos, você vê a qual cliente ele pertence. Você não está apenas visualizando o 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 nota sobre nomenclatura. Antes de você ler guias mais antigos ou assistir a vídeos antigos, você pode ouvir as palavras entidade, campo e registro. Esses são termos mais antigos do Dataverse. A Microsoft agora usa tabela em vez de entidade, coluna em vez de campo e linha em vez de registro. O significado não mudou. Um guia 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 encontrou 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. O Dataverse só funciona quando as pessoas certas podem trabalhar com os dados de forma segura. Um representante de vendas precisa dos detalhes 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 porção. Eles não devem ver as minhas informações. Pense em um registro de cliente com uma nota de contato privado, um 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 eles não consigam trabalhar cria um problema diferente. O Dataverse oferece controles para isso. E o primeiro controle começa com a identidade. Ao entrar com sua conta da empresa, Microsoft Entry ID identifica você.

Pense no Entry ID como a recepção na entrada do escritório. Você chega, mostra seu crachá e o recepcionista verifica quem você é a entrada. O Dataverse usa essa identidade para saber qual usuário está trabalhando com os dados. Ele não para na pergunta, esta pessoa tem permissão para entrar. Ele também pergunta, o que esta pessoa pode fazer depois de 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 ao cliente 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 escolher informações importantes de clientes. Um agente de suporte pode criar e atualizar casos, mas não terá uma oportunidade de venda.

As permissões podem abranger, ler, criar, alterar e excluir linhas. Isso significa que o acesso não depende de alguém lembrar quais botões ocultarem cada aplicativo. As permissões estão junto com os 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. Ambos usam a mesma tabela de conta. Eles apenas não veem a mesma parte dela. Essa configuração ajuda as pessoas a focarem em seu próprio trabalho, enquanto dá aos gerentes a visão de que precisa. Também reduz a chance de alguém abrir informações de um cliente que não precisa acessar. Algumas informações precisam de proteção ainda mais.

A segurança em nível de coluna pode proteger colunas individuais dentro de uma tabela. Talvez um usuário possa abrir uma linha de cliente, mas não deva ver o identificador pessoal, um valor de salário, dados bancários ou bancários ou uma nota financeira privada. A linha do cliente permanece disponível para o trabalho que eles precisam fazer. A coluna protegida permanece restrita. Para empresas maiores, unidades de negócios podem criar fronteiras entre partes da organização. Uma empresa pode separar regiões, divisões ou subsidiárias que trabalham com diferentes grupos de clientes. As unidades de negócios ajudam a moldar como o acesso funciona através dessas fronteiras. Isso não significa que toda empresa por segurança é complicado. Uma equipe pequena pode precisar apenas de algumas funções claras. Uma empresa maior pode precisar de mais camadas, pois suas equipes, regiões e responsabilidades diferem.

O ponto é que o Dataverse consegue adaptar o acesso a como a gente 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 exigir um motivo ao encerrar um caso. Ela também pode alterar o que os usuários veem com base nas informações que inserem. A mesma regra se aplica a todos os aplicativos que usam essa tabela. Isso é importante porque você não quer um aplicativo aceitando dados incompletos enquanto outros rejeita. A regra pertence às informações de negócio, numa tela que por acaso exibe. O Dataverse também pode executar a lógica nos bastidores para ajudar a manter os processos de negócio consistente. O detalhe que você precisa lembrar é simples. Os dados vêm com regras, não apenas com armazenamento.

Portanto, a base inclui as informações, as pessoas autorizadas a trabalhar com elas e as regras que as mantenham utilizáveis. Uma vez que o Dynamics 305 funciona sobre essa mesma base, ele não precisa de uma ponte tradicional apenas para acessar seus próprios dados de negócio. O que a integração do Dynamics 306 realmente significa? A maioria das pessoas ouve integração do Dynamics 306 com o Dataverse. Você 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 rodar e torce para que nada falhe no processo. Essa imagem faz sentido para muitas ferramentas. Mas aqui, no TMS, para o Dynamics 306 e 365 Sales e o Dynamics 306 e 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 dois bancos de dados separados, passando linhas de clientes de um lado para o outro apenas para se entenderem.

Eles trabalham a partir das mesmas informações de negócio desde o início. Vamos tornar isso concreto. Imagine que você é um vendedor e cria uma nova empresa no Dynamics 365 Sales. Se 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 pode trabalhar com exatamente a mesma empresa e detalhes de conta. Ninguém precisa exportar uma lista de vendas ou criar o cliente novamente dentro de uma ferramenta de suporte separado. 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 no TMS. Vendas vê o negócio, o suporte vê o chamado e ambas as equipes trabalham em torno do mesmo cliente. Bem, isso não significa automaticamente que todas as telas sejam idênticas ou que toda a equipe siga o mesmo processo.

Vendas precisa de leads, oportunidades, chamadas e reuniões. O atendimento ao cliente precisa de chamados, filas e histórico de serviço. Cada aplicativo do Dynamics 365 oferece às pessoas ferramentas feitas total. Embora as informações comerciais subjacentes possam se conectar, onde for necessário o que as pessoas geralmente querem dizer quando falam sobre a integração do Dynamics 365 e do Dataverse. Não se trata apenas de mover dados do ponto A para o ponto B. Tudo se resume a aplicativos que trabalham com as mesmas linhas, relacionamentos, regras e controles de acesso desde o início. Vamos percorrer 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 uma oportunidade. Chamadas, e-mails, agendamentos e tarefas podem ser conectados 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 chamado suporte pode ser conectado de volta a esse mesmo cliente. O agente de suporte não vê apenas um nome e um endereço de e-mail. Ele pode trabalhar no 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 entrar em uma conversa de renovação sem saber que é um problema. Um relacionamento com o cliente pode apoiar diferentes tipos de trabalho, o que é muito mais útil do que simplesmente manter o nome de cliente correspondente em dois sistemas. Você também pode ouvir a expressão modelo de dados comum, às vezes abreviada, como CDM. Ai, não deixe que o nome faça soar mais misterioso do que realmente é. Significa simplesmente que a Microsoft fornece padrões de tabelas de negócios comuns para coisas que muitas empresas rastreiam, como contas, contatos, atividades e chamados.

Esses padrões dão aos aplicativos baseados no Dynamics 365 e no Dataverse uma linguagem inicial compartilha. 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, quando necessário, mas não precisa 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 de negócio. 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 visita após o agendamento. Você pode criar um Power App que funcione com as mesmas tabelas do Dataverse já usadas 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 vendas ou atendimento já usam, sujeitos às regras de segurança que abordamos anteriormente. Para trabalhos comerciais mais estruturados, você pode criar um aplicativo baseado em modelo. 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 visualizações e aplica funções de segurança. O Power Apps usa então essa estrutura para criar uma experiência de aplicativo de negócios funcional. Pense nisso como organizar uma bancada de trabalho com as ferramentas e materiais que sua equipe realmente usa. Tabelas descrevem o trabalho. Os relacionamentos conectam as peças. Os formulários permitem que as pessoas insiram e revisem detalhes. As visualizações ajudam a encontrar as linhas de impressão.

A segurança decide o que cada pessoa pode abrir ou alterar. Um aplicativo baseado em modelo pode coexistir com o Dynamics 365 porque ambos funcionam com o Dataverse. Talvez o Dynamics 365 Seus gerencie todo o processo de vendas, enquanto um aplicativo baseado em modelo menor oferece 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, esse acesso ainda requer cuidado. Só porque um aplicativo pode trabalhar com uma tabela do Dataverse não significa que todo usuário deve editar cada linha ou ver cada coluna. O acesso a linhas e as regras de negócio ainda controlam o que acontece. Um aplicativo de campo pode oferecer a alguém exatamente os detalhes e ações do cliente de que precisa, sem expor o restante da empresa ou os dados. 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 trabalhar a partir da mesma base compartilha. Uma vez que você vê isso, a próxima pergunta fica clara. O que mais você pode fazer com essa mesma atualização de cliente em toda a plataforma conectada da Microsoft? Como a plataforma conectada funciona o trabalho real? Uma atualização compartilhada de cliente torna-se útil quando as ferramentas ao redor podem ser... Power Automate gerencia o trabalho de acompanhamento, monitorando uma alteração em uma linha do Dataverse e iniciando uma ação quando essa mudança ocorre. Por exemplo, um novo lead entra no Dynamics 365 Sales. Um fluxo pode notificar o vendedor atribuído, postar uma mensagem no Teams ou criar uma tarefa de acompanhamento. Ninguém precisa monitorar uma caixa de entrada do diretor. O lead muda e a próxima etapa começa automaticamente. Power Automate não precisa de uma cópia separada do lead apenas para realizar esse trabalho.

Ele pode reagir à linha Dataverse usando os mesmos detalhes de cliente e propriedade que o aplicativo de vendas usa. Isso mantém a automação próxima ao processo de negócios, 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 essas equipes vejam o trabalho acontecendo sem criar novas exportações de planilhas toda sexta-feira à tarde. O relatório extrai dados de negócios que as pessoas já utilizam. Isso significa que um gráfico de pipeline pode mudar conforme as oportunidades avanças. O painel de casos pode mostrar a carga de trabalho atual à medida que os agentes atualizam os casos.

O ponto agora é que um painel substitui a necessidade de pessoas verificarem os detalhes. Ele oferece uma visão mais clara do trabalho antes que elas decidam o que precisa de atenção. Power Apps adiciona outro caminho, o mesmo processo. Imagine um trabalhador de campo chegando ao local do cliente. Ele não precisa de toda a experiência de vendas do Dynamics 365. Ele pode apenas precisar encontrar o cliente, revisar os detalhes da visita, confirmar o que aconteceu e adicionar uma nota ou foto ou foto. Power App Focado pode oferecer a ele essa experiência mais simples. Pode precisar de um aplicativo para revisar contratos de clientes. Um gerente pode precisar de um aplicativo simples para aprovar sua instância. 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 encaixa no seu dia a 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. O 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 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. Deixe a Auton colocar as peças em um fluxo diário. Um novo lead entra no Dynamics 365. Uma regra de atribuição verifica quem deve ser o responsável, talvez com base na região ou no produto. O responsável recebe uma mensagem no Teams através de um fluxo do Power Automate para que saiba que é trabalho guardado.

À medida que o vendedor atualiza o lead e o move pelo processo de vendas, o painel do Power BI muda para mostrar à equipe como está o pipeline da Automo. Uma atualização inicia um trabalho útil em vários lugares. Power Automate move o trabalho de uma etapa para a próxima. O Power BI ajuda as pessoas a visar o trabalho. O Power Apps oferece às equipes uma forma focada de participar. O Dataverse mantém as informações de negócios organizadas e seguras enquanto essas ferramentas realizam o seu trabalho. Essa diferença é importante. A automação não é o sistema de arquivos e um painel. Não é o banco de dados de clientes. Cada ferramenta tem uma função separada, mas todas podem trabalhar a partir da mesma função. Saber disso ajuda a escolher a ferramenta certa, em vez de tratar cada planilha ou lista simples como se deve se gerir todo um processo de negócio.

Quando o Dataverse encaixa, o que ele não substitui? Aqui está o ponto principal. Colhe o Dataverse quando várias pessoas e aplicativos precisarem trabalhar com dados de negócio conectado. Você precisa de regras de acesso claras e processos repetíveis? O Dataverse lida com isso, mas não substitui todo o resto. O Excel continua sendo sua escolha para análises pessoais e listas rápidas. As listas do SharePoint funcionam bem para acompanhamento simples de equipe. 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 aplicativos do Dynamics 365 e 5 automações e relatórios, sem criar outra cópia, é aí que ele se destaca. Mas conclusão, uma base e muitas ferramentas de negócio. 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 a base comum.

Inscreva-se no Microsoft Knowledge Nuggets em M365 para mais guias em linguagem simples sobre Dynamics 365, Power Platform e Microsoft 365. Depois, assista o nosso episódio sobre aplicativos baseados em modelos para ver como as tabelas do Dataverse se transformam em um aplicativo de negócios funcional. Então, vamos lá.