Un commercial met à jour l'adresse d'un client. Plus tard, le service financier ouvre le même dossier et voit toujours l'ancienne adresse. Alors, quelle est la bonne adresse ? Pendant des années, pour corriger cela, il fallait exporter des données, modifier une feuille de calcul, l'envoyer par e-mail et saisir deux fois la mise à jour dans une seconde application. La double écriture de Dynamics 365 change. Elle connecte les applications finance et opérations aux applications clientes basées sur Dataverse, de sorte que les enregistrements partagés, comme les clients et les commandes, restent synchronisés automatiquement. Vous êtes avec moi, je suis Milko Peters de M365FM, et cette capsule de connaissances explique la double écriture en termes simples. Nous verrons ce qui est transféré, comment, où la double écriture s'intègre et où elle ne s'applique pas. Commençons d'abord par le problème métier, qui a rendu cela nécessaire,

le problème que résout la double écriture. Imaginez une entreprise où deux groupes travaillent sur le même client, mais utilisent des applications totalement différentes au quotidien. Les applications finance et opérations gèrent le travail de back-office. Il s'agit de l'argent, des stocks, des produits, des commandes, des achats et de la chaîne approvisionne. C'est ici qu'une entreprise suit ce qu'elle vend, ce qu'elle peut livrer, ce qu'elle doit, et ce qu'un client doit payer. Les applications clients se concentrent sur le travail au plus près du client. Les équipes commerciales suivent les pistes et développent des opportunités. Le service client gère les questions et les dossiers. Le service après-vente planifie les interventions et envoie du personnel sur site. Les équipes projet suivent le travail promis à un client. Des tâches différentes nécessitent des écrans différents. Un commercial ne devrait pas refouiller dans un écran financier juste pour mettre à jour un contact après un appel.

Un utilisateur financier a besoin de détails sur le client et la commande qui correspondent à ce que voit le commercial, car les factures et les livraisons dépendent de ces informations. Sans connexion, un seul client devient silencieusement deux enregistrements. Les ventes peuvent lister dans Windbikes et Ecom, tandis que la finance peut lister dans Windbikes et Ecom. L'un des dossiers possède la nouvelle adresse, l'autre envoie toujours les factures à l'ancien bureau, à l'ancien bureau. Les deux enregistrements semblent corrects individuellement, mais ils ne décrivent plus la même relation commerciale. Deux petits problèmes apparaissent en premier. Quelqu'un ne trouve pas un client parce que le nom est différent dans une autre application. Un commercial promet un prix ou vérifie un stock, mais les informations ne correspondent pas au côté opérationnel. La finance doit traiter une commande, mais les détails du client nécessitent une vérification, un email et une autre mise à jour manuelle.

Ensuite, ces petits problèmes s'accumulent. Quelqu'un exporte les données clies dans une feuille de calcul. Une autre personne corrige quelques lignes et les importe ailleurs. Quelqu'un d'autre saisit un nouveau client dans les deux applications, car personne ne sait quel enregistrement apparaîtra en premier. Rapidement, on se retrouve avec des doubles, des adresses divergentes et plus de temps passé à vérifier les données qu'à les utiliser. Rien de tout cela n'arrive par négligence. Cela arrive parce que les systèmes demandent aux gens de faire le lien, les gens copient des données. Les gens retiennent quelle application utilisée en premier. Les gens remarquent les erreurs après qu'elles ont déjà atteint une autre équipe. Cette approche fonctionnait quand les systèmes restaient séparés et que les équipes acceptaient les délais. Mais quand les ventes, le service, la finance et les opérations ont besoin des mêmes informations clients, un tableur devient un mauvais outil de transfert.

Prenons l'exemple d'une simple commande. Un client appelle le service commercial et demande « Pouvez-vous livrer la semaine prochaine ? » Combien cela coûtera-t-il ? L'équipe commerciale a besoin de détails sur le produit, le prix et les stocks pour répondre. Une fois le client d'accord, la finance et les opérations ont besoin des bonnes informations pour traiter la vente. Les deux parties ont besoin des mêmes faits. Les ventes ont besoin de ces faits dans l'application où travaillent les commerciaux. La finance et les opérations en ont besoin dans l'application où ils gèrent les commandes, l'argent et la livraison. L'objectif n'est pas de forcer chaque équipe à utiliser un écran unique et géant. L'objectif est que les enregistrements partagés suivent un chemin clair et convenu. C'est là que le Ken DualWrite, où il entre en scène. Qu'est-ce que le DualWrite ad ad ad ? Voici la définition la plus simple.

Le Dynke DualWrite est une connexion Microsoft intégrée qui synchronise certaines données entre les applications Dynamics 365 Finance & Operations et Dataverse. Dataverse est la base de données communes derrière de nombreuses applications professionnelles Microsoft. Dynamics 365 Sales, Customer Service, Field Service et des parties de Project Operations l'utilisent. PowerApps et Power Automate peuvent également l'utiliser. Vous n'avez pas besoin de savoir comment Dataverse toque chaque enregistrement pour comprendre le cas DualWrite. Considérez-le simplement comme la zone de données communes côté application client de Dynamics 365. Imaginez un immeuble de bureau avec un front office égale mais un back office égale. Le front office gère les conversations avec les clients. Commerciaux, agents de service, techniciens de terrain. Ils ont tous besoin d'écran pour communiquer, suivre les demandes et gérer le travail.

Le back office gère le travail qui fait tourner l'entreprise. Régistre financier, stock, commande, achat, livraison. Les deux travaillent pour la même société. Mais sans connexion, quelqu'un doit transférer manuellement les informations. Ils apportent un formulaire papier, envoient un email ou copient les données dans un autre système. Le travail est fait, mais cela prend plus de temps et les détails peuvent changer en cours de route. Le DualWrite carré qu'est comme une porte interne avec personnel entre ces deux bureaux. Quand un enregistrement change d'un côté, le GAD DualWrite a une transmet la modification par cette porte vers l'autre côté. Cela ne combine pas toutes les applications géantes à l'équipe commerciale votre main devant. L'équipe financière peut toujours travailler dans le domaine. Chaque équipe conserve les écrans conçus pour son travail, tandis que certaines informations partagées restent connectées en coulisses.

Ce terme est capré en chargé. DualWrite ne copie pas aveuglément chaque donnée dans les deux systèmes. Il fonctionne grâce à des connexions définies entre des enregistrements qui vont ensemble. Microsoft appelle ces connexions des mappages de table. Une table est simplement un endroit où une application conserve un type d'enregistrement. Une table client conserve les enregistrements des clients. Une table produit conserve les enregistrements des produits. Une table d'adresse conserve les détails des adresses. Un mappage de table indique à DualWrite quelle table du côté finance et opération se connecte à quelle table dans Dataverse. Considérez le mappage de table comme une feuille de traduction convenue. Une colonne identifie un enregistrement d'un côté. Une autre colonne identifie son enregistrement correspondant de l'autre côté. Le reste de la feuille explique quels champs vont ensemble.

Nom, numéro de téléphone, ligne d'adresse. Cet accord définit les règles de connexion. Sans cela, deux applications pourraient utiliser des étiquettes différentes ou stocker les mêmes détails à des endroits différents. Un mappage indique à DualWrite comment ces détails sont liés. Ainsi, les applications n'ont pas besoin d'une intervention humaine pour les interpréter à chaque fois. Souvent, les gens entendent le nom DualWrite et supposent que chaque modification se répercute toujours dans les deux sens. C'est parfois le cas. Pour un mappage bidirectionnel pris en charge, une modification dans Dataverse peut mettre à jour l'enregistrement associé dans Finance et Opérations. Une modification prise en charge dans Finance et Opérations peut également mettre à jour l'enregistrement associé dans Dataverse. Les deux côtés peuvent participer au même enregistrement partagé. C'est la partie DualWrite.

La mise à jour s'effectue en temps quasi réel. Cela se déplace rapidement pendant que les utilisateurs travaillent au lieu d'attendre une tâche planifiée qui s'exécute la nuit. Un utilisateur met à jour un enregistrement pris en charge et la connexion transmet cette mise à jour pendant que le travail est en cours. Le temps quasi réel ne signifie pas de la magie ou un délai nul. Cela signifie que la connexion est conçue pour le travail métier en direct, pas pour un échange de fichiers quotidiens. Si quelqu'un modifie un détail, l'équipe concernée n'a pas besoin d'attendre demain matin pour le voir. Cela change la façon dont les équipes peuvent travailler. Le front office peut utiliser des données provenant du back office. Le back office peut recevoir des mises à jour prises en charge provenant d'applications tournées vers le clear. Dataverse devient la base de données d'un côté, Finance et Opérations restent la base opérationnelle de l'autre et DualWrite maintient les enregistrements partagés, approuvés, connectés.

Néanmoins, une porte interne ouverte nécessite des règles. Avant de laisser un enregistrement voyager dans les deux sens, vous devez savoir où il doit commencer, qui peut le modifier et quel côté doit primer en cas de désaccord entre les deux applications. Quelles données peuvent être transférées et quel système les détient ? Alors, quels enregistrements DualWrite peut-il garder connectés ? Les exemples courants commencent par les enregistrements que de nombreux départements partagent au quotidien. Dossiers clients, adresses, contacts, produits, fournisseurs, détails de l'entreprise et informations de référence pour la finance et la fiscalité. Réfléchissez un instant à un dossier client. Le service commercial a besoin du nom du client, du contact principal, du numéro de téléphone et de l'adresse de livraison. Service financier a besoin du dossier client légal, des détails de facturation et des informations nécessaires aux commandes et factures.

Si chaque département tient sa propre liste de clients, l'entreprise passe son temps à comparer les dossiers au lieu de servir le client. Avec les bons mappages DualWrite en place, ces équipes peuvent travailler à partir de détails clients connectés. Cela ne signifie pas que les utilisateurs commerciaux doivent soudainement apprendre à utiliser l'application finance. Cela signifie qu'ils peuvent travailler avec les informations clients dans Dynamics 365 Sales, tandis que les utilisateurs finance travaillent avec les informations liées dans Finance. Le client reste identifiable comme étant le même dans les deux environnements. Les adresses sont importantes. Un client peut avoir une adresse de facturation, une adresse de livraison et peut-être un site nécessitant une intervention. Ces détails ne peuvent pas être traités comme du texte brut copié dans une case car chaque adresse a une fonction différente.

GADE. DualWrite prend en charge la structure d'enregistrement partagé nécessaire à cette relation. Les contacts suivent le même schéma. Une entreprise cliente peut avoir un acheteur, un contact comptable et un responsable de service. Le service commercial doit savoir qui prend les décisions. Le service financier doit savoir à qui adresser les questions de facturation. Le service technique doit savoir qui attend sur le site. Les enregistrements connectés aident chaque équipe à voir les personnes liées au client sans ressaisir ces informations dans chaque application, dans chaque application. Les produits sont un autre exemple courant. Un représentant commercial doit savoir ce que l'entreprise vend, le coût du produit, si le stock est disponible. Ces réponses proviennent généralement du côté opérationnel, là où sont gérés les produits, les stocks, les achats et l'exécution. C'est pourquoi les informations produits commencent souvent dans Finance & Operations.

Une équipe opérationnelle y crée et prépare un produit. Une fois ce produit prêt pour le client, DualWrite peut envoyer les détails associés vers Dataverse. Les utilisateurs commerciaux peuvent alors sélectionner et discuter du produit dans leur propre application sans avoir à ressaisir la liste des produits. Cela permet aux conversations commerciales de rester fondées sur ce que l'entreprise peut réellement fournir. Les détails sur les prix et les stocks peuvent également atteindre le service commercial via les applications connectées. Au lieu de deviner si un article existe, si le prix a changé ou si le stock permet de tenir une promesse, l'équipe commerciale travaille avec des informations liées aux opérations. Cela ne remplace pas le besoin d'un bon jugement commercial. Cela élimine une raison évitable pour un commercial d'appeler l'entrepôt simplement pour confirmer des détails de base.

Les informations sur les fournisseurs peuvent également être reliées là où un processus métier en a besoin. Les détails de l'entreprise, les structures organisationnelles, les données financières et fiscales de référence peuvent être importants pour le client comme pour l'exploitation comme pour l'exploitation. Les enregistrements exacts dépendent des applications et des processus utilisés par une entreprise, mais les modèles restent le même. Partagez les enregistrements qui doivent signifier la même chose dans les deux systèmes. Ne supposez pas pour autant que chaque enregistrement doit circuler dans les deux sens. Taines applications prennent en charge de mise à jour 8 directions. Une modification peut débuter dans Dataverse pour aller vers Finance and Operations ou inversement. Cette approche convient aux enregistrements pour lesquels les deux parties ont une raison métier valable de mettre à jour des détails approuvés.

D'autres ma page ne fonctionnent que dans un sens. Des produits nous offrent un exemple utile. Dans de nombreuses entreprises,

on contrôle le référentiel produit, les stocks, les unités et autres détails nécessaires à la vente et à la livraison. Le produit est ensuite transmis vers Dataverse où les équipes de vente et de services peuvent l'utiliser. C'est une règle claire. Le produit n'a pas besoin que deux équipes créent des versions concurrentes. Une partie crée et gère le produit, l'autre le reçoit et l'utilise dans le cadre de son travail. Chaque enregistrement partagé nécessite ces décisions ou cet enregistrement commencé. Qui peut le modifier ? Si un nom, une adresse, un prix ou une classification semblent incorrectes, quelle équipe le corrige ? Ces questions semblent simples mais elles évitent beaucoup de confusion par la suite. Une connexion peut transmettre une modification très rapide. Si personne ne s'est entendu sur le responsable de ce changement, une erreur peut être transmise tout aussi rapide. Choisissez un propriétaire pour l'enregistrement et si nécessaire, pour les détails individuels au sein de cet enregistrement.

Par exemple, les ventes peuvent gérer les détails de relations clients et les informations de contact principales. La finance peut gérer les détails liés au paiement, l'exploitation peut gérer les détails de produits et de stocks. Votre répartition exacte dépend du fonctionnement de votre entreprise et elle doit être documentée et comprise par les utilisateurs des applications. Il existe également deux termes que vous pourriez rencontrer après que l'écriture double de Write et Entendue Dataverse Party et Dataverse Party Company. Une partie back est la manière dont Microsoft gère une personne ou une organisation de façon cohérente. Cela aide à relier les personnes, les organisations, les contacts et les adresses sans traiter. Chaque relation comme un enregistrement séparé et non lié. Une entreprise que aide Dataverse à comprendre le contexte de société commerciale utilisée par Finance et Operations.

Vous n'avez pas besoin de devenir un expert de ces deux termes dès le premier jour. Sachez simplement qu'ils existent car Finance & Operations gère des structures métiers que les applications clients doivent reconnaître lorsque les enregistrements passent d'un côté à l'autre. Une fois que les enregistrements peuvent circuler dans les deux sens, le processus associé compte tout autant que les données elles-mêmes. Comment un changement se propage entre les applications ? Suivons un changement dans le système pour voir ce qui se passe réellement. Un commercial est en ligne avec un client qui vient de déménager d'un nouveau bureau. Au cours de cette conversation, il ouvre la fiche client dans Dynamics 365 Sales et met à jour l'adresse postale. Assez simple, n'est-ce pas ? Ensuite, il enregistre la fiche. C'est là que la partie intéressante commence. Sales stock ce changement dans Dataverse qui est la plateforme de données pour les applications orientées clients.

Ensuite, la double écriture vérifie le mappage qui relie les informations clients et d'adresse entre ce site et Finance & Operations. Elle transmet automatiquement la modification correspondante. Pas de fichier d'exportation qui traîne dans un dossier partagé en attendant quelqu'un. Personne n'a besoin d'envoyer un email à la finance avec une note disant « Eh, merci de mettre à jour cette adresse. » Le mappage sait déjà quels champs sont liés et envoie la modification directement à la fiche client associée dans Finance & Operations. Ainsi, un utilisateur finance peut ouvrir cette fiche client plus tard, voir l'adresse mise à jour et traiter une commande ou préparer une facture sans interrupture, sans interruption. C'est le résultat pratique tout simplement. Deux personnes continuent de travailler dans des applications différentes sans avoir retapé les mêmes détails clients. Le commercial travaille sur un écran conçu pour les échanges avec les clients.

L'utilisateur finance travaille sur un écran conçu pour les tâches financières. Chacun envoie les informations clients dont il a réellement besoin, là où il en a besoin, là où il en a besoin. Et le voyage fonctionne aussi dans l'autre sens. Imaginez que la finance mette à jour des informations clientes dans Finance & Operations. Disons qu'un utilisateur finance corrige un détail qui concerne la fiche client opérationnelle. La double écriture utilise le mappage correspondant en sens inverse et envoie cette mise à jour à Dataverse. Ensuite, Sales ou toute autre application basée sur Dataverse peut la récupérer. Cette connexion est synchrone pour le travail quotidien normal. Synchrone signifie que les applications tentent d'effectuer la mise à jour au même moment, au lieu de la confier à une tâche de fond qui ne s'exécuterait que 20 minutes plus tard. Si la connexion ne peut pas effectuer la mise à jour, ce problème doit être traité immédiatement sans rester caché jusqu'à ce que quelqu'un remarque une incohérence.

Ce comportement est logique pour des enregistrements métiers partagés. Vous ne voulez pas qu'une adresse client, un détail produit ou toute autre information partagée divergent pendant des heures parce qu'un traitement par l'eau n'a pas encore été lancé. Les gens prennent des décisions basées sur ce qu'ils voient sur leur écran à l'instant présent. Ainsi, la connexion maintient les deux côtés en synchronisation pendant le travail. Pourtant, le travail en direct nécessite parfois une pause contrôlée. La double écriture inclut des options de lecture, de pause et de rattrapage. La lecture signifie que le mappage est actif et que les modifications prises en charge en transmisant. La pause arrête temporairement le mappage lorsqu'une équipe doit effectuer des travaux planifiés, enquêter sur un problème ou gérer un changement en toute sécurité. Mais la pause n'est pas un espace de stationnement permanent.

Pendant qu'un mappage est en pause, les modifications peuvent être mises en fil d'attente pour une durée, un espace et demi. Lorsque le mappage reprend, le rattrapage traite ces modifications en attente. Cela aide les équipes à se rétablir après une interruption planifiée. Cependant, quelqu'un doit être responsable de cette pause et savoir quand le mappage doit redémarrer. Avant que tout cela ne commence dans le travail quotidien, il existe une autre étape, la synchronisation initiale. La synchronisation initiale amène les enregistrements existants des deux côtés vers un point de départ commun. Imaginez une entreprise qui a déjà des clients dans Finance and Operations et des enregistrements clients dans Dataverse. La connexion ne peut pas simplement être activée en supposant que chaque enregistrement existant correspond déjà parfaitement. Elle a besoin d'une ligne de départ. La synchronisation initiale aide à transférer les données existantes avant que les utilisateurs ne comptent sur les mises à jour en direct.

Ce travail nécessite de la prudence car les doublons, les adresses incomplètes et les anciennes données de test ne se nettoient pas par magie au lancement d'une synchronisation. Ils peuvent en fait créer des problèmes plus rapidement si les enregistrements ne respectent pas les règles convenues. Une fois les mappages en cours d'exécution, les personnes qui gèrent la double écriture ont besoin d'un espace clair pour vérifier son état de santé. La double écriture fournit des journaux d'activités et d'erreurs combinées afin que les administrateurs puissent voir ce que la connexion a traité et où elle a rencontré des difficultés. Ils peuvent également définir des alertes et des solides. Cela signifie que les bonnes personnes sont informées des problèmes avant que les utilisateurs ne les découvrent par une mise à jour manquante ou échouée. Cette vue de support est importante car chaque erreur a une cause.

Peut-être qu'un champ obligatoire est manquant. Peut-être qu'un enregistrement lié n'est pas encore rêvé. Peut-être que quelqu'un a modifié des données d'une manière incompatible avec le mappage. Réessayer un enregistrement échoué sans corriger la cause entraîne généralement le même échec. Une configuration de double écriture bien gérée surveille la connexion, corrige la raison des erreurs et concentre les mappages sur les enregistrements qui doivent vraiment rester connectés. Ou la double écriture s'adapte. La double écriture est idéale lorsque votre entreprise utilise Dynamics 365 Finance ou Supply Chain Management parallèlement à des applications orientées clients comme Sales, Customer Service, Field Service, Customer Service ou Project Operation. Ces applications prennent en charge différentes parties d'une même conversation commerciale. échange avec le client, une autre planifie la livraison, gère les stocks, suit les coûts ou envoie la facture.

Lorsque les deux groupes doivent travailler sur des enregistrements liés au quotidien, la double écriture peut connecter ce travail sans forcer tout le monde à utiliser la même application. Prenons l'exemple d'un processus prospect vers encaissement. Un commercial travaille avec un client potentiel dans Danix 365 Sales. Il assure le suivi du contact, discute des produits, établit un devis et avance vers une commande. Durant cet échange, le commercial a besoin des détails du client, d'informations sur les produits, des tarifs et des données de commande liées au service financier de l'entreprise. Une fois la vente conclue, la gestion financière et de la chaîne logistique prend le relais pour le travail qui suit l'engagement. Elle gère l'exécution de la commande, la facturation des stocks et les enregistrements financiers. La double écriture aide ces deux parties à rester connectées. Les commerciaux peuvent travailler dans l'application client adaptée à leur métier, tandis que la finance et les opérations gèrent la transaction dans l'application conçue pour leur travail.

Le client ne devient pas deux histoires distinctes, l'une racontée par les ventes et l'autre par la finance. Le service sur site fournit un autre bon exemple. Imaginez une entreprise qui envoie des techniciens installés, réparés ou entretenir des équipements chez des clients. L'agent sur site a besoin des coordonnées du client, de détails sur le travail et d'informations sur l'actif client correspondant à l'équipement installé ou pris en charge par l'entreprise. En coulisses, l'entreprise doit également suivre les pièces, les coûts, les achats et les flux financiers liés à cette intervention. Le service sur site se concentre sur la planification et l'achèvement de l'intervention. La finance et les opérations se concentrent sur les données opérationnelles et financières qui y sont associées. Lorsque ces enregistrements sont correctement connectés, le travail du technicien n'est plus dissocié des pièces utilisées, du coût du travail ou du dossier client associé.

Project Operations suit le même modèle, en particulier pour les entreprises qui vendent des prestations par projet. Une équipe projet peut gérer le travail client, le temps des collaborateurs, les coûts prévus et les jalons du projet. La finance doit avoir une vision de l'aspect financier des achats, des coûts de la facturation et du reporting. Sans connexion, les chefs de projet peuvent passer trop de temps à solliciter la finance

et le projet confirme ce qui s'est passé. Des enregistrements de projets connectés offrent aux deux groupes une vue plus claire du travail, depuis l'engagement client jusqu'à l'activité financière. Il existe également un avantage plus large lié à Power Platform. Comme l'application client utilise Dataverse, les données approuvées dans Dataverse peuvent alimenter Power Apps et Power Apps et Power Automate. Une entreprise peut créer une petite application pour une équipe interne ou configurer un flux qui réagit lorsqu'un enregistrement métier atteint un certain stade. Cela ne signifie pas que chaque enregistrement financier et opérationnel doit soudainement figurer dans chaque application Power. Cela signifie que les enregistrements connectés peuvent faire partie d'un ensemble plus large d'outils professionnels à condition que l'entreprise choisisse cet objectif avec soin et protège les données correctement.

Une limite doit rester claire. La double écriture DualWrite ne prend pas en charge Dynamics 365 Business Central. Business Central peut se connecter à d'autres produits Microsoft par d'autres méthodes. Mais la double écriture est destinée au volet finance et opération de Dynamics 365 et aux applications clients basées sur Dataverse. Ce n'est pas non plus un outil pour copier chaque table que vous pouvez trouver. Un enregistrement doit être déplacé parce que les utilisateurs ont besoin du même enregistrement opérationnel aux deux endroits. Pas parce que copier des données semble plus sûr. La double écriture ne remplace pas non plus un plan d'intégration plus large lorsqu'une entreprise a besoin de flux de reporting, de liens vers des systèmes tiers ou d'une migration de données importantes. Traiter chaque connexion de données comme une tâche identique crée rapidement des problèmes. Limite, préparation et erreur courante.

Voyez la double écriture comme un accord conclu entre deux systèmes. Il convient de garder certains enregistrements partagés et synchronisés mais ce n'est pas un canal magique pour chaque table, rapport ou système externe. Avant de la configurer, vérifiez quelles intégrations existent déjà. Si une ancienne connexion et la double écriture mettent à jour le même enregistrement client, vous pouvez rapidement créer des conflits. C'est un casse-tête dont vous n'avez pas besoin. Alors mettez-vous d'abord d'accord sur les bases. Comment allez-vous saisir des noms ? Quelle entité juridique détient chaque enregistrement ? Qui peut effectuer des modifications ? Quels rôles de sécurité sont nécessaires pour chaque équipe ? Éliminez les doublons et les enregistrements incomplets avant la première synchronisation. Commencez par les mappages préétablis de Microsoft. Connecte déjà les enregistrements courts.

Les tables et champs personnalisés eux nécessitent des tests minutiaux. Vérifiez les tables liées et les dépendances de mappage car parfois un enregistrement doit en précéder un autre pour pouvoir être synchronisé. Planifiez votre première synchronisation en fonction du volume de données. Ne traitez pas cela comme un interrupteur que vous actionnez pendant le déjeuner. Cela causera des problèmes. Un mappage en pause nécessite toujours un responsable et un plomb de redémarrage. Les modifications en fil d'attente et les enregistrements ayant échoué ne restent pas définies. Surveillez les journaux d'activité, les erreurs, les alertes et les seuils. En cas d'échec, trouvez le champ manquant, l'enregistrement erroné ou la règle rompue qui en est la cause. Les tentatives répétées ne corrigeront pas des données incorrectes. Lorsque vous percevez la double écriture comme un pont contrôlé, tout prend sa place.

Conclusion, une conversation métier partagée. La double écriture maintient la circulation des enregistrements partagés pris en charge entre la finance et les opérations et vos applications cliquées en basée sur DataLars. Ainsi, les équipes peuvent travailler à partir de données commerciales connectées. Abonnez-vous sur votre plateforme de podcast préférée pour plus de pépites de connaissances avec moi, Mirko Peters sur m365.fm et partagez cet épisode avec quelqu'un qui connecte encore les ventes, le service et la finance via une énième feuille de calcul.