O vendedor atualiza o endereço de um cliente. Mais tarde, o financeiro abre o mesmo registro e ainda vê o endereço antigo. Então, qual endereço está correto? Por anos, corrigir isso significava alguém exportar dados, editar uma planilha, enviá-la por e-mail e editar a mesma atualização duas vezes em um segundo aplicativo. O DualWrite do Dynamics 365 muda isso. Ele conecta aplicativos de finanças e operações com aplicativos de clientes baseados no Dataverse, para que registros compartilhados como clientes e pedidos permaneçam sincronizados automaticamente. Você está comigo? Eu sou o Milko Peters, da M305FM, e esta pílula de conhecimento explica o DualWrite em termos simples. Abordaremos o que é transferido, como é transferido, onde o DualWrite se encaixa e onde não se encaixa. Primeiro, vamos começar com o problema de negócio que criou a necessidade para ele.

O problema que o DualWrite resolve. Imagine uma empresa onde dois grupos trabalham com o mesmo cliente, mas usam aplicativos completamente diferentes no dia a dia. Aplicativos de finanças e operações cuidam do trabalho de back-off. Isso inclui dinheiro, estoque, produtos, pedidos, compras e acadetos para mim. É aqui que a empresa rastreia. O que vende, o que pode entregar, o que deve e o que um cliente precisa pagar. Aplicativos de clientes focam no trabalho mais próximo ao cliente. Equipes de vendas acompanham leads e criam oportunidade. O atendimento ao cliente lida com dúvidas e casos. O serviço de campo planeja tarefas e envia pessoas locais. Equipes de projeto rastreiam o trabalho prometido no clima. Trabalhos diferentes precisam de telas diferentes. Um vendedor não deveria ter que procurar em uma tela financeira apenas para atualizar um contato após uma ligação. Mas um usuário financeiro precisa de detalhes de cliente pedido que correspondam ao que as vendas veem, afinal, faturas e entregas dependem dessas informações.

Sem uma conexão, um cliente silenciosamente se torna dois registros. Vendas pode listar como Northin Bikes, o financeiro pode listar como Northin Bicycle Company. Um registro tem um novo endereço, o outro identifica faturas para o escritório antigo, antigo. Ambos os registros parecem razoáveis sozinhos, mas já não descrevem o mesmo relacionamento comercial. Pequenos problemas surgem primeiro. Alguém não consegue encontrar um cliente porque o nome está diferente e outro aplicativo. Um representante de vendas promete um preço, verifica o estoque, mas a informação não coincide com o lado operacional. O financeiro precisa processar um pedido, mas os detalhes do cliente exigem uma verificação, um e-mail e outra atualização. Então esses pequenos problemas se acumulam. Alguém exporta dados de clientes para uma planilha. Outra pessoa corrige algumas linhas e importa para outro lugar. Alguém mais insere um novo cliente em ambos os aplicativos porque ninguém sabe qual registro aparecerá primeiro.

Logo há duplicatas, endereços diferentes e mais tempo gasto verificando dados do que usando-os. Nada disso acontece porque as pessoas são de cuidado. Acontece porque os sistemas pedem que as pessoas sejam em conexão. Pessoas copiam dados. Pessoas precisam lembrar qual aplicativo vem primeiro. Pessoas encontram erros depois que eles já chegaram a outra equipe. Essa abordagem funcionava quando os sistemas de negócios eram separados, as equipes aceitavam atraso. Mas quando vendas, serviços, finanças e operações precisam das mesmas informações do cliente durante o dia, uma planilha torna-se uma ferramenta de transferência em eficiência. Pense em uma conversa simples sobre um pedido. O cliente liga para vendas e pergunta quanto vocês podem entregar na próxima semana. Quanto vai custar? A equipe de vendas precisa de detalhes de produto, preço e estoque para responder. Assim que o cliente concorda, finanças e operações precisam das informações corretas do cliente e do pedido para processar a venda.

Ambos os lados precisam dos mesmos. Vendas precisam desses fatos no aplicativo onde o pessoal de vendas trabalha. Finanças e operações precisam deles no aplicativo onde gerenciam pedidos, dinheiro e entrega. O objetivo não é tentar forçar todas as equipes a usarem uma única tela gigante. O objetivo é que os registros compartilhados sigam uma rota clara e acordada. É aí que a gravação dupla do All Right Ensemble. O que é a gravação dupla, afinal? Então, o que exatamente é a gravação dupla? Aqui está a definição mais simples. A gravação dupla é a conexão integrada da Microsoft que mantém dados selecionados, sincronizados entre os aplicativos do Dynamics 365 Finance & Operations e Dataverse. O Dataverse é a base de dados compartilhada por trás de muitos aplicativos de negócios na Microsoft. Dynamics 365 Sales, Customer Service, Field Service e partes do Project Operations usam essa base. O Power Apps e o Power Automate também podem usar.

Você não precisa saber como o Dataverse armazena cada registro para entender a gravação dupla. Apenas pense nela como a área de dados comum lá dos aplicativos de cliente do Dynamics 365. Imagine um prédio comercial com um escritório de atendimento e um setor administrativo. O escritório de atendimento lida com conversas com clientes. Pessoal de vendas, agentes de serviços, trabalhadores de campo. Todos eles precisam de telas que ajudem a conversar com as pessoas, rastrear solicitações e gerenciar o trabalho. O setor administrativo lida com o trabalho que mantém a empresa funcionando. Nosso registro financeiro, estoque, pedidos, compras, entrega. Ambos os setores trabalham para a mesma empresa, mas sem uma conexão adequada entre eles, alguém tem que levar as informações de um lado para o outro. Eles carregam um formulário impresso, enviam um e-mail ou copiam dados para outro sistema. O trabalho ainda é feito, mas demora mais e detalhes podem mudar ao longo do caminho.

A gravação dupla é como uma porta interna com funcionários entre esses dois escritórios. Quando um registro compatível muda de um lado, a gravação dupla passa a alteração relacionada a essa porta para o outro lado. Ele não combina todos os aplicativos gigantes. Vendas ainda pode trabalhar em venda. Finanças ainda pode trabalhar em finanças. Cada equipe mantém as telas criadas para seu trabalho, enquanto informações compartilhadas e selecionadas permanecem conectadas nos bastidores. Palavra suportar é importante. DualWrite não copia cegamente cada parte dos dados em um dos sistemas. Ele funciona através de conexões definidas entre registros que pertencem a um outro. A Microsoft chama essas conexões de mapas de tabela. Uma tabela é simplesmente um lugar onde um aplicativo mantém um tipo de registro. Uma tabela de clientes mantém registro de clientes. Uma tabela de produtos mantém registro de produtos.

Uma tabela de endereço mantém detalhes de endereço. Um mapa de tabela diz ao DualWrite qual tabela no lado de Finanças e Operações se conecta qual tabela no Dataverse. Pense em um mapa de tabela com uma folha de tradução acordada. Uma coluna identifica um registro de um lado. Outra coluna identifica seu registro correspondente do outro lado. O restante da folha explica quais campos pertencem um ao outro. Nosso nome, número de telefone, linha de endereço. Esse acordo estabelece as regras de conexão. Sem ele, dois aplicativos poderiam usar rótulos diferentes ou armazenar o mesmo detalhe em lugares diferentes. Um mapa diz ao DualWrite como esses detalhes se relacionam. Os aplicativos não precisam de pessoa para interpretá-los toda vez. Agora, as pessoas costumam ouvir o nome DualWrite e presumem que isso significa que toda mudança sempre se move nos dois sentidos. Às vezes, sim. Para um mapa bidirecional suportado, uma alteração no Dataverse pode atualizar o registro relacionado no Finance and Operations.

Uma alteração suportada no Finance and Operations também pode atualizar o registro relacionado no Dataverse. Ambos os lados podem participar do mesmo registro compartilhado. Essa é a parte do Aldo. A atualização ocorre quase em tempo real. Ela se move rapidamente à medida que as pessoas trabalham ao invés de esperar por um trabalho agendado que roda durante a noite. Um usuário atualiza um registro suportado e a conexão envia essa atualização enquanto o trabalho ainda está em andamento. Quase tempo real não significa mágica ou atraso zero. Significa que a conexão foi criada por trabalho comercial ao vivo, não por uma troca de arquivos uma vez por dia. Se alguém altera um detalhe, a equipe relacionada não precisa esperar até a manhã seguinte para vê-lo. Isso muda a forma como as equipes podem trabalhar. O FrontOffice pode usar dados provenientes do BackOffice. O BackOffice pode receber atualizações suportadas de aplicativos voltados ao cliente.

Dataverse torna-se a base de dados de um lado, o Finance and Operations permanece a base operacional do outro e o DualWrite mantém os registros compartilhados, aprovados e conectados. Ainda assim, uma porta internativa precisa de regras. Antes de permitir que um registro viaje em ambas as direções, você precisa saber onde esse registro deve começar, quem pode alterá-lo e qual lado deve liderar quando os dois aplicativos discordarem. Quais dados podem ser transferidos e qual sistema é o proprietário? Então, quais registros o DualWrite consegue manter conectado? Os exemplos comuns começam com os registros que muitos departamentos compartilham diariamente. Registro de clientes, endereços, contatos, produtos, fornecedores, detalhes da empresa e informações de referência usadas para finanças e impostos. Pense em um registro de cliente por um momento. Vendas precisa do nome do cliente, contato principal, número de telefone e endereço de entrega.

Financeiro precisa do registro legal do cliente, detalhes de cobrança e informações necessárias para pedidos e faturas. Cada departamento mantém sua própria lista de clientes separada, a empresa gasta tempo comparando registros em vez de atender o cliente. Com os mapeamentos de DualWrite corretos, essas equipes podem trabalhar com detalhes de clientes conectados. Isso não significa que usuários de vendas precisam aprender o aplicativo financeiro de repente. Significa que eles podem trabalhar com informações de clientes no Dynamics 305 Sales, enquanto os usuários do financeiro trabalham com as informações relacionadas no Finance. O cliente permanece reconhecível como o mesmo em ambos os lugares. Endereço importante. Um cliente pode ter um endereço de cobrança, um de entrega e talvez um local onde um técnico precise visitar. Podem ser tratados apenas como textos simples, copiados em uma caixa, pescados em uma caixa, pois cada endereço tem uma função diferente.

O DualWrite suporta a estrutura de registro compartilhada necessária para esse relacionamento. Os contatos seguem o mesmo padrão. Uma empresa cliente pode ter um comprador, um contato de contas a pagar e um gerente de serviços. Vendas precisa saber quem toma as decisões. Financeiro precisa saber para onde direcionar dúvidas de cobrança. Serviço precisa saber quem está aguardando o local. Registros conectados ajudam cada equipe a ver as pessoas ligadas ao cliente sem precisar recriar essas informações em cada aplicativo. Produtos são outro exemplo comum. Um representante de vendas precisa saber o que a empresa vende, qual o custo do produto, se há estoque disponível. Essas respostas geralmente vêm do lado operacional do negócio, pois é onde o produto, estoque, compras e atendimento são gerenciados. Por isso que as informações de produtos geralmente começam em finanças e operações. A equipe de operações cria e prepara um produto lá.

Assim que o produto está pronto para o trabalho com o cliente, o DualWrite pode enviar os detalhes relacionados ao produto para o Dataverse. Os usuários de vendas podem então selecionar e discutir o produto em seu próprio aplicativo sem que alguém precise inserir a lista de produtos uma segunda vez. Isso ajuda as conversas de vendas a permanecerem baseadas no que a empresa realmente pode fornecer. Detalhes de preços e estoque também podem chegar às vendas através dos aplicativos conectados. Em vez de adivinhar se um item existe, se o preço mudou ou se o estoque pode cumprir uma promessa, a equipe de vendas pode trabalhar com informações vinculadas ao lado operacional. Isso não elimina a necessidade de um bom julgamento de vendas. Elimina o motivo evitável para um representante de vendas ligar para o armazém apenas para confirmar detalhes básicos. Informações de fornecedores também podem se conectar onde um processo de negócio precisar dele.

Detalhes da empresa, estruturas organizacionais, dados de referência financeira e dados fiscais podem ser importantes tanto para o lado do cliente quanto para o lado da operação. Os registros exatos dependem dos aplicativos e processos que uma empresa usa, mas o padrão permanece o mesmo. Compartilhe os registros que precisam significar a mesma coisa. Agora, não presuma que todo o registro deve viajar em ambas as direções. Uns aplicativos oferecem superdirecionais. Uma alteração pode começar no Dataverse e ir para o Finance and Operations, ou começar no Finance and Operations e ir para o Dataverse. Essa abordagem funciona para registros em que ambos os lados têm um motivo de negócio adequado para atualizar detalhes aprovados. Outros mapeamentos são as gerenciais e as direções. Produtos nos dão um exemplo útil. Em muitas empresas, o Finance and Operations é responsável pela criação de produtos, pois as operações controlam o mestre de produtos, estoque, unidades e outros detalhes necessários para vender e entregar.

O produto, então, flui para o Dataverse, onde as equipes de vendas e serviço podem usá-lo. Essa é uma regra clara. O produto não precisa de duas equipes criando versões conflitantes. Um lado cria e governa o produto. O outro lado recebe e usa como parte do seu trabalho. Cada registro compartilhado precisa desse tipo de decisão. Onde esse registro começa? Quem pode editar? Se o nome, endereço, preço ou classificação parecer errado, qual equipe o corrige? Essas perguntas parecem simples, mas evitam muita confusão mais tarde. Uma conexão pode mover uma alteração muito rapidamente. Se ninguém concordou sobre quem é o responsável pela alteração, ela pode mover um erro. Com a mesma rapidez. Por um proprietário para o registro e, quando necessário, para detalhes individuais dentro desse registro. Por exemplo, as vendas podem ser responsáveis pelos detalhes de relacionamento do cliente e pelas informações de contato principal.

E as operações podem ser responsáveis pelos detalhes relacionados ao pagamento. E as operações podem ser responsáveis pelos detalhes de produto e estoque. Sua divisão exata depende de como sua empresa trabalha, mas precisa ser documentada e compreendida pelas pessoas que usam os aplicativos. Há também dois termos que você pode ver após a gravação dupla. DualWrite expandiu o Dataverse. Party, Party e Company, Empresa. Um Party é a maneira da Microsoft de lidar com uma pessoa ou organização de forma consistente. Isso ajuda a conectar pessoas, organizações, contatos e endereços sem tratar cada relacionamento como um registro separado e não relacionado. Uma Company ajuda o Dataverse a entender o contexto da empresa de negócios usado pelo Finance & Operations. Você não precisa se tornar um especialista em nenhum desses termos no primeiro dia. Saiba apenas que eles existem, pois o Finance & Operations lida com estruturas de negócios que os aplicativos de clientes precisam reconhecer quando os registros cruzam os dois lados.

Assim que os registros podem trafegar em ambas as direções, o processo em torno desses registros é tão importante quanto os próprios dados, com uma alteração viagem dos aplicativos. Vamos acompanhar uma alteração pelo sistema e ver o que realmente acontece. Um representante de venda está em uma chamada com um cliente que acabou de se mudar para um novo escritório. Durante essa conversa, o representante abre o registro do cliente no Dynamics 306 Sales e atualiza o endereço. Simples, certo? Em seguida, ele salva o registro. É aí que a parte interessante começa. Sales armazena essa alteração no Dataverse, que é o lado de dados, para aplicativos voltados ao cliente. Então, o DualWrite verifica o mapa que conecta as informações de cliente e endereço entre este local e o Finance & Operations. Ele envia alteração correspondente automáticamente. Nada de arquivos de exportação e impasses compartilhados esperando que alguém os pegue.

Ninguém precisa enviar um e-mail para o financeiro dizendo aí, por favor, atualize este endereço. O mapa já sabe quais campos estão vinculados e envia alteração suportada diretamente para o registro do cliente relacionado no Finance & Operations. Assim, o usuário do financeiro pode abrir esse registro mais tarde, ver o endereço atualizado, processar um pedido ou preparar uma fatura sem interrupções. Esse é o resultado prático, simples e direto. Duas pessoas continuam trabalhando em aplicativos diferentes, mas nenhuma precisa redigitar os mesmos detalhes do cliente. O representante de vendas trabalha em uma tela projetada para conversas com o cliente. O usuário do financeiro trabalha em uma tela criada para tarefas financeiras. Cada pessoa vê as informações do cliente de que realmente precisa exatamente onde precisa. E o fluxo funciona na outra direção também. Imagine que o financeiro atualiza informações suportadas do cliente no Finance & Operations.

Digamos que um usuário do financeiro corrija um detalhe que pertence ao registro do cliente operacional. DualWrite usa o mapa correspondente de forma inversa e envia essa atualização para o Dataverse. Então o Sallius ou qualquer outro aplicativo baseado no Dataverse pode captá-la. Essa conexão é síncrona para o trabalho diário normal. Síncrona significa que os aplicativos tentam concluir a atualização relacionada no mesmo momento de trabalho, em vez de deixá-la para um processo em segundo plano que pode rodar 20 minutos depois. Se a conexão não puder concluir a atualização, esse problema precisa de atenção imediata, sem ficar oculto até que alguém note uma divergência. Esse comportamento faz sentido para registro de negócio compartilhado. Você não quer que o endereço de um cliente, detalhes de produto ou outras informações compartilhadas fiquem defasados por horas, fiquem defasados por horas porque um trabalho em lote não fez.

As pessoas tomam decisões com base no que vem na tela agora mesmo. Portanto, a conexão mantém ambos os lados alinhados enquanto o trabalho acontece. Mesmo o trabalho em tempo real às vezes precisa de uma pausa controlada. O Dual Write inclui opções de Reproduzir, Pausar e Recuperar. Reproduzir significa que o mapeamento está ativo e as alterações suportadas foi uma... Pausar interrompe temporariamente o mapeamento quando uma equipe precisa realizar um trabalho planejado e investigar um problema, ou gerenciar um problema, ou gerenciar um uso. Mas a pausa não é um estacionamento permanente. Quando o mapeamento está pausado, as alterações podem entrar em uma fila por tempo e espaço de mim. Quando o mapeamento é retomado, a recuperação processa as alterações pendentes. Isso ajuda as equipes a se recuperarem após uma interrupção planejada. No entanto, alguém precisa ser responsável por essa pausa e saber quando o mapeamento deve voltar a você.

Antes de tudo isso começar no trabalho diário, existe outra etapa, a sincronização inicial. A sincronização inicial traz registro de ambos os lados para um ponto de partida comum. Pense em uma empresa que já possui clientes no Finance Operations e registros de clientes no Dataverse. A conexão não pode simplesmente ser ativada assumindo que cada registro existente corresponda perfeitamente. É necessário uma linha de partida. A sincronização inicial ajuda a trazer os dados existentes antes que as pessoas dependam de atualizações em tempo real. Esse trabalho exige cuidado, pois registros duplicados, endereços incompletos e dados de teste antigos não se limpam magicamente só porque uma sincronização começou. Eles podem, na verdade, criar problemas mais rapidamente se os registros não seguirem as regras estabelecidas. Uma vez que os mapeamentos estão em execução, as pessoas que gerenciam o DualWrite precisam de um local claro para verificar sua integridade.

O DualWrite fornece logs combinados de atividade e erro para que os administradores possam ver o que a conexão processou e onde encontrou dificuldades. Eles também podem definir alertas e limites. Isso significa que as pessoas certas ficam sabendo dos problemas antes que os usuários os descubram por meio de uma atualização ausente ou com falha. Essa visão de suporte é importante porque todo erro tem uma causa. Talvez um campo obrigatório seja a falta. Talvez um registro relacionado ainda não tenha chegado. Talvez alguém tenha alterado dados de uma forma que não se encaixa no lugar. Tentar processar novamente um registro com falha sem corrigir a causa geralmente gera a mesma falha novamente. Uma configuração de DualWrite bem executada monitora a conexão, corrige a razão por trás dos erros e mantém os mapeamentos focados nos registros que realmente precisam permanecer conectados. Onde o DualWrite aplica?

O DualWrite se aplica melhor quando sua empresa utiliza o Dynamics 365 Finance ou Supply Chain Management junto com aplicativos voltados ao cliente como vendas, atendimento ao cliente, serviço de campo ou operações de projeto. Esses aplicativos suportam diferentes partes da mesma conversa com esse. Uma equipe fala com o cliente, outra planeja a entrega, gerencia o estoque, rastreia custos ou envia a fatura. Quando ambos os grupos precisam trabalhar com registros relacionados durante o dia, o DualWrite pode conectar esse trabalho sem forçar todos a usarem o mesmo aplicativo. Considere o processo de Prospect to Cash como um exemplo. Um vendedor trabalha com um cliente em potencial no Dynamics 365 Sales. Eles rastreiam o contato, discutem produtos, criam uma cotação e avançam para um pedido. Durante essa conversa, o vendedor precisa de detalhes do cliente, informações de produtos, preços e dados de pedidos relacionados ao setor financeiro da empresa.

Assim que a venda se torna real, o setor de finanças e gerenciamento da cadeia de suprimentos assume o trabalho que ocorre após a promessa. Ele cuida do preenchimento do pedido, faturamento de estoque e registro financeiro. O DualWrite ajuda essas duas partes a permanecerem conectados. Os vendedores podem trabalhar no aplicativo que se ajusta ao seu trabalho, enquanto finanças e operações gerenciam a transação no aplicativo criado para suas funções. O cliente não se torna duas histórias separadas, uma contada por vendas e outra contada por finanças. O Field Service oferece outro bom exemplo. Imagine uma empresa que envia técnicos para instalar, reparar ou manter equipamentos nos locais dos clientes. O técnico de campo precisa de detalhes do cliente, detalhes sobre o trabalho e informações sobre o ativo do cliente referente ao item instalado ou suportado. Nos bastidores, a empresa também precisa rastrear peças, custos, compras e o dinheiro vinculado a esse trabalho.

O Field Service concentra-se no planejamento e na conclusão da visita. O setor de finanças e operações concentra-se no registro operacional e financeiro ao redor disso. Quando esses registros se conectam corretamente, o trabalho do técnico não fica separado das peças usadas, do custo do trabalho e do registro cliente a ele vinculado. Project Operations segue o mesmo padrão, especialmente para empresas que vendem trabalho por projeto. Uma equipe de projeto pode gerenciar o trabalho do cliente, o tempo das pessoas, custos planejados e marcos do projeto. O setor financeiro precisa ver o lado financeiro de compras, custos, faturamento e relatórios. Sem uma conexão, gerentes de projeto podem perder muito tempo cobrando atualizações do financeiro, enquanto o financeiro aguarda as equipes de projeto confirmarem o que aconteceu. Registros de projeto conectados dão a ambos os grupos uma visão mais clara do trabalho à medida que ele passa de uma promessa do cliente para uma atividade financeira.

Há também um benefício mais amplo da Power Platform aqui, porque o lado do aplicativo do cliente usa o Dataverse, dados aprovados no Dataverse podem suportar Power Apps e Power Apps e Power Automate. Uma empresa pode criar um pequeno aplicativo para uma equipe interna, ou criar um fluxo que responda quando um registro de negócio e de negócio atinge nada do ponto. Isso não significa que todo registro de finanças e operações deva, de repente, fazer parte de todo o Power App. Isso significa que os registros conectados podem fazer parte de um conjunto mais amplo de ferramentas de negócios, desde que a empresa escolha esse propósito com cuidado e proteja os dados adequadamente. Um limite para isso permanecer claro. O DualWrite não oferece suporte ao Dynamics 305 Business Central. O Business Central pode se conectar a outros produtos da Microsoft por outros métodos, mas o DualWrite é voltado para o lado de finanças e operações do Dynamics 305 e para aplicativos baseados no Dataverse.

Também não é uma ferramenta para copiar todas as tabelas que você encontrar. Um registro deve ser movido porque as pessoas precisam do mesmo registro operacional em ambos os lugares, não porque copiar dados pareça mais seguro. DualWrite também não substitui um plano de integração mais amplo quando uma empresa precisa de feeds de relatório, links para sistemas de terceiros ou uma grande migração de dados. Tratar cada conexão de dados como o mesmo trabalho cria problemas rapidamente. Limites, preparação e erros comuns. Pense no DualWrite como acordo de aperto de mão entre dois sistemas. Eles concordam em manter certos registros compartilhados em sincronia, mas não é um canal mágico para cada tabela relatória ou sistema externo. Antes de configurá-lo, verifique quais integrações já existem. Se uma conexão antiga e o DualWrite atualizarem o mesmo registro de cliente, você pode criar conflitos rapidamente.

Essa é uma dor de cabeça que você não quer. Portanto, concorde com o básico primeiro. Como vocês inserirão os nomes? Qual empresa é legal e proprietária de cada registro? Quem pode fazer alterações? Quais funções de segurança cada equipe precisa? Duplicatas e registros incompletos antes da primeira sincronização. Comece com os mapas pré-criados da Microsoft. Já conecta um registro com uso. Tabelas e campos personalizados, esses precisam de teste de cuidado. E verifique as tabelas relacionadas e as dependências de mapeamento, que às vezes um registro precisa que outro exista antes de poder ser sincronizado. Planeje sua primeira sincronização com base na quantidade de dados que se postou. Não trate como um interruptor de luz que você aciona durante o almoço. Isso que eu usará provando. Um mapa pausado ainda precisa de um proprietário e de um plano de reinicialização. Alterações na fila e registro com falha não permanecem lá para cima.

Observe os registros de atividade, erros, alertas e limites. Quando algo falhar, encontre o campo ausente, o registro incorreto ou a regra quebrada por trás disso. Repetir as tentativas não corrigirá dados ruins. Quando você vê o DualWrite como uma ponte controlada, tudo se encaixa. Conclusão. Uma conversa de negócio compartilhada. DualWrite mantém os registros compartilhados, suportados e movimento entre o financeiro e operações e seus aplicativos baseados no Dataverse. Dessa forma, as equipes podem trabalhar a partir de dados de negócio conectado. Inscreva-se na sua plataforma de podcast favorita para mais pílulas de conhecimento comigo, Mirko Peters, em m307.fm. E compartilhe este episódio com alguém que ainda está conectando vendas, serviços e finanças por meio de outra planilha. E compartilhe este episódio com alguém que ainda está conectado com alguém que ainda está conectado com alguém que ainda está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que está conectado com alguém que