Un vendedor actualiza la dirección de un cliente. Más tarde, Finanzas abre el mismo registro y todavía ve la anterior. ¿Cuál dirección es la correcta? Durante años, solucionar esto significaba exportar datos, editar una hoja de cálculo, enviarla por correo e inscribir la misma actualización dos veces en otra aplicación. Escritura dual de Dynamics 365 Conecta las aplicaciones de finanzas y operaciones con las aplicaciones de clientes basadas en Dataverse para que los registros compartidos como clientes y pedidos se sincronizan automáticamente. Me acompaña, soy Milko Peters, CM365FM, y esta cápsula de conocimiento explica la escritura dual en lenguaje sencillo. Cubriremos qué se mueve, cómo se mueve, dónde encaja la escritura dual y dónde no encaja. Primero comencemos con el problema empresarial que generó la necesidad de esto. El problema que resuelve la escritura dual. Imagina una empresa donde dos grupos trabajan con el mismo cliente pero usan aplicaciones totalmente diferentes día a día.

Las aplicaciones de finanzas y operaciones manejan el trabajo administrativo. Eso es dinero, existencias, productos, pedidos, compras y la cadena de suministro. Aquí es donde una empresa rastrea lo que vende, lo que puede entregar, lo que debe y lo que un cliente necesita pagar. Las aplicaciones de clientes se enfocan en el trabajo más cercano al cliente. Sus equipos de ventas siguen prospectos y crean oportunidades. Atención al cliente maneja preguntas y casos. Servicio de campo planifica trabajos y envía personas a los sitios. Sus equipos de proyectos rastragan el trabajo prometido. Rajo diferente requiere pantallas diferentes. Un vendedor no debería tener que buscar en una pantalla de finanzas solo para actualizar un contacto después de una llamada. Pero un usuario de finanzas necesita detalles de clientes y pedidos que coincidan con lo que ve ventas, ya que las facturas y entregas dependen de esa información.

Sin una conexión, un cliente se convierte silenciosamente en dos registros. Ventas podría listar Northwind Bikes, mientras que finanzas podría listar Northwind Bicycle Company. O un registro tiene la nueva dirección, el otro sigue enviando facturas a la oficina antigua. Ambos registros parecen razonables por sí solos, pero ya no describen la misma relación comercial. Los problemas pequeños aparecen primero. Alguien no puede encontrar a un cliente porque el nombre es diferente en otra aplicación. Un representante de ventas promete un precio o verifica existencias, pero la información no coincide con el lado operativo. Finanza necesita procesar un pedido, pero los detalles del cliente requieren una verificación, un correo electrónico, electrónico y autorización. Luego de esos pequeños problemas se acumulan. Alguien exporta datos de clientes a una hoja de calco. Otra persona corrige algunas filas y las importa en otro lugar.

Alguien más ingresa a un nuevo cliente en ambas aplicaciones porque nadie sabe qué registro aparecerá primero. Pronto hay duplicados, direcciones diferentes y más tiempo dedicado a verificar datos que a usarlos. Nada de esto sucede porque la gente se descuida. Sucede porque los sistemas piden a las personas que se conviertan en la conexión. La gente copia datos. La gente recuerda qué aplicación va primero. La gente detecta errores después de que ya han llegado otro equipo. Ese enfoque funcionaba cuando los sistemas empresariales permanecían separados y los equipos aceptaban retrasos. Pero cuando ventas, servicios, finanzas y operaciones necesitan la misma información del cliente durante el día, una hoja de cálculo se vuelve una mala herramienta de traspaso. Piense en una conversación sencilla sobre un pedido. Un cliente llama a ventas y pregunta cómo pueden entregar la próxima semana. ¿Y cuánto costará?

El equipo de ventas necesita detalles de producto, precio y existencias para responder. Una vez que el cliente acepta, finanzas y operaciones necesitan información correcta del cliente del pedido para procesar la venta. Ambas partes necesitan un sencito. Ventas necesita esos hechos en la aplicación donde trabaja el personal de venta. Finanzas y operaciones los necesitan en la aplicación donde gestionan pedidos, dinero y entregas. El objetivo no es intentar forzar a cada equipo a usar una pantalla gigante. El objetivo es que los registros compartidos sigan una ruta clara y acordada. Ahí es donde entra en juego la escritura Dual Run. ¿Qué es exactamente la escritura Dual? Dual. Aquí está la definición más simple. La escritura Dual es la conexión integrada de Microsoft que mantiene sincronizados datos seleccionados entre las aplicaciones de Dynamics 360. Finance and Operations y Dataverse. Dataverse es la base de datos compartida detrás de muchas aplicaciones empresariales de Microsoft.

Dynamics 365, Sales, Customer Service, Field Service y partes de Project Operations la utilizan. Power Apps y Power Automate también pueden utilizar. No necesitas saber cómo Dataverse almacena cada registro para entender la escritura Dual. Solo piénselo como el área de datos común en el lado de las aplicaciones de clientes Dynamics 365. Imagina un edificio de oficinas con una oficina frontal y una oficina frontal. La oficina frontal maneja las conversaciones con los clientes. Personal de venta, agentes de servicio, trabajadores de campo. Todos necesitan pantallas que les ayuden a hablar con las personas, bastar solicitudes y gestionar el trabajo. La oficina administrativa maneja el trabajo que mantiene la empresa en función. Nuestro registro financiero es existencias, pedidos, compras, entregas. Ambas oficinas trabajan para la misma empresa, pero sin una conexión adecuada entre ellas, alguien tiene que llevar la información de un lado al otro.

Llevan un formulario impreso, ven un correo electrónico o copian datos en otro sistema. El trabajo aún se realiza, pero toma más tiempo y los detalles pueden cambiar en el camino. La escritura Dual es como una puerta interna con personal entre esas dos oficinas. Cuando un registro compatible cambia de un lado, la escritura Dual pasa el cambio relacionado a través de esa puerta hacia el otro lado. No combina todas las aplicaciones en una sola aplicación gigante. Ventas puede seguir trabajando en venta. Finanzas puede seguir trabajando en finanzas. Cada equipo conserva las pantallas diseñadas para su trabajo, mientras que la información compartida seleccionada se mantiene conectada entre bastidores. Esa palabra compatible es importante. DualWrite no copia ciegas cada dato en ambos sistemas. Funciona mediante conexiones definidas entre registros que pertenecen juntos. Microsoft llama a estas conexiones mapas de tabla.

Una tabla es simplemente un lugar donde una aplicación guarda un tipo de registro. Una tabla de clientes guarda registros de clientes. Una tabla de productos guarda registros de producto. Una tabla de direcciones guarda direcciones. Un mapa de tabla le indica a DualWrite qué tabla en el lado de Finance and Operations se conecta con qué tabla en Dataverse. Piense en un mapa de tabla como una hoja de traducción a guarda. Una columna identifica un registro en un lado. Otra columna identifica su registro coincidente en el otro lado. El resto de la hoja explica qué campos pertenecen juntos. Nuestro nombre, número de teléfono, línea de dirección. Ese acuerdo proporciona las reglas de conexión. Sin él, dos aplicaciones podrían usar etiquetas diferentes o almacenar el mismo detalle en lugar de... Un mapa le dice a DualWrite cómo se relacionan esos detalles. Así, las aplicaciones no necesitan que una persona se interprete cada...

Ahora bien, la gente suele escuchar el nombre DualWrite y Asume, que significa que cada cambio siempre se mueve en ambos sentidos. A veces sí es así. Para un mapa bidireccional compatible, un cambio en Dataverse puede actualizar el registro relacionado en Finance and Operations. Un cambio compatible en Finance and Operations también puede actualizar el registro relacionado en Dataverse. Ambos lados pueden participar en el mismo registro compartido. Esa es la parte dual. La actualización ocurre en tiempo casi rápido. Se mueve rápidamente mientras la gente trabaja en lugar de esperar una tarea programada que se ejecuta durante el mundo. Un usuario actualiza un registro compatible, y la conexión envía esa actualización mientras el trabajo aún está en curso. Tiempo casi real no significa margen ni retraso cero. Significa que la conexión está creada para el trabajo empresarial en vivo, no para un intercambio de archivos una vez al día.

Si alguien cambia un detalle, el equipo relacionado no necesita esperar hasta mañana por la mañana para verlo. Eso cambia la forma en que los equipos pueden trabajar. La oficina principal puede usar datos que provenen de la oficina administrativa. La oficina administrativa puede recibir actualizaciones compatibles de aplicaciones orientadas al cliente. Dataverse se convierte en la base de datos de un lado, Finance and Operations sigue siendo la base operativa del otro, y DoorWrite mantiene conectados los registros compartidos aprobados. Aún así, una puerta interna activa necesita reír. Antes de permitir que un registro viaje en ambas direcciones, necesitas saber dónde debe comenzar ese registro o quién puede cambiarlo, y qué lado debe prevalecer cuando las dos aplicaciones no están de acuerdo. ¿Qué datos se pueden mover y qué sistema los posee? Entonces, ¿qué registros puede mantener conectados DoorWrite?

Los ejemplos comunes comienzan con los registros que muchos departamentos comparten a día. Registros de clientes, direcciones, contactos, productos, proveedores, detalles de la empresa e información de referencia utilizada para finanzas e impuestos. Pensemos en registro de cliente por un momento. Ventas necesita el nombre del cliente, el contacto principal, el nombre del teléfono y la dirección de entrega. Finanza necesita el registro legal del cliente, los detalles de facturación y la información necesaria para pedidos y factura. Si cada departamento mantiene su propia lista de clientes por separado, la empresa pierde tiempo comprando registros en lugar de atender al cliente. Con los mapas de DoorWrite correctos, los equipos pueden trabajar con detalles de clientes conectados. Eso no significa que los usuarios de ventas necesitan aprender a usar la aplicación de finanzas de RP. Significa que pueden trabajar con la información del cliente en Dynamics 365 Sales, mientras que los usuarios de finanzas trabajan con la información relacionada en finanzas.

El cliente sigue siendo reconocible como el mismo cliente en ambos lugares. Las direcciones también importan. Un cliente puede tener una dirección de facturación, una dirección de entrega y tal vez un sitio donde un trabajador de servicio deva. Estos detalles no pueden tratarse simplemente como texto plano copiado en un cuadro porque cada dirección tiene una función distinta. DoorWrite admite la estructura de registros compartidos necesaria para esa relación. Los contactos siguen el mismo patrón. Una empresa cliente puede tener un comprador, un contacto de cuentas por pagar y un gerente de servicio. Ventas necesita saber quién toma las decisiones. Finanzas necesita saber a dónde dirigir las facturaciones. Servicios necesita saber quién espera en el sitio. Los registros conectados ayudan a cada equipo a ver a las personas relacionadas con el cliente sin recrear esa información en cada aplicación.

Los productos son otro ejemplo común. Un representante de ventas necesita saber qué vende la empresa, cuánto cuesta el producto y si existencias disponibles. Esas respuestas suelen provenir del lado operativo del negocio porque ahí es donde se gestiona los productos, el inventario, las compras y el cumplimiento. Es por esto que la información del producto a menudo comienza en finanzas y operaciones. Un equipo de operaciones crea y prepara un producto allí. Una vez que el producto está listo para el trabajo con el cliente, DualWrite puede enviar los detalles relacionados del producto a Dataverse. Los usuarios de ventas pueden seleccionar y discutir el producto en su propia aplicación sin que nadie tenga que ingresar la lista de productos por segunda vez. Su ayuda a que las conversaciones de ventas se basen en lo que la empresa realmente puede ofrecer, realmente puede ofrecer. Los detalles de precios e inventario también pueden llegar a ventas a través de las aplicaciones conectadas.

En lugar de adivinar si un artículo existe, si el precio cambió o si el inventario puede respaldar una promesa, el equipo de ventas puede trabajar con información vinculada al lado operativo. Eso no elimina la necesidad de un buen criterio de venta. Elimina la razón evitable para que un representante de ventas llame al almacén solo para confirmar detalles básicos. La información de los proveedores también puede conectarse donde un proceso de negocio la necesita. Los detalles de la empresa, las estructuras organizativas, los datos de referencia financieros y los datos fiscales pueden ser relevantes tanto para el lado del cliente como para el del cliente como para el de las operaciones. Los registros exactos dependen de las aplicaciones y procesos que use una empresa, pero el patrón sigue siendo el mismo. Comparte los registros que necesiten significar lo mismo en ambos lugares. Ahora bien, más suma que cada registro debe viajar en ambas direcciones.

Algunas aplicaciones admiten actualizaciones de dirección. Un cambio puede comenzar en Dataverse y pasar a Finanzas y Operaciones o comenzar en Finanzas y Operaciones y pasar a Dataverse. Ese enfoque se ajusta a registros donde ambas partes tienen una narrazón comercial adecuada para actualizar detalles de prueba. Otro mapa funciona en el Exceledic. Los productos nos dan un ejemplo. En muchos negocios, Finanzas y Operaciones se encargan de la creación de productos porque Operaciones controla el maestro de productos, existencias, unidades y otros detalles necesarios para venderlo y entregarlo. Luego, el producto fluye hacia Dataverse, donde los equipos de ventas y servicio pueden usarlo. Esa es una regla clara. El producto no necesita dos equipos creando versiones en competencia. Un lado crea y gobierna el producto, el otro lado lo recibe y lo usa como parte de su trabajo. Cada registro compartido necesita ese tipo de decisión.

¿Dónde comienza este registro? ¿Quién puede editar? Si un nombre, dirección, precio o clasificación parece incorrecto, ¿qué equipo lo corrige? Esas preguntas parecen simples, pero evitan mucha confusión más adelante. La conexión puede muy rápidamente... Si nadie acordó quién es responsable de ese cambio, puede muerir un error con la misma rapidez. Elija un propietario para el registro y, cuando sea necesario, para los detalles individuales dentro de ese registro. Por ejemplo, ventas podría ser propietario de los detalles de relación de un cliente y la información de contacto principal. Finanzas podría ser propietario de detalles relacionados con los pagos, pero sin apoditos de exigencias. Su división exacta depende de cómo funcione su negocio, pero debe estar escrita y ser comprendida por las personas que usan las aplicaciones. También hay dos términos que puede ver después de que la escritura dual expanda Dataverse, entidad, party y empresa, company.

Una entidad es la forma en que Microsoft maneja una persona u organización de manera consistente. Ayuda a conectar personas, organizaciones, contactos y direcciones sin tratar cada relación como un registro separado y no relacionado. Una empresa ayuda a Dataverse a comprender el contexto de empresa comercial utilizado por finanzas y operaciones. No necesita convertirse en un experto en ninguno de los dos términos. Solo sepa que existen porque finanzas y operaciones maneja estructuras empresariales que las aplicaciones de clientes deben reconocer cuando los registros pasan de un lado a otro. Una vez que los registros pueden viajar en ambas direcciones, el proceso que los rodea es tan importante como los datos mismos. ¿Cómo viaja un cambio entre las aplicaciones? Sigamos un cambio a través del sistema y veamos qué sucede realmente. Un representante de ventas está en una llamada con un cliente que acaba de mudarse a una nueva oficina.

Durante esa conversación, el representante abre el registro del cliente en Dynamics 365.6 y actualiza la dirección. Bastante simple, ¿verdad? Luego guardan el registro. Ahí es donde comienza la parte interesante. Sales almacena ese cambio en Dataverse que es el lado de datos para las aplicaciones orientadas al cliente. Luego, DualWrite verifica el mapa que conecta la información del cliente y la dirección entre este sitio y finanzas y operaciones. Envía el cambio correspondiente a formato map. Sin archivos de exportación en la carpeta compartida esperando a que alguien lo recoja. Knight dirá que enviar un correo electrónico de finanzas diciendo, oye, por favor, actualiza esta dirección. El mapa ya sabe qué campos están vinculados. Y envía el cambio admitido directamente al registro del cliente relacionado en finanzas y operaciones. Así, un usuario de finanzas puede abrir ese registro del cliente más tarde, ver la dirección actualizada y procesar un pedido o preparar una factura sin interrupciones.

Ese es el resultado práctico sin regalar. Dos personas siguen trabajando en aplicaciones diferentes, pero ninguna tiene que volver a escribir el mismo detalle del cliente. El representante de ventas trabaja en una pantalla diseñada para conversaciones con clientes. El usuario de finanzas trabaja en una pantalla creada para el trabajo financiero. Cada persona ve la información del cliente que realmente necesita justo donde la necesita. Y el viaje también funciona en la otra dirección. Imagine que finanzas actualiza información del cliente admitida en finanzas y operaciones. Supongamos que un usuario de finanzas corrige un detalle que pertenece al registro operativo del cliente. DualWrite utiliza el mapa correspondiente a la inversa y envía esa actualización relacionada a Dataverse. Entonces Sales, Customer o cualquier otra aplicación basada en Dataverse puede captarlo. Esta conexión es sincrónica para el trabajo diario normal.

Sincrónico significa que las aplicaciones intentan completar la actualización relacionada en el mismo momento en lugar de dejarla en un trabajo en segundo plano que podría ejecutar segundo plano que podría ejecutarse 20 minutos después. Si la conexión no puede completar la actualización, ese problema requiere atención inmediata, no ocultarse silenciosamente hasta que alguien note una discrepancia. Ese comportamiento tiene sentido para los registros comerciales compartidos. No querrá que una dirección de cliente, detalle de producto u otra información compartida se desincronice durante horas porque un trabajo por lotes aún no se ejecuta. Las personas toman decisiones basadas en lo que ven en su pantalla en este momento. La conexión mantiene ambos lados sincronizados mientras se realiza el trabajo. Cuando hacía el trabajo en curso, a veces requiere una pausa controlada. DualWrite incluye opciones de reproducción, pausa y puesta de día.

Reproducir significa que el mapa está activo y los cambios compatibles se transmiten normalmente. La pausa detiene temporalmente el mapa cuando un equipo necesita realizar labores planificadas, investigar un problema o gestionar un problema o gestionar una segura. Pero la pausa no es un lugar de estacionamiento para mí. Mientras un mapa está en pausa, los cambios pueden ponerse en cola por un tiempo y espacio limitado. Cuando el mapa se reanuda, la puesta al día procesa esos cambios pendientes. Esto ayuda a los equipos a recuperarse tras una interrupción planificada. Pero alguien debe hacerse cargo de esa pausa y saber cuándo debe volver a ejecutarse el mapa. Antes de que todo esto comience en el trabajo diario, hay otro paso. La sincronización inicial. La sincronización inicial lleva a los registros existentes de ambos lados a un punto de partida compartido. Piensen en una empresa que ya tiene clientes en Finance and Operations y registros de clientes en Dataverse.

La conexión no puede simplemente activarse y asumir que cada registro existente ya coincide a la perfección. Necesita una línea de salida. La sincronización inicial ayuda a traer los datos existentes antes de que los usuarios dependan de las actualizaciones en tiempo real. Este trabajo requiere cuidado, porque los registros duplicados, direcciones incompletas y datos de prueba antiguos no se limpian mágicamente solo porque comience una sincronización. De hecho, pueden crear problemas más rápidos si los registros no siguen las reglas acordadas. Una vez que los mapos están en ejecución, las personas que gestionan DualWrite necesitan un lugar claro para verificarlos. DualWrite proporciona registros combinados de actividad y errores para que los administradores vean qué procesó la conexión y dónde tuvo dificultades. También pueden establecer alertas y umbral. Esto significa que las personas adecuadas se enteran de los problemas antes de que los usuarios los descubran mediante una actualización fallida o faltar.

Esa vista de soporte es importante porque cada error tiene una causa. Quizá falta un campo obligatorio. Quizás un registro relacionado o no llegado. Quizás alguien cambió datos de una manera que no encaja con el mapa. Reintentar un registro fallido sin corregir la causa suele provocar el mismo fallo de nuevo. Una configuración de DualWrite bien gestionada vigila la conexión, soluciona el origen de los errores y mantiene los mapas enfocados en los registros que realmente necesitan estar conectados. ¿Dónde encaja mejor DualWrite? DualWrite encaja mejor cuando su empresa utiliza Dynamics 365 Finance o Supply Chain Management junto con aplicaciones de cara al cliente como ventas, servicio al cliente, servicio de campo u operaciones de proyectos. Estas aplicaciones respaldan diferentes partes de la misma conversación empresarial. Un equipo habla con el cliente. Otro equipo planifica la entrega, gestiona el inventario, rastrea costos o envía la factura.

Cuando ambos grupos necesitan trabajar con registros relacionados durante el día, la escritura Dual puede conectar ese trabajo sin obligar a todos a usar la misma aplicación. Tomemos como ejemplo el proceso de cliente potencial efectivo. Un vendedor trabaja con un cliente potencial en Dynamics 365 C. Realizan un seguimiento de contacto, discuten producto, crean una cotización y avanzan hacia un pedido. Durante esa conversación, el vendedor necesita detalles del cliente, información del producto, precios e información del pedido, relacionada con el área financiera de la empresa. Una vez que la venta se concreta, finanzas y supply chain management asumen el trabajo que ocurre después de la promesa. Gestionan el cumplimiento de pedidos, la facturación de existencias y los registros financieros. La escritura Dual ayuda a que esas dos partes permanecan conectadas. Los vendedores pueden trabajar en la aplicación de clientes que se adapta a su labor, mientras que finanzas y operaciones gestionan la transacción en la transacción en la aplicación diseñada para su trabajo.

El cliente no se convierte en dos historias separadas, una contada por ventas y otra por finanzas. Field Service le ofrece otro buen ejemplo. Imagina una empresa que envía técnicos para instalar, reparar o mantener equipos en las instalaciones del cliente. El trabajador de campo necesita los detalles del cliente, información sobre el trabajo e información sobre el activo del cliente del artículo que la empresa instaló. Detrás de SENA, la empresa también necesita realizar un seguimiento a las piezas, los costos, las compras y el dinero vinculado a ese trabajo. Field Service se centra en planificar y completar la visita. Finanzas y operaciones se centran en el registro operativo y financiero relacionado. Cuando esos registros se conectan correctamente al trabajo de un técnico, no quedan separados de las piezas utilizadas, el costo del trabajo o registro del cliente conectado a él. Project Operations sigue el mismo patrón, especialmente para empresas que venden trabajo por proyecto.

Un equipo de proyecto puede gestionar el trabajo del cliente, el tiempo de las personas, los costos planificados y los hitos de proyecto. Finanzas necesita ver el aspecto financiero de las compras, los costos, la facturación y los informes. Sin una conexión, los gerentes de proyecto pueden perder demasiado tiempo persiguiendo a Finanzas para obtener actualizaciones, mientras Finanzas espera que los equipos de proyecto confirmen lo sucedido. Los registros de proyecto conectados brindan a ambos grupos una visión más clara del trabajo a medida que avanza de la promesa del cliente hasta la actividad financiera. También hay un beneficio más amplio de Power Platform aquí, porque el lado de la aplicación del cliente usa Dataverse, por lo que los datos aprobados en Dataverse pueden respaldar a Power Apps y Power Apps y Power Automate. Una empresa podría crear una pequeña aplicación para un equipo interno, o crear un flujo que responda cuando un registro comercial alcanza cierto punto.

Eso no significa que cada registro de finanzas y operaciones debe estar necesariamente en cada Power Apps. Significa que los registros conectados pueden formar parte de un conjunto más amplio de herramientas empresariales, siempre que la empresa elija ese propósito con cuidado y proteja los datos adecuadamente, y proteja los datos adecuadamente. Un límite debe permanecer claro. DualWrite no es compatible con Dynamics 365 Business Central. Business Central puede conectarse con otros productos de Microsoft mediante otros métodos, pero DualWrite es para el lado de finanzas y operaciones de Dynamics 365 y las aplicaciones de clientes basadas en Dataverse. Tampoco es una herramienta para copiar todas las tablas que encuentres. Un registro debe moverse porque las personas necesitan el mismo registro operativo en ambos lugares, no porque copiar datos parezca más seguro. DualWrite tampoco reemplaza un plan de integración más amplio cuando una empresa necesita fuentes de informes, enlaces a sistemas de terceros o una gran migración de datos.

Tratar cada conexión de datos como el mismo trabajo crea problemas rápidamente. Límites, preparación y errores comunes. Piensa en DualWrite como un acuerdo de apretón de manos entre dos sistemas. Acuerda en mantener sincronizados ciertos registros compartidos, pero no es un conducto mágico para cada tabla e informe o sistema externo. Antes de configurarlo, verifica qué integración es existente. Si una conexión antigua y DualWrite actualizan el mismo registro de cliente, puedes crear conflictos rápidamente. Es un dolor de cabeza que no querrás tener. Así que primero aguarden lo básico. ¿Cómo ingresarán los nombres? ¿Qué empresa legal posee cada registro? ¿Quién puede realizar el cambio? ¿Qué roles de seguridad necesita cada equipo? Eliminen duplicados y registros incompletos antes de la primera sincronización. Empiecen con los mapas pre-construidos de Mac. Ya conectan registros comunes. Las tablas y campos personalizados requieren pruebas cuidadosas.

Y revisen las tablas relacionadas y la dependencia de los mapas, porque a veces un registro necesita que otro exista antes de poder sincronizarse. Planea que en su primera sincronización sea con la cantidad de datos que tengan. No lo traten como un interruptor de luz que encienden durante el almuerzo. Eso causará problemas. Un mapa pausado todavía necesita un propietario y un plan de reinicio. Los cambios en Core y los registros fallidos no permanecen para siempre. Vigilen los registros de actividad, errores, alertas y umbrales. Cuando algo falla, encuentren en el campo faltante el registro incorrecto o la regla rota detrás de ello. Los reintentos repetidos no arreglarán los datos incorrectos. Cuando veas a DualWrite como un puente controlado, todo encaja en su lugar. Inclusión una conversación de negocios compartida. DualWrite mantiene los registros compatibles moviéndose entre finanzas y operaciones y su aplicación es de clientes basadas en Dataverse.

De esa manera, los equipos pueden trabajar a partir de datos empresariales conectados. Suscríbanse en su plataforma de podcast favorita para más píldoras de conocimiento conmigo, Mirko Peters, en M365.FFM. Y compartan este episodio con alguien que todavía esté conectando ventas, servicio y finanzas a través de otra hoja de cálculo.