Bonnes pratiques relatives à Dataverse

  • 5 minutes

La modélisation des données est une science, qui compte des professionnels et des normes établies. Pour être efficace avec la modélisation de données Dataverse, vous n’avez pas besoin d’être un modélisateur de données professionnel, ni d’utiliser des outils spéciaux. Des outils populaires tels que Microsoft Visio peuvent être utilisés pour créer rapidement un schéma entité/association (ERD) de base qui visualise les relations et le flux de données entre les tables.

Dans cette unité, nous aborderons quelques bonnes pratiques générales pour la modélisation de données pour les déploiements Dataverse, notamment :

  • Les modèles de données doivent être mis à jour en permanence pendant un déploiement. Il est fréquent qu’un modèle de données soit conçu au début d’un projet, mais il est important que ce processus de conception ne s’arrête pas là. Au fur et à mesure du déploiement, de nouvelles colonnes et tables sont ajoutées. Vous devez capturer ces nouvelles colonnes et tables dans le modèle de données et d’en faire un modèle de données vivant. En outre, vous devez recommander aux clients de continuer à mettre à jour le modèle de données au fur et à mesure qu’ils améliorent le système.

  • Utilisez des outils éprouvés pour démarrer. Les outils communautaires disponibles avec XrmToolBox facilitent la génération rapide de schémas ERD de votre configuration Dataverse. Ces outils sont le générateur UML et le créateur de schémas entité/association (ERD). Après avoir terminé les mises à jour de configuration, vous pouvez générer un schéma ERD à jour.

  • N’incluez pas chaque table. Certaines tables principales, comme Activité, Note et Utilisateur (propriétaires d’enregistrements), sont associées à la quasi-totalité des tables dans Dataverse. Si vous incluez toutes les relations avec ces tables dans votre modèle de données, le résultat sera illisible. Il est recommandé d’inclure dans votre schéma de modèle de données uniquement les tables principales exploitées dans votre configuration et des relations personnalisées avec les tables Utilisateur et Activité pour optimiser la lisibilité.

  • Les modèles de données doivent inclure des tables en dehors de Dataverse. Si vous effectuez une intégration à d’autres systèmes à l’aide de connecteurs de données ou tables virtuelles Dataverse ou si vous intégrez des flux de données qui circulent en dehors de Dataverse à l’aide d’une intégration, ces données doivent également être représentées dans votre schéma de modèle de données.

  • Commencez simplement, avec les tables standard, puis ajoutez des relations de table personnalisées à votre modèle de données.

  • L’expérience doit influencer votre modèle de données. Parfois, il est facile de sur-normaliser vos données, mais cela peut rendre l’application plus lourde à utiliser.

Commencez avec ce dont vous avez besoin maintenant, mais concevez le modèle de données de manière à prendre en charge ce que vous ferez à l’avenir. Par exemple, si vous savez qu’à l’avenir, vous devrez stocker des détails supplémentaires sur les secteurs de vente, l’utilisation d’une colonne de texte pour le secteur rendra l’implémentation plus difficile que si vous utilisiez la relation de table de secteur. Prévoyez à l’avance vos besoins futurs.

Entités prêtes à l’emploi et tables personnalisées

Dans cette rubrique, nous identifions les tables standard prêtes à l’emploi utilisées dans la configuration, ainsi que les tables personnalisées et leur raison d’être. Ces informations sont importantes, car Microsoft Dataverse offre de nombreuses tables courantes et en général, une table personnalisée ne doit pas être créée s’il existe déjà une table standard qui sert l’objectif concerné. En effet, si vous surchargez votre configuration avec de nombreuses tables redondantes, vous nuisez aux performances du système et à sa convivialité. (De nombreuses tables semblant redondantes déroutent les utilisateurs dans la Recherche avancée.) Chaque table personnalisée doit servir un objectif spécifique.

En outre, cette rubrique vous permet également d’identifier les tables les plus utilisées et de déterminer si vous risquez de surcharger des tables.

Envisagez de remplacer des tables standard par des tables personnalisées

Parfois, les fabricants envisagent de remplacer les fonctionnalités standard par des tableaux personnalisés. En effet, ces derniers ont besoin non seulement d’une opportunité de vente, mais aussi d’un formulaire plus simple que le formulaire d’opportunité standard, par conséquent il est plus simple de personnaliser une table. Cependant, vous devez tenir compte de ce à quoi vous pouvez renoncer en utilisant une table personnalisée au lieu d’une table standard. L’utilisation d’une table prête à l’emploi garantit un meilleur alignement sur les fonctionnalités de base de la plateforme. Comme des fonctionnalités supplémentaires sont régulièrement ajoutées, l’utilisation de tables standard permet de bénéficier facilement des nouvelles fonctionnalités lorsqu’elles sont publiées. Par exemple, si vous décidez de remplacer la table d’opportunité standard par une table d’opportunité personnalisée, vous ne pouvez pas tirer parti du complément Sales Insights pour Microsoft Dynamics 365 Sales et d’autres fonctionnalités d’IA.

Ne pas recréer les comptes et les contacts

Lors du déploiement de solutions Microsoft Power Platform, vous suivrez souvent plusieurs types de sociétés, d’organisations et de contacts dans le système. Certaines de ces entités représentent des organisations de clients, tandis que d’autres peuvent être des organisations de support et de conseil, comme des cabinets de comptables et d’experts juridiques. Certaines entités peuvent être des types d’organisations diverses, comme des associations professionnelles.

L’approche la plus courante vis-à-vis de la gestion de différentes catégories de relations d’entreprise consiste à utiliser la table de compte pour tous les types d’organisation et une colonne telle que le type de relation ou un groupe d’options personnalisé pour marquer les sociétés selon leur type ou leur catégorie. Vous pouvez filtrer les vues en fonction du type de société, et les règles métier peuvent afficher ou masquer conditionnellement des composants de colonne et de formulaire en fonction du type.

Afin de bénéficier d’une intégration standard aux applications de finances et d’opérations Dynamics 365 à l’aide de l’infrastructure de double écriture, il est préférable d’utiliser les tables et colonnes par défaut ajoutées par la solution principale de double écriture à votre environnement Dataverse.

Une autre approche consiste à créer des tables personnalisées pour chaque type de société. Voici l’une des raisons fréquemment citées : « Je peux avoir besoin d’utiliser des comptes pour une autre raison à l’avenir. Je ne souhaite donc pas personnaliser la table Compte. »

Avant de recréer la table Compte en tant que table de société personnalisée, réfléchissez bien à ce à quoi vous renoncez en créant une table personnalisée. Considérons les facteurs suivants :

  • Adresses multiples : la table Compte offre une fonctionnalité d’adresse unique qui prend en charge plusieurs adresses. Les deux premières adresses sont affichées sur le formulaire de la société, mais ces enregistrements d’adresses résident dans la table d’adresse client associée. Bien que vous puissiez créer une table d’adresse personnalisée liée à une table de société personnalisée, la recréation de la logique unique où les adresses sont stockées dans la table associée et affichées sur le formulaire et les vues de table nécessitent un développement. Si vous avez besoin de plusieurs adresses, utilisez la table de compte.
  • Hiérarchie des contacts : les comptes sont les parents des contacts. Les activités associées aux contacts sont reportées dans l’enregistrement de compte parent. Cette hiérarchie ne peut pas être remplacée par un enregistrement de société personnalisé. Vous pouvez créer des relations supplémentaires avec des tables de société personnalisées, mais la relation compte/contact standard ne peut pas être remplacée. Si la société dispose de contacts avec des relations de société principales avec ce type de société ou si vous souhaitez reporter les activités des contacts dans les sociétés, utilisez la table de compte.
  • Contrôle de mappage standard : dans les applications pilotées par modèle, le contrôle de mappage standard ne prend pas en charge les tables de société personnalisées.
  • Relations hiérarchiques : les relations hiérarchiques entre les comptes parents/enfants et la visualisation de hiérarchie standard et le report des activités de compte enfant dans le compte parent fonctionnent uniquement avec les tables de compte standard.
  • Colonnes de recherche polymorphes : Dataverse comprend un type spécial de colonne de recherche polymorphe appelé colonne client. Cette colonne permet d’associer une ligne à une société/un compte ou un contact.
  • Marketing n’est pas compatible : les listes Marketing peuvent fonctionner uniquement avec des contacts, des comptes et des prospects, et non des tables personnalisées. Microsoft Dynamics 365 Customer Insights - Journeys peut effectuer des envois à des comptes et des contacts, mais pas à des tables de société personnalisées.

Par conséquent, dans la quasi-totalité des cas, la table de compte doit être utilisée pour les enregistrements de société de tous types, avec les exceptions suivantes :

  • Types mineurs de sociétés non relationnelles et ayant des attributs minimaux, par exemple un type d’organisation sans contacts, ni adresse et qui n’existe qu’à des fins de recherche.
  • Sociétés non qualifiées ou non vérifiées importées de cartes de visite ou de formulaires web dont nous ne souhaitons pas polluer la table Compte. Dans ces situations, vous pouvez utiliser la table Prospect.

Reconvertissez les tables système

Envisageons le scénario où vous avez un besoin métier similaire à une opportunité, mais il ne s’agit pas d’une véritable opportunité de vente. Dans ce cas, vous pouvez envisager de reconvertir des tables système ou de créer de nouvelles tables.

Les sections suivantes détaillent les facteurs à prendre en compte avant de réutiliser les tables système.

L’avenir

Microsoft Power Platform évolue plus rapidement que jamais. L’utilisation de tables de manière non standard peut donc poser des problèmes si Microsoft apporte des modifications à la table que vous utilisez. De plus, si vous choisissez de reconvertir une entité système peu utilisée telle que la table Contrat, il est possible que Microsoft choisisse de la déconseiller à l’avenir. Les tables personnalisées ne sont pas déconseillées. En outre, si vous reconvertissez une table système, pensez à ce que vous feriez ultérieurement si vous en avez besoin aux fins prévues. Des clients ayant reconverti la table d’incident ont par la suite eu besoin d’une gestion des incidents et ont dû répondre à ce besoin avec des tables personnalisées, car la table d’incident standard était déjà utilisée à des fins radicalement différentes.

La surcharge

Certaines colonnes de nombreuses tables système ne peuvent pas être supprimées des formulaires, par exemple certaines colonnes des tables d’opportunité, d’incident et de campagne. Bien que vous puissiez masquer ces colonnes, la présence de nombreuses colonnes verrouillées sur le formulaire peut surcharger la configuration de votre environnement.

L’expérience utilisateur

Si votre cas d’utilisation correspond à moins de 50 % à la fonctionnalité de table standard, une table personnalisée offre généralement une expérience utilisateur plus simple que la simplification d’une table système plus complexe. Il est également possible d’ajouter des flux de processus métier à toute table, notamment des tables personnalisées, ce qui peut rendre l’expérience utilisateur offerte par une table personnalisée aussi conviviale, sinon meilleure, que celle offerte par la reconversion d’une table système.

Éviter les pièges courants

Vous trouverez ci-dessous les problèmes courants de modélisation des données :

  • Trop de tables : les tables sont probablement sur-normalisées.
  • Trop de colonnes sur une table : une table séparée aurait dû être créée.
  • Utilisez les outils : visualiser rapidement les formulaires au lieu de répéter les colonnes.
  • Évitez le type de données Oui/Non : s’il peut y avoir plus de valeurs ou si vous devez stocker les valeurs comme Inconnu.
  • Formatage des pièges : vous ne pouvez utiliser rien d’autre que le formatage du type de données.
  • Éléments inutilisés : évitez de créer des éléments du modèle de données que vous ne prévoyez pas d’utiliser.

Preuve de concept

Dataverse facilite la création d’un environnement de test et la création de tables et de relations est rapide. Vous pouvez créer une preuve de concept pour tester votre modèle de données et voir à quoi pourrait ressembler l’expérience utilisateur.