Vérifier les doublons clients avant une migration de données

Avant une migration, déterminez quels enregistrements représentent le même client. Un nom d’entreprise identique est un indice de recherche, pas une preuve d’identité suffisante. Une nouvelle adresse peut appartenir à un client existant ; deux entreprises homonymes peuvent rester deux clients distincts.

Microsoft Dataverse distingue les doublons possibles de leur fusion ultérieure. Les champs qui déclenchent une correspondance dépendent des règles configurées. Une recherche de similarité ne remplace donc pas votre décision métier.

Distinguer trois enregistrements aux identités vérifiées

Cet exemple est entièrement fictif. Les trois enregistrements source portent le nom Beispiel Technik GmbH. Les références d’organisation ont déjà été vérifiées pour l’exemple ; ce ne sont pas des identifiants officiels. Le déménagement de l’organisation de l’ancienne adresse Nordweg vers Parkweg a aussi été confirmé. Le tableau décrit des décisions de migration attendues, pas les résultats d’un import réalisé.

Les deux premières lignes restent distinctes malgré le même nom. La première et la troisième correspondent à la même organisation malgré des adresses différentes. Dans l’exemple, Parkweg 6 devient l’adresse actuelle du client K-900. Cela ne doit pas modifier silencieusement une ancienne adresse de livraison dans une commande existante.

Consigner les preuves et les cas incertains avant l’import

Faites vérifier les correspondances avec des preuves d’identité adaptées et acceptées dans le projet. Des références fiables et des documents de données maîtres traçables peuvent les étayer. Les identifiants du tableau représentent le résultat de cette vérification. Ils ne doivent pas être déduits d’un nom similaire.

Sans preuve fiable, la correspondance reste ouverte. Consignez les candidats, le motif de clarification et le rôle responsable. Créer un nouvel enregistrement exige une décision confirmée sur le client ; cela ne doit pas servir à contourner une vérification d’identité manquante. Une fusion peut aussi affecter les enregistrements liés : vérifiez le fonctionnement précis du produit avant de l’utiliser.

Réutiliser durablement la correspondance confirmée

Conservez le lien entre source et cible pour qu’un transfert ultérieur reconnaisse le même enregistrement. Dans notre conception, (sourceSystem, sourceId) constitue la référence source unique. Elle est liée à l’identifiant cible confirmé. Ces noms de champs décrivent notre exemple, pas l’API Dataverse.

Dataverse documente les clés alternatives constituées d’une combinaison unique de valeurs de colonnes. Vérifiez pendant l’étude technique les clés et restrictions réellement prises en charge par vos systèmes. Une liste de correspondances n’impose pas à elle seule l’unicité dans la cible.

Tester aussi la répétition et les relations

Transférez d’abord les données d’exemple dans un environnement de test adapté. Vérifiez les deux clients cibles distincts, la correspondance commune de l’organisation qui a déménagé et son adresse actuelle. Soumettez ensuite les mêmes références source : aucun client supplémentaire ne doit être créé.

Vérifiez aussi à quel client cible se rattachent les commandes transférées et si les adresses des documents historiques sont conservées. Si une correspondance confirmée change plus tard, ses effets sur les liens existants doivent être examinés séparément.

Sources

• Microsoft — Detect duplicate records and merge

• Microsoft — Define alternate keys