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

15 minutes

Cette unité décrit 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 la configuration avec de nombreuses tables redondantes, vous nuisez aux performances du système et au final, à sa convivialité. (De nombreuses tables de sondage redondantes déroutent les utilisateurs dans la Recherche avancée.) Chaque table personnalisée doit servir un objectif spécifique. Cette rubrique vous permet également d’identifier les tables les plus utilisées et de déterminer si vous risquez de surcharger des tables.

Déterminer s’il faut remplacer des tables standard par des tables personnalisées

Parfois, les configurateurs envisagent de remplacer les fonctionnalités standard par des tables personnalisées, par exemple s’ils ont besoin non seulement d’une opportunité de vente, mais aussi d’un formulaire plus simple que le formulaire d’opportunité standard. Cependant, vous devez tenir compte des options auxquelles 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, des tables standard vous permettent de bénéficier plus 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 de Sales Insights et d’autres fonctionnalités d’IA.

Pour les tables sectorielles, envisagez d’utiliser Common Data Model. Outre le système de métadonnées, Common Data Model comprend un ensemble de schémas de données extensibles standardisés publiés par Microsoft et ses partenaires. Cette collection de schémas prédéfinis comprend des tables, des attributs, des métadonnées sémantiques et des relations. Microsoft travaille en étroite collaboration avec des acteurs de divers secteurs pour rendre Common Data Model plus pertinent en créant des accélérateurs sectoriels.

Les accélérateurs sectoriels sont des composants fondamentaux de Microsoft Power Platform et Dynamics 365 qui permettent aux éditeurs de logiciels indépendants (ISV) et à d’autres fournisseurs de solutions de créer rapidement des solutions sectorielles. Les accélérateurs étendent Common Data Model pour inclure de nouvelles tables, afin de prendre en charge un schéma de données pour des concepts de secteurs spécifiques. Microsoft se concentre actuellement sur l’offre d’accélérateurs pour les secteurs suivants :

Industrie automobile
Services financiers (notamment les services bancaires et l’assurance)
Éducation (notamment l’enseignement supérieur, primaire et secondaire)
Associations
Industrie
Médias
Communication

Ne pas recréer les comptes et les contacts

Lors du déploiement de Dynamics 365, vous suivrez souvent plusieurs types de sociétés, d’organisations et de contacts dans le système. Certains types représentent des organisations client/clients finaux, d’autres peuvent être des organisations de services professionnels et de conseil, comme des cabinets comptables et des cabinets d’avocats, et d’autres encore peuvent être divers types d’organisations, par exemple des associations professionnelles.

Par conséquent, vous devrez déterminer comment gérer plusieurs catégories de relations d’entreprise. L’approche la plus courante consiste à utiliser la table de compte pour tous les types d’organisation, puis une colonne telle que le type de relation ou des colonnes de choix personnalisées pour marquer les sociétés selon leur type ou leur catégorie. Les vues peuvent être filtrées 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 à l’aide de la double écriture, la meilleure option à votre disposition consiste à 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é. L’une des raisons fréquemment citées est que les utilisateurs peuvent avoir besoin d’utiliser des comptes pour une autre raison à l’avenir. Ils ne souhaitent donc pas personnaliser la table de compte.

Avant de recréer la table de compte en tant que table de société personnalisée, réfléchissez bien aux options auxquelles vous renoncez en créant une table personnalisée, par exemple les suivantes :

Adresses multiples : la table de compte offre une fonctionnalité d’adresse unique prenant en charge plusieurs adresses. Les deux premières adresses s’affichent 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 signifie que 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.
Tables de société : le contrôle de mappage standard des applications pilotées par modèle ne prend pas en charge les tables de société personnalisées.
Relations hiérarchiques : les relations 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.
Colonne client : Dynamics 365 comprend un type spécial de colonne de recherche polymorphe appelé colonne client. Cette colonne permet d’associer un enregistrement à une société/un compte ou un contact. Dynamics 365 ne permet pas de sélectionner des tables personnalisées à partir de colonnes de recherche polymorphes.
Marketing : les listes marketing peuvent fonctionner uniquement avec des contacts, des comptes et des prospects, et non des tables personnalisées. Microsoft Dynamics 365 Marketing peut effectuer des envois à des comptes et des contacts, mais pas à des tables de société personnalisées.

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 existant uniquement à 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 vous ne souhaitez pas polluer la table de compte. Dans ces situations, vous pouvez utiliser la table de prospect.

Déterminer s’il faut reconvertir des tables système

Envisageons un scénario où vous avez un besoin métier similaire à une opportunité, mais il ne s’agit pas d’une opportunité de vente. Dans ce scénario, vous devez déterminer s’il faut reconvertir des tables système ou créer des tables.

Les sections suivantes détaillent les situations à prendre en compte avant de reconvertir des tables système.

L’avenir

Dynamics 365 évolue bien plus rapidement que jamais. L’utilisation de tables de manière non standard peut donc poser des problèmes si Microsoft modifie la table que vous utilisez. De plus, si vous choisissez de reconvertir une table système rarement utilisée telle que la table de contrat, vous vous exposez au risque 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, vous pourriez rencontrer des problèmes ultérieurement si vous en avez besoin aux fins prévues. Dans certains cas, des clients ayant reconverti une 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.

Continuer