Bienvenue dans Microsoft Knowledge Nugget, je suis Mo Peters. Le sujet d'aujourd'hui en déconcerte souvent plus d'un. Qu'est-ce que Dataverse exactement ? Est-ce une base de données, une application ou un service caché des Dynamics 365 que seuls les informaticiens doivent comprendre ? Voici la définition la plus simple. Dataverse est la base de données partagées qui alimente de nombreuses expériences Dynamics 365. Imaginez Dynamics 365 comme un immeuble de bureau. Les applications de vente, de services clients et autres sont les pièces où les gens travaillent, tandis que Dataverse est le système de classement et les règles derrière les murs. A la fin de cet épisode, vous saurez où résident les données Dynamics et comment une mise à jour client peut apparaître dans le travail commercial, l'automatisation et les rapports. Mais avant d'aborder les noms de produits, commençons par le désordre métier.

Ceci permet de disposer d'un placement partagé unique. Au lieu de copies séparées, imaginez une entreprise avec une équipe commerciale, une équipe de support et une équipe financière. Les ventes conservent les détails des clients dans une feuille de calcul. Le support travaille dans un outil de gestion d'éthique est distinct. La finance possède les noms des clients dans son propre système. Quelqu'un d'autre enregistre des fiches de discussion par email dans une boîte partagée, tandis qu'une autre personne garde des notes dans un dossier que personne d'autre ne trouve. Le même client existe désormais à cinq endroits différents. Cette configuration semble normale au début, car chaque équipe ne voit que la partie du travail qui se trouve devant elle. Mais voici le problème. Dès qu'un client change de numéro de téléphone, d'adresse, de nom d'entreprise ou de contact principal, les ennuis commencent.

Les ventes mettent à jour la feuille de calcul. Le support ne le voit pas. La finance continue d'envoyer des documents à l'ancienne adresse. Ensuite, quelqu'un exporte une liste, la nettoie manuellement, l'envoie par email et soudainement, trois personnes pensent chacune que leur copie est la bonne. À quelle liste devez-vous vous fier ? Cette question fait perdre plus de temps que vous ne pourriez le penser. Le personnel s'arrête pour comparer les enregistrants. Les managers demandent pourquoi un rapport ne correspond pas au système de vente. Un agent de support ouvre un dossier pour un client dont les détails existent déjà ailleurs, avec de légères différences. Personne n'essaie de craindre des ordres. Le désordre provient de la multiplication des ordres. Il y a 20 ans, des systèmes distincts signifiaient des serveurs séparés, des bases de données séparées, conservant leurs propres informations.

Les connecter demandaient un travail sur mesure, des importations planifiées et beaucoup de vérifications manuelles. Un changement à un endroit pouvait atteindre un autre système le lendemain la semaine suivante, ou jamais. Dataverse offre aux applications métiers un espace partagé pour ce type d'informations. Pour le dire simplement, Dataverse est la plateforme de données cloud de Microsoft pour les informations professionnelles. Elle stocke ces informations dans des tables structurées, afin que les données aient une forme claire, au lieu de vivre sous forme de notes aléatoires, de fichiers épars et d'onglets de tableurs déconnectés. Voyez cela, comme le classeur de l'entreprise, mais que plusieurs outils approuvés peuvent utiliser simultanément. Un client apparaît une seule fois dans Dataverse. Ce client peut apparaître dans Dynamics 365 Sales lorsqu'un commercial travaille sur une affaire.

Les mêmes détails clients peuvent s'afficher dans Dynamics 365 Customer Service lorsqu'un agent traite une demande de support. Une PowerApp peut utiliser les mêmes informations clients pour un technicien ou un responsable de compte, sans que personne n'ait à copier les données dans une nouvelle application. Une seule ligne client, un point de référence partagé. Cela ne signifie pas que chaque équipe voit soudainement tout. L'accès nécessite toujours des règles, et nous y viendrons sous peu. Cela signifie que les applications approuvées peuvent travailler à partir des mêmes informations métiers au lieu de créer leur propre version concurrente. C'est pourquoi Dynamics 365 et Dataverse s'associent si naturellement. Les applications Dynamics 365, telles que Sales et Customer Service, utilisent Dataverse pour stocker et sécuriser leurs données de travail. Et voici le point important. Lorsqu'on parle d'intégrer Dynamics 365 à Dataverse, on imagine souvent deux produits distincts nécessitant un connecteur entre eux.

Pour de nombreuses applications Dynamics 365, ce n'est pas le cas. Les données résident déjà dans Dataverse. Vous ne sortez pas une liste de clients de Dynamics 365 pour la copier dans une autre base de données, en espérant que les deux restent à jour. Vous pouvez bâtir sur la même fondation, en utilisant les mêmes informations métiers que Dynamics 365 utilise déjà. Cela change la donne. Au lieu de demander comment synchroniser ces deux listes de clients, vous pouvez demander quelles personnes et applications doivent travailler avec ce dossier client et ce que chacune est autorisée à faire. Bien sûr, Dataverse ne remplace pas tous les systèmes d'une entreprise. Une entreprise peut encore utiliser des logiciels financiers, des outils métiers, des systèmes d'entrepôt, des sites web ou d'anciennes applications contenant leurs propres données. Dataverse n'est pas une colle magique qui élimine tous les systèmes externes du jour au lendemain.

Ce qu'il vous offre, c'est un emplacement commun pour les données métiers que les applications connectées doivent partager. Détails des clients, travail de vente, support, tâches et suivi. Ces enregistrements peuvent coexister dans une source unique que les outils approuvés peuvent lire et mettre à jour. Alors ouvrez ce classeur avec moi. Une fois que vous voyez comment Dataverse organise les informations, toute la connexion Dynamics 365 devient beaucoup plus facile à comprendre. Le classeur, les tables, les lignes, les colonnes et les relations. Ouvrons ce classeur. Dans Dataverse, les informations sont stockées dans des tables. Voyez cela comme un vrai meuble avec des tiroirs séparés. Un tiroir contient les entreprises, un autre les personnes et un troisième les demandes de support. Ou ne jetez pas tous les papiers dans un seul grand tiroir en espérant que quelqu'un pourra trier cela plus tard.

Chaque tiroir a sa fonction. Dans Dataverse, une table contient un type d'informations métiers. Une table de comptes contient généralement les entreprises avec lesquelles vous travaillez. Une table de contacts contient des personnes physiques. Une table de prospects contient les clients potentiels, avant qu'ils ne deviennent des clients réels. Une table de cas contient les demandes de support, tandis qu'une table d'activités peut suivre le travail comme les appels, e-mails, rendez-vous et tâches. Ce sont des tables standards. Microsoft les inclut, car la plupart des entreprises doivent suivre leurs clients, leurs contacts, leur travail et leurs échanges. Il est inutile d'inventer une nouvelle table pour quelque chose de courant si une table standard convient déjà. Mais chaque entreprise a aussi son propre fonctionnement. Un organisme de formation pourrait avoir besoin de suivre des cours et des certificats.

Une entreprise immobilière peut avoir besoin de bâtiments d'unités et d'inspection. Fabricants pourraient suivre des contrôles d'équipement ou des visites de maintenance. Dans ces cas-là, vous pouvez créer des tables personnalisées qui correspondent au travail réel de votre entreprise. Considère une table personnalisée comme l'ajout d'un nouveau tiroir au meuble. Avec une étiquette claire, Chaque table contient des lignes. Une ligne est un élément dans ce tiroir. Par exemple, Une ligne dans la table de contact pourrait représenter Maria Gomez, une personne chez un client. Sa ligne contient ses propres détails, séparés de tous les autres contacts du système. Les colonnes décrivent les détails que vous souhaitez conserver pour chaque ligne. La ligne de contact de Maria peut comporter des colonnes pour son prénom, nom, adresse e-mail, numéro de téléphone, intitulé de poste, entreprise, propriétaire de l'enregistrement et statut.

Une colonne définit le type d'information qui doit figurer à cet endroit. Ainsi, une colonne e-mail attend une adresse e-mail et une colonne de statut peut contenir les choix de statut approuvés. C'est ainsi que les informations métiers prennent une forme fiable. Sans colonne, une personne pourrait saisir un numéro de téléphone dans une case de notes, une autre dans un champ de nom et quelqu'un d'autre pourrait ne pas le saisir du tout. Avec une table de contact clair, tout le monde travaille avec le même ensemble de détails aux mêmes endroits. Cette structure aide également les applications à comprendre les deux. Un formulaire peut afficher les bonnes cases, un rapport peut regrouper les contacts par statut et une automatisation peut réagir lorsqu'un propriétaire change. L'information n'est pas seulement stockée, elle possède des étiquettes qui indiquent aux outils connectés la signification de chaque élément.

Commencez avec les tables standards lorsqu'elles correspondent à vos besoins professionnels. Si vous vendez à des entreprises, les comptes et les contacts décrivent déjà un modèle que la plupart des gens comprennent. Si vous gérez le support client, les cas constituent un point de départ. Ajoutez ensuite des tables personnalisées uniquement là où votre entreprise possède des informations qui ne correspondent pas au modèle intégré. Cela permet d'éviter un problème courant. Créez cinq tables différentes qui signifient toutes client-puc. Une équipe l'appelle client-huc, une autre maître client-huc et une troisième contact-partenaire-huc. Très vite, les utilisateurs ne savent plus quelles tables ils doivent utiliser. Des tables standards claires et des tables personnalisées bien nommées rendent le système compréhensible à mesure qu'ils s'étoffent. La suite consiste à faire travailler ces tiroirs ensemble.

Un contact appartient à un compte. Maria travaille pour Contozo Lutel. Au lieu de ressaisir l'adresse, le numéro de téléphone et les détails de Contozo dans la ligne de Maria, Dataverse peut créer une relation entre la table des contacts et celle des comptes. Maria est liée à Contozo et ce lien est important car les informations de l'entreprise restent attachées à l'entreprise. Si Contozo change d'adresse, il suffit de mettre à jour la ligne du compte une seule fois. Chaque contact associé pointe toujours vers la même entreprise sans avoir à stocker sa propre copie obsolète. Les relations permettent aussi de lier un ticket de support au client qui l'a ouvert. Elles peuvent relier une opportunité commerciale aux appels, emails, réunions et tâches liées à cette vente. Lorsqu'un commercial ouvre une opportunité, il voit l'activité associée au lieu de chercher dans des notes ou des calendriers sans lien.

L'information a un contexte. Vous ne regardez pas simplement le numéro de dossier. Vous pouvez voir à quel client il appartient. Vous ne visualisez pas seulement un contexte. Vous pouvez voir l'entreprise liée à cette personne. Ces liens rendent les données utiles sans avoir à saisir plusieurs fois les mêmes informations à différents endroits. Une petite précision sur les noms. Avant que vous ne lisiez d'anciens guides ou ne regardiez de vieilles vidéos, vous pourriez entendre les termes « Entité, quelque chambre et quelque enregistrement ». Ce sont d'anciens termes Dataverse. Microsoft utilise désormais « Table K » au lieu d'entité, « Colonne K » au lieu de chambre et « Côte-Lieu d'enregistrement ». Le sens n'a pas changé. Si un ancien guide vous dit de créer une entité, il parle en réalité de créer une table, un champ est une colonne et un enregistrement est une ligne. Connaître les deux terminologies vous évitera de croire que vous avez trouvé un produit différent.

Les tables organisent donc les informations et les relations les connectent. Mais un système bien organisé nécessite tout de même des contrôles. Quelqu'un doit décider ce que les utilisateurs peuvent saisir, modifier et consulter en toute sécurité. C'est le rôle des règles et du contrôle, d'accès aux données. Le partage de données ne fonctionne que si les bonnes personnes peuvent y accéder en toute sécurité. Un commercial a besoin des coordonnées du client. Un agent de support a besoin de l'historique des dossiers. Un manager a besoin d'une vision plus large. Et un partenaire externe n'a peut-être accès qu'à une petite partie du processus. Ils ne devraient pas tous voir les mêmes informations. Imaginez un enregistrement client avec une note de contact privé, un prix négocié et un ticket de support en cours. Donner un accès total à chaque utilisateur créerait rapidement des risques. Restreindre tout le monde si sévèrement qu'ils ne peuvent plus travailler pose un autre problème.

Dataverse vous offre des contrôles pour gérer cela. Le premier contrôle commence par l'identité. Lorsque vous vous connectez avec votre compte d'entreprise, Microsoft EntraID vous identifie. Considérez EntraID comme la réception à l'entrée de vos bureaux. Vous arrivez à montrer votre badge et le réceptionniste vérifie votre identité avant de vous laisser entrer. Dataverse utilise cette identité pour savoir quel utilisateur manipule les données. Il ne se contente pas de demander si cette personne est autorisée à entrer. Il demande aussi ce que cette personne est autorisée à faire une fois à l'intérieur. C'est là qu'interviennent les rôles de sécurité. Un rôle de sécurité est un ensemble d'autorisations liées à un poste ou à une responsabilité. Vous pouvez créer un rôle pour le personnel commercial, un autre pour le service client et un autre pour les managers. Chaque rôle peut contrôler l'accès à une table.

Par exemple, un commercial peut être autorisé à lire, créer et mettre à jour des comptes, contacts, pistes et opportunités. Il peut ne pas être autorisé à supprimer des informations clients importantes. Un agent de support peut créer et mettre à jour des incidents mais pas modifier une opportunité commerciale. Les autorisations couvrent la lecture, la création, la modification et la suppression de lignes. Cela signifie que l'accès ne dépend pas de quelqu'un qui doit se souvenir des boutons à masquer dans chaque application. Les autorisations sont associées aux données. Ainsi, les mêmes garde-fous s'appliquent partout où ces données dataverses apparaissent. Ensuite, vous pouvez restreindre l'accès encore davantage. La sécurité au niveau des lignes décide quelles lignes individuelles une personne peut manipuler. Un commercial peut ne voir que ses propres clients tandis qu'un manager peut voir les lignes clients de toute son équipe GRI.

Les deux personnes utilisent la même table de compte. Ils ne voient simplement pas la même partie. Cette configuration aide chacun à se concentrer sur son travail tout en donnant au manager la vue dont ils ont besoin. Cela réduit aussi le risque qu'une personne accède à des informations clients sans raison légitime. Certaines informations nécessitent une protection encore plus stricte. La sécurité au niveau des colonnes peut protéger des colonnes individuelles au sein d'une table. Un utilisateur peut ouvrir une ligne client sans voir un identifiant, un salaire, des coordonnées bancaires ou une note financière privée. La ligne client reste disponible pour le travail qu'il doit accomplir. La colonne protégée, elle, reste restreinte. Pour les grandes entreprises, les unités commerciales peuvent créer des frontières entre différentes parties de l'organisation. Une entreprise peut séparer des régions, divisions ou filiales travaillant avec des groupes de clients différents.

Les unités commerciales aident à définir le fonctionnement de l'accès à travers ses frontières. Cela ne signifie pas que chaque entreprise a besoin d'une carte de sécurité complexe. Une petite équipe peut n'avoir besoin que de quelques rôles clairs ? Une grande entreprise peut avoir besoin de plus de niveaux, car ses équipes, ses régions et ses responsabilités diffèrent. L'idée est que Dataverse peut adapter l'accès au fonctionnement réel de l'entreprise. Le contrôle d'accès protège ceux qui peuvent atteindre les données, mais des règles protègent aussi la qualité des données elles-mêmes. Une règle métier peut exiger de saisir un numéro de téléphone avant d'enregistrer un nouveau contact.

La même règle s'applique à toutes les applications qui utilisent cette table. C'est important, car vous ne voulez pas qu'une application accepte des données incomplètes tandis qu'une autre les rejette. La règle est associée aux informations métiers et non un écran particulier qui les affiche. Dataverse peut également exécuter une logique en arrière-plan pour assurer la cohérence des processus métiers. Le détail à retenir est simple. Les données s'accompagnent de règles, pas seulement de stockage. Ainsi, la base inclut les informations, les personnes autorisées à les utiliser et les règles qui les maintiennent exploitables. Dès que Dynamics 365 serait le traditionnel pour accéder à ses propres données métiers. Ce que signifie réellement l'intégration Dynamics 365 ? La plupart des gens entendent intégration Dynamics 365 avec Dataverse Segure et imaginent deux systèmes séparés reliés par un connecteur.

Un système détient les données clients, un autre en a besoin d'une copie alors quelqu'un configure une synchronisation, attend son exécution et espère qu'aucun problème ne survient. Cette image est logique pour de nombreux outils professionnels. Mais voici le point important. Pour Dynamics 365 Sales et Dynamics 365 Customer Service, la connexion est bien plus étroite, ces applications utilisent Dataverse comme fondation de données partagées. Ce ne sont pas des bases de données distinctes qui s'échangent des lignes de clients pour se comprendre. Elles travaillent dès le départ sur les mêmes informations métiers. C'est ça la différence.

Vous êtes un commercial et vous créez une nouvelle entreprise dans Dynamics 365 Sales. Vous ajoutez le contact principal et commencez à travailler sur une affaire potentielle. Ces détails deviennent immédiatement partie intégrante des données partagées utilisées par l'application. Plus tard, ce client contacte le support. L'agent du support peut travailler exactement avec les mêmes détails d'entreprise et de contact. Personne n'a besoin d'exporter une liste depuis les ventes ou de recréer le client dans un outil de support séparé. L'agent lit simplement le dossier de support à ce client et voit l'historique qui lui permet de comprendre la situation. L'équipe commerciale voit l'affaire, le support voit le dossier et les deux équipes travaillent autour du même client. Cela ne signifie pas pour autant que chaque écran est identique ou que chaque équipe suit le même processus. L'équipe commerciale a besoin de pistes, d'opportunités, d'appels et de réunions.

Service client a besoin de dossiers, de files d'attente et d'historiques de services. Chaque application Dynamics 365 fournit aux utilisateurs des outils adaptés à leur métier, tandis que les informations professionnelles sous la centre peuvent se connecter là où c'est nécessaire. Cette base commune est ce à quoi les gens font souvent référence en parlant de l'intégration entre Dynamics 365 et Dataverse. Il ne s'agit pas seulement de déplacer des données d'un point A vers un point B, mais de permettre aux applications d'utiliser les mêmes lignes, relations, règles et contrôles d'accès dès le début. Permettez aux équipes de suivre un parcours de vente simple. Un prospect arrive via un site web ou un événement. Un commercial travaille avec ce prospect, apprend à mieux connaître la personne et transforme ce prospect en relation client et en opportunité. Les appels, email, rendez-vous et tâches peuvent tous être liés à ce travail.

Ainsi, l'équipe n'a pas besoin de chercher dans différents outils pour reconstituer l'histoire. Si le client a besoin d'aide par la suite, un dossier de support peut être rattaché à ce même client. L'agent de support ne voit pas simplement un nom et une adresse email. Il peut travailler dans le contexte de la relation client déjà identifiée. Parallèlement, l'équipe commerciale peut voir que le client a un incident de service ouvert, évitant ainsi d'aborder une discussion de renouvellement sans connaître ses problèmes antérieurs. Une seule relation client peut prendre en charge différents types de travail. C'est bien plus utile que de simplement conserver un nom de client identique dans deux systèmes. Vous pourriez également entendre l'expression « Common Data Model EGUEG », parfois abrégée en CDM. Ne laissez pas ce nom rendre la chose plus mystérieuse qu'elle ne l'est. Cela signifie simplement que Microsoft fournit des modèles de table métier courant pour des éléments que de nombreuses entreprises suivent, tels que les comptes, les contacts, les activités et les dossiers.

Ces modèles offrent aux applications basées sur Dynix 365 et Dataverse un langage commun de départ. Un compte représente une entreprise. Un contact représente une personne. Une activité assure le suivi du travail et a une relation commerciale. Vous pouvez ajuster la configuration pour votre entreprise et ajouter vos propres tables, si nécessaire, sans avoir à repartir d'une page blanche à chaque fois. Lorsqu'une application comprend une table de compte et qu'une autre utilise cette même table, les deux font référence au même type d'informations commerciales ou raciales. Cela change également ce que vous êtes en mesure de construire. Supposons que votre équipe de terrain ait besoin d'une application simple pour rechercher un client, confirmer une visite et ajouter une note après le rendez-vous. Vous pouvez créer une PowerApp qui utilise les mêmes tables Dataverse que celle déjà exploitée par Dynamics 365.

Il n'est pas nécessaire d'exporter les clients dans une nouvelle liste uniquement pour cette application. L'agent de terrain ouvre l'application, trouve le client et met à jour les informations de la visite. Les données restent connectées à la relation client utilisée par les ventes ou le service client conformément aux règles de sécurité vues précédemment. Pour des tâches métiers plus structurés, vous pouvez créer une application pilotée par modèle. Une application pilotée par modèle sur un modèle de données. Vous choisissez les tables Dataverse, définissez leurs relations, configurez les formulaires et vues, puis appliquez des rôles de sécurité. PowerApps utilise ensuite cette structure pour générer une application métier fonctionnelle. Imaginez cela comme l'organisation d'un établi avec les outils et matériaux réellement utilisés par votre équipe. Les tables décrivent le travail. Les relations connectent les différents éléments.

Les formulaires permettent de saisir et de consulter les détails. Les vues aident à trouver les lignes nécessitant une attention particulière. La sécurité détermine ce que chaque personne peut ouvrir ou modifier. Une application pilotée par modèle peut coexister avec Dynamics 365 car toutes deux utilisent Dataverse. Par exemple, Dynamics 365 Sales gère le processus de vente complet tandis qu'une application dédiée offre au gestionnaire de contrat un espace ciblé pour suivre les accords clients. Les deux peuvent exploiter les données clients associées sans créer une seconde base de données. Bien entendu, cet accès doit être géré avec son. Le fait qu'une application puisse utiliser une table Dataverse ne signifie pas que chaque utilisateur doit pouvoir modifier chaque ligne voire chaque colonne. L'accès par rôle et les règles métier contrôlent toujours les actions autorisées. Une application métier peut fournir exactement les détails et actions nécessaires sans exposer le reste des données de l'entreprise.

Ainsi, l'intégration de Dynamics 365 avec Dataverse agit comme un câble reliant deux pièces éloignées. Les applications Dynamics 365 et les processus métiers peuvent tous appuyer sur une même base partagée. Une fois ce constat établi, la question suivante devient évidente. Quoi d'autre peut utiliser cette même mise à jour cliente sur la plateforme connectée de Microsoft comment la plateforme connectée fonctionne-t-elle concrètement ? Une mise à jour qui est en partagée devient utile lorsque les outils qui l'entourent peuvent réagir. Power Automate gère le suivi en surveillant les changements dans une ligne Dataverse et en déclenchant une action lorsque ce changement survient. Par exemple, un nouveau prospect arrive dans Dynamics 365 Sales. Un flux peut notifier le commercial attitré, publier un message dans Teams ou créer une tâche de suivi. Personne n'a besoin de surveiller une boîte de réception partagée toute la journée.

Le prospect change et l'étape suivante se lance automatiquement. Power Automate n'a pas besoin d'une copie séparée du prospect pour effectuer ce travail pour effectuer ce travail. Il peut réagir à la ligne dans Dataverse en utilisant les mêmes détails de clients et propriétés que l'application de vente ce qui maintient l'automatisation au plus près du processus métier au lieu de compter sur quelqu'un pour exporter un fichier et lancer une chaîne d'email manuelle. Ensuite, il y a Power BI. Un responsable commercial peut vouloir visualiser le pipeline actuel. Un responsable du service client peut avoir besoin de voir combien de dossiers sont arrivés cette semaine, lesquels restent ouverts ou quels clients contactent le support le plus souvent. Ou moins. Power BI peut établir des rapports sur les données métiers de Dataverse afin que ses équipes puissent suivre le travail en cours sans avoir à créer de nouvelles feuilles de calcul chaque vendredi après-midi.

Le rapport s'appuie sur les données métiers que les collaborateurs utilisent déjà. Cela signifie qu'un graphique de pipeline peut évoluer à mesure que les opportunités progrivent. Un tableau de bord des dossiers peut afficher la charge de travail actuelle à mesure que les agents mettent à jour les tickets. L'idée n'est pas qu'un tableau de bord

nécessite une attention particulière. Power Apps ajoute une autre voie au sein du même processus. Imaginez un technicien de terrain arrivant sur le site d'un client. Il n'a pas besoin de l'expérience complète de DLMX 365 Sales. Il peut simplement avoir besoin de trouver le client, de consulter les détails de la visite, de confirmer ce qui s'est passé et d'ajouter une note ou une photo. Une application Power Apps ciblée peut leur offrir cette expérience simplifiée. Une équipe de compte pourrait avoir besoin d'une application pour examiner les accords clients. Un manager pourrait avoir besoin d'une application simple pour approuver une demande. Chaque application peut se concentrer sur une tâche spécifique tout en travaillant avec les mêmes données contrôlées de Dataverse en arrière-plan. Chaque personne utilise l'outil adapté à sa journée. L'entreprise conserve les informations connectées.

Parfois, ces informations proviennent de l'extérieur de Dataverse. Une entreprise peut disposer d'une liste provenant d'une source en ligne qui doit être intégrée à ces données métiers. Power Query peut importer des données à partir de sources en ligne prises en charge, les nettoyer lors de l'importation et les charger dans la table Dataverse appropriée. C'est utile lorsqu'une source externe contient des informations dont vos outils Dynamics et Power Platform ont besoin. Vous devez toujours décider ce qui appartient à Dataverse et comment cela doit se connecter aux tables existantes. Importer des données sans cette réflexion déplace simplement la confusion vers un nouvel emplacement. Assemblons ces éléments dans un flux de travail quotidien. Un nouveau prospect est saisi dans Dynamics 360. Une règle d'attribution vérifie qu'il doit être responsable de ce prospect peut être en fonction de la région et du produit.

Le responsable reçoit un message Teams via un flux Power Automate pour savoir qu'il a du travail en attente. A mesure que le commercial met à jour le prospect et le fait avancer dans le processus de vente, le tableau de bord Power BI se met à jour pour montrer à l'équipe le pipeline actuel. Une seule mise à jour déclenche un travail utile à plusieurs endroits. Power Automate fait passer le travail d'une étape à la suivante. Power BI aide les collaborateurs à visuer le travail. Power Apps offre aux équipes spécifiques un moyen ciblé de participer. Dataverse maintient les informations métiers organisés et sécurisés pendant que ces outils effectuent leurs tâches. La différence est importante. L'automatisation n'est pas le système de classement et un tableau de bord n'est pas la base de données client. Chaque outil a une fonction propre mais ils peuvent tous exploiter la même source. Le savoir aide à choisir le bon outil plutôt que de vouloir gérer tout un processus métier via une simple liste ou feuille de calcul quand Dataverse est approprié et ce qu'il ne remplace pas.

Voici le point clé. Optez pour Dataverse lorsque plusieurs personnes et applications doivent utiliser des données métiers connectés. Vous avez besoin de règles d'accès claires et de processus reproductibles. Dataverse en charge mais ne remplace pas tout le reste. Excel reste votre allié pour l'analyse personnelle et les listes rapides. Les listes SharePoint sont efficaces pour un suivi d'équipes simples. Si vous êtes un développeur en quête d'un contrôle poussé, SQL demeure un choix robuste. Alors quand Dataverse est-il vraiment pertinent ? Lorsque vos données doivent être reliées entre Dynamics 365, vos applications, automatisation et rapport sans en créer de copie, c'est là qu'il excelle. En conclusion, une base unique de multiples outils métiers. Voici ce qu'il faut retenir. Dynamics 365 et Dataverse sont optimaux quand vos données, règles, sécurité, apps, automatisation et rapport partagent un socle commun.

Abonnez-vous à Microsoft Knowledge Nuggets sur M365FM pour plus de guides simples sur Dynamics 365, Power Platform et Microsoft 365. Regardez ensuite notre épisode sur les applications pilotées par modèle pour voir comment l'étape Dataverse devient une application métier fonctionnelle. d'avoir regardé cette vidéo ! Sous-titrage Société Radio-Canada