Bienvenue à l'épipide de Savoir Microsoft, je suis Mirko Peters. Le sujet d'aujourd'hui est souvent source de confusion. Qu'est-ce que Dataverse exactement ? Est-ce une base de données, une application ou un service Dynamics 365 caché réservé aux informaticiens à HANU ? Voici la définition la plus simple. Dataverse est le socle de données partagées derrière de nombreuses expériences Dynamics 365. Imaginez Dynamics 365 comme un immeuble de bureau. Les ventes, le service client et les autres applications sont les bureaux 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 se refléter dans le travail commercial, l'automatisation et le reporting. Mais avant d'aborder les noms de produits, commençons par le désordre métier que cela résout.

Un lieu unique et partagé, au lieu de copies séparées. Imaginez une entreprise avec une équipe de vente, une équipe de support et une équipe financière. Les ventes gardent les détails des clients dans un tableau. Le support travaille dans un outil de gestion des tickets séparés. La finance a les noms des clients dans son propre système. Quelqu'un d'autre enregistre d'email dans une boîte aux lettres partagées, tandis qu'une autre personne garde des notes dans un dossier que personne d'autre dans un dossier que personne d'autre ne peut. Le même client existe désormais à 5 endroits différents. Cette configuration semble normale au début, car chaque équipe ne voit que la partie du travail 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 difficultés commencent. Les ventes mettent à jour le tableur, le support ne le voit pas, et la finance envoie toujours les documents à l'ancienne adresse, à l'adresse.

Ensuite, quelqu'un exporte une liste, la nettoie manuellement, l'envoie par email, et soudain, 3 personnes pensent chacune que leur copie est la bonne. A quelle liste devez-vous fière ? Cette question fait perdre plus de temps que vous ne pourriez le penser. Le personnel s'arrête pour comparer les enregistres. 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 un désordre. Le désordre provient de la multiplication des coûts. Il y a 20 ans, des systèmes séparés signifiaient des serveurs séparés, des bases de données séparées et des équipes distinctes gardant leurs propres informations. Les connectés nécessitaient un travail personnalisé, des importations planifiées et beaucoup de vérifications manuelles. Un changement effectué à 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. En termes simples, Dataverse est la plateforme de données cloud de Microsoft pour les informations métiers. Elle stocke ces informations dans des tables structurées afin que les données aient une forme claire au lieu d'exister sous forme de notes éparses, de fichiers isolés et d'onglets de tableurs déconnectés. Voyez cela comme le classeur de l'entreprise, mais un classeur que plusieurs outils approuvés peuvent utiliser simultanément. Un client n'apparaît qu'une seule fois dans Dataverse. Ce client peut apparaître dans Dynamics 365 Sales lorsqu'un commercial travaille sur une affaire. Les mêmes coordonnées clients peuvent s'afficher dans Dynamics 365 Customer Service lorsqu'un agent traite une demande d'assistance. Une Power App peut utiliser ces mêmes informations clients pour un technicien sur le terrain ou un gestionnaire de compte sans que personne n'ait à copier les données dans une nouvelle application préalable.

Une ligne client, un point de référence unique 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 données métiers au lieu de créer leur propre version divergente. C'est pourquoi Dynamics 365 et Dataverse s'associent si naturellement. Les applications Dynamics 365 comme Sales et Customer Service utilisent Dataverse pour stocker et sécuriser les données qu'elles exploitent. Mais 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 beaucoup d'applications Dynamics 365, ce n'est pas vrai. 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 les mêmes fondations en utilisant les mêmes informations métiers que celles déjà exploitées par Dynamics 365. Cela change la nature de la discussion. Au lieu de demander comment synchroniser ces deux listes de clients, vous pouvez demander quelles personnes et quelles applications doivent travailler avec ce dossier client et quelles actions doivent-elles être autorisées à effectuer. Bien sûr, Dataverse ne remplace pas tous les systèmes d'une entreprise. Une entreprise peut toujours utiliser des logiciels financiers, des outils métiers, des systèmes de gestion 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 qui vous offre, c'est un espace commun pour les données métiers que les applications connectées doivent partager, coordonnées clients, activités commerciales, supports, tâches et suivis.

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 verrez comment Dataverse organise les informations, la connexion avec Dynamics 365 deviendra beaucoup plus facile à comprendre. Le classeur, les tables, les lignes, les colonnes et les relations. Ouvrons ce classeur. Dans Dataverse, les informations sont organisées dans des tables. Imaginez cela comme un vrai classeur avec des tiroirs séparés. Un tiroir contient les entreprises, un autre les personnes et un troisième les demandes d'assistance. Vous ne jetez pas tous les papiers dans un seul grand tiroir en espérant que quelqu'un les triera plus tard. Chaque tiroir a sa fonction. Ainsi, dans Dataverse, une table contient un type d'informations commerciales. Une table de comptes contient généralement les entreprises avec lesquelles vous travaillez.

Une table de contact contient des personnes physiques. Une table de pistes contient des clients potentiels avant qu'ils ne deviennent des clients réels. Une table de requêtes contient les demandes de support, tandis qu'une table d'activités permet de suivre 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 collaborateurs, leur travail et leurs échanges. Il n'est pas nécessaire de commencer par créer une nouvelle table pour un usage courant si une table standard convient déjà. Cependant, chaque entreprise a aussi ses propres soucis. Un organisme de formation pourrait avoir besoin de suivre des cours et des certifiques. Une société immobilière peut avoir besoin de gérer des bâtiments, des unités et des inspections. Fabricant pourrait suivre des contrôles d'équipement, 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érez une table personnalisée comme l'ajout d'un nouveau tiroir au meuble, avec une étiquette claire. Chaque table contient ensuite 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, e-mail, téléphone, poste, entreprise, propriétaire de l'enregistrement et statut. Une colonne définit le type d'information attendue. Ainsi, une colonne e-mail attend une adresse e-mail et une colonne statut peut contenir des choix de statut approuvés.

C'est ainsi que l'information commerciale prend une forme fiable. Sans colonne, une personne pourrait saisir un numéro de téléphone dans une zone de notes, une autre dans un champ de nom et une autre pourrait ne pas l'entrer du tout. Avec une table de contact claire, tout le monde travaille avec les mêmes détails au même endroit. Cette structure aide aussi les applications à comprendre les données. Un formulaire peut afficher les bonnes cases, un rapport peut grouper les contacts par statut et une automatisation peut réagir quand un propriétaire change. L'information n'est pas seulement stockée, elle est étiquetée pour indiquer aux outils connectés ce que chaque élément signifie. Commencez par les tables standard dès qu'elles correspondent à vos besoins professionnels. Si vous vendez à des entreprises, les comptes et contacts décrivent déjà un modèle que la plupart des gens comprennent. Si vous gérez le support client, les requêtes vous offrent un point de départ.

Ensuite, n'ajoutez des tables personnalisées que si votre entreprise possède des informations qui ne correspondent pas au modèle intégré. Cela permet d'éviter un problème courant. Créer cinq tables différentes qui signifient toutes client et Q. Une équipe l'appelle client, une autre client principal et une troisième contact partenaire, IOWQ. 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 l'armoire compréhensible à mesure qu'elles s'étoffent. La suite concerne la manière dont ces tiroirs commencent à fonctionner ensemble. Un contact appartient à un compte. Maria travaille pour Contoso LTD. Au lieu de retaper l'adresse, le numéro de téléphone et les détails de l'entreprise dans la ligne de Maria, Dataverse peut créer une relation entre la table contact et la table compte. Maria est liée à Contoso, et ce lien est important car les informations de l'entreprise restent avec l'entreprise.

Si Contoso change d'adresse, il suffit de mettre à jour la ligne du compte une seule fois, et chaque contact associé pointera vers la même entreprise sans avoir à conserver sa propre copie obsolète. Les relations permettent également de lier un ticket de support au client qu'il a créé. Elles peuvent lier une opportunité commerciale aux appels, e-mails, réunions et tâches relatives à cette affaire. Lorsqu'un commercial ouvre une opportunité, il peut voir les activités liées plutôt que de chercher dans des notes et des calendriers sans rapport. Les informations ont un contexte. Vous ne regardez pas seulement un numéro de ticket, vous voyez à quel client il appartient ou l'appartient. Vous ne voyez pas seulement un contact, 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 la terminologie avant de consulter d'anciens guides ou vidéos. Vous entendrez peut-être les termes entités, champs et enregistrements. Il s'agit d'anciens termes Dataverse. Microsoft utilise désormais table d'entités, colonnes au lieu de champs, et lignes au lieu d'enregistrement. Le sens n'a pas changé. Un ancien guide qui vous demande de créer une entité parle en réalité de créer une table, un champ est une colonne, et un enregistrement est une ligne. Connaître et ces deux ensembles de termes vous évitera de croire que vous utilisez un produit différent. Donc les tables organisent les informations et les relations les connectent. Mais une armoire bien organisée 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é. Les règles et le guichet d'accueil Dans Dataverse, les données ne sont utiles que si les bonnes personnes peuvent y accéder en toute sécurité.

Un commercial a besoin des détails clients, un agent de support a besoin de l'historique des tickets, un manager a besoin d'une vue d'ensemble, et un partenaire externe n'a peut-être accès qu'à une petite partie du processus. Ils ne doivent pas tous voir les mêmes informations. Pensez à un enregistrement client contenant une note de contact privé, un prix négocié et un ticket de support ouvert. Donnez un accès complet à chaque utilisateur créerait rapidement des risques. Restreindre tout le monde si sévèrement qu'ils ne peuvent plus travailler crée un autre problème. Dataverse vous fournit des contrôles pour cela. Et 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 l'accueil à l'entrée de vos bureaux. Vous arrivez, présentez votre badge et l'agent d'accueil vérifie votre identité avant de vous laisser entrer.

Dataverse utilise cette identité pour savoir quel utilisateur travaille avec les données. Cela ne s'arrête pas à la question. Cette personne est-elle autorisée à entrer ? Cela pose aussi la question « Que peut faire cette personne une fois entrée ? » 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 les commerciaux, un autre pour les agents du 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 peuvent couvrir la lecture, la création, la modification et la suppression de l'aide.

Cela signifie que l'accès ne dépend pas de la mémoire de quelqu'un pour masquer des boutons dans chaque application. Les autorisations sont liées aux données elles-mêmes. Ainsi, les mêmes garde-fous s'appliquent partout où apparaissent ces données dataverse. Ensuite, vous pouvez restreindre l'accès encore davantage. La sécurité au niveau des lignes décide avec quelles lignes individuelles une personne peut travailler. Un commercial peut ne voir que les clients qu'il possède, tandis qu'un manager peut voir les lignes clients possédés par toute son équipe. Les deux personnes utilisent la même table de compte. Elles ne voient simplement pas la même partie de celle-ci. 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 sur un client sans raison valable. Certaines informations nécessitent une protection encore plus stricte.

La sécurité au niveau des colonnes peut protéger des colonnes individuelles dans une table. Peut-être qu'un utilisateur peut ouvrir une ligne client, mais ne devrait pas voir un identifiant personnel, un salaire, des détails bancaires ou une note financière privée. La ligne client reste disponible pour le travail qu'ils doivent effectuer. La colonne protégée, elle, reste restreinte. Pour les plus 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, des divisions ou des filiales qui travaillent avec des groupes de clients différents. Les unités commerciales aident à définir comment fonctionne 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 n'a besoin que de quelques rôles clairs ? Une grande entreprise peut nécessiter plus de niveaux, car ses équipes, ses régions et ses responsabilités diffèrent.

L'essentiel est que Dataverse puisse 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 la saisie d'un numéro de téléphone avant d'enregistrer un nouveau contact. Elle peut vérifier une condition, comme exiger un motif lors de la clôture d'un ticket. Elle peut également modifier ce que les utilisateurs voient en fonction des informations saisies. La même règle s'applique à toutes les applications utilisant 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 appartient aux informations métiers, pas à un écran qui se trouve les affichés. 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 comprend les informations, les personnes autorisées à les utiliser, les règles qui les maintiennent exploitables. Une fois que Dynamics 365 fonctionne sur cette même base, il n'a pas besoin de passerelles traditionnelles pour accéder à ses propres données métiers. Ce que signifie réellement ? Intégration Dynamics 365 à garer, la plupart des gens entendent intégration Dynamics 365 avec Dataverse Girl et imaginent deux systèmes distincts 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 qu'elle s'exécute et espère qu'aucun échec ne surviendra. Cette image a du sens pour de nombreux outils professionnels. Mais ici, pour Dynamics 365 Sales et Dynamics 365 Customer Service, la connexion est beaucoup plus étroite.

Ces applications utilisent Dataverse comme fondation de données partagée. Ce ne sont pas deux bases de données distinctes qui s'échangent des lignes de clients pour se comprendre. Elles travaillent dès le départ à partir des mêmes informations métiers. Soyons concrets. Imaginez que vous êtes un commercial et que vous créez une nouvelle société 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 avec exactement la même société et les mêmes coordonnées. 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 ticket de support à ce client et voit l'historique qui l'aide à comprendre la situation.

Les ventes voient l'affaire, le support voient le ticket 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. Les ventes ont besoin de pistes, d'opportunités, d'appels et de réunions. Le service client a besoin de tickets, de files d'attente et de l'historique de service. Chaque application de Dynamics 365 offre des outils conçus pour le métier de chacun. Bien que les informations métiers sous-jacents puissent se connecter partout, cette base commune est ce à quoi les gens font souvent référence en parlant d'intégration entre Dynamics 365 et Dataverse. Il ne s'agit pas principalement de déplacer des données d'un point A à un point B. Tout repose sur des applications utilisant les mêmes lignes, relations, règles et contrôles d'accès dès le départ. Parcourons ensemble un parcours de vente simple.

Une piste arrive via un site web ou un événement. Un commercial travaille avec cette piste, en apprend plus sur la personne et transforme la piste en relation client et en opportunité. Les appels, emails, rendez-vous et tâches peuvent tous être liés à ce travail. Ainsi, l'équipe n'a pas besoin de chercher dans des outils distincts pour reconstituer l'historique. Si le client a besoin d'aide plus tard, un ticket de support peut être attaché à ce même client. L'agent du support ne voit pas seulement 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 problème de service en cours et éviter d'aborder un renouvellement sans savoir qu'il y a un souci. Une relation client unique peut supporter différents types de travail, ce qui est bien plus utile que de simplement faire correspondre un autre client dans deux systèmes.

Vous pourriez également entendre l'expression « common data model » parfois abrégée en CDM. Ne laissez pas ce nom paraître plus mystérieux qu'il ne l'est. Cela signifie simplement que Microsoft fournit des modèles de table métier commun pour les éléments que beaucoup d'entreprises suivent, comme les comptes, les contacts, les activités et les tickets. Ces modèles donnent aux applications Dynamics 365 et basées sur Dataverse, un langage de départ commun. Un compte désigne d'entreprise. Un contact désigne personne. Une activité suit le travail lié à une relation commerciale. Vous pouvez ajuster la configuration pour votre entreprise et ajouter vos propres tables si besoin. Mais vous ne repartez pas 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 applications font référence au même type d'informations métier-métier.

Cela change aussi ce que vous pouvez construire. Supposons que votre équipe de terrain ait besoin d'une application simple pour rechercher un client, confirmez une visite et ajoutez une note après le rendez-vous. Vous pouvez créer une Power App qui travaille avec les mêmes tables Dataverse déjà utilisées par Dynamics 365. Il n'est pas nécessaire d'exporter les clients dans une nouvelle liste juste pour cette application. L'employé sur le terrain ouvre l'application, trouve le client et met à jour les informations de visite. Les données restent connectées à la relation client déjà utilisée par les ventes ou le service client conformément aux règles de sécurité abordées précédemment. Pour un travail métier plus structuré, vous pouvez créer une application pilotée par mode. Une application pilotée par modèle commence par un modèle de données. Vous choisissez l'étape Dataverse, définissez leurs relations, configurez des formulaires et des vues, puis appliquez des rôles de sécurité.

Power Apps utilise ensuite cette structure pour créer une expérience d'application métier fonctionnelle. Considérez cela comme l'organisation d'un établi autour des outils et matériaux que votre équipe utilise réellement. Les tables décrivent le travail, les relations connectent les éléments entre. Les formulaires permettent aux utilisateurs de saisir et de consulter des détails. Les vues les aident à trouver les lignes qui nécessitent une attention particulière. La sécurité décide ce que chaque personne peut ouvrir ou modifier. Une application pilotée par modèle peut fonctionner aux côtés de Dynamics 365 car les deux utilisent Dataverse. Peut-être que Dynamics 365 Sales gère le processus de vente complet, tandis qu'une application pilotée par modèle plus restreinte offre au gestionnaire de compte à un espace dédié pour suivre les accords clients. Les deux peuvent exploiter les mêmes données clients sans créer une seconde base de données.

Bien entendu, cet accès nécessite toujours de la vigile. Ce n'est pas parce qu'une application peut interagir avec une table Dataverse que chaque utilisateur doit pouvoir modifier chaque ligne ou voire chaque colonne. Les rôles, l'accès aux lignes et les règles métiers contrôlent toujours les actions autorisées. Une application de terrain peut fournir à un utilisateur exactement les détails clients et les actions dont il a besoin, sans exposer le reste de l'entreprise ou les données sensibles. Ainsi, l'intégration de Dynamics 365 avec Dataverse n'est plus un simple câble reliant deux pièces distantes. Les applications Dynamics 365, les applications personnalisées et les processus métiers peuvent tous reposer sur la même fondation partagée. Une fois que vous avez compris cela, la question suivante devient évidente. Que pouvez-vous faire d'autre avec cette même mise à jour client sur l'ensemble de la plateforme connectée de Microsoft ?

Comment la plateforme connectée fonctionne en situation réelle ? Une mise à jour client partagée devient utile lorsque les outils qui l'entourent peuvent réagir. Power Automate gère le travail de suivi en surveillant tout changement dans une ligne Dataverse et en déclenchant une action dès que ce changement survient. Par exemple, un nouveau prospect est saisi dans Dynamics 365 Sales. Un flux peut avertir le vendeur à signer, 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 démarre automatiquement. Power Automate n'a pas besoin d'une copie séparée du prospect juste pour effectuer ce travail. Il peut réagir à la ligne dans Dataverse en utilisant les mêmes détails de client et de propriété que ceux utilisés par l'application de vente. Cela maintient l'automatisation au plus près du processus métier au lieu de dépendre de quelqu'un qui doit exporter un fichier et lancer une chaîne d'email manuelle.

Ensuite, il y a Power BI. Directeur commercial peut vouloir visualiser le pipeline actuel. Un responsable du service client peut avoir besoin de voir le nombre de dossiers reçus cette semaine, ceux qui restent ouverts ou quels clients contactent le support le plus souvent. Power BI peut générer des rapports sur les données métiers de Dataverse permettant à ses équipes de suivre l'activité sans avoir à créer de nouveaux fichiers Excel chaque vendredi après-midi, chaque vendredi après-midi. Le rapport s'appuie

d'opportunités progrès. Un tableau de bord des dossiers peut afficher la charge de travail en temps réel à mesure que les agents mettent à jour l'étiquette. L'idée est désormais qu'un tableau de bord remplace la vérification manuelle des détails par les personnes. Il leur offre une vision plus claire du travail avant qu'ils ne décident ce qui nécessite leur attention. Power Apps ajoute une nouvelle voie d'accès au même processus. Imaginez un technicien de terrain arrivant sur le site d'un client. Il n'a pas besoin de toute l'interface de Dynamics 365 Sales. Il a peut-être seulement besoin de trouver le client, consulter les détails de la visite, confirmer ce qui s'est passé et ajouter une note ou une photo, une photo. Une Power App ciblée peut lui offrir cette expérience simplifiée. Une équipe commerciale pourrait avoir besoin d'une application pour réviser les accords clients. Un manager pourrait avoir besoin d'une application simple pour approuver.

Chaque application se concentre sur une tâche tout en exploitant les mêmes données contrôlées dans Dataverse en arrière-plan. Chaque personne utilise l'outil adapté à sa journée. L'entreprise conserve des informations connectées. Parfois, ces informations proviennent de l'extérieur de Dataverse. Une entreprise peut disposer d'une liste issue d'une source en ligne qui doit être intégrée à ces données métiers. Power Query peut importer des données depuis des sources en ligne prises en charge, les nettoyer durant l'importation et les charger dans la table Dataverse appropriée. C'est utile lorsqu'une source externe contient des informations que vos outils Dynamics et Power Platform doivent utiliser. Vous devez toujours décider ce qui a sa place dans Dataverse et comment cela doit se connecter aux tables existantes. Importer des données sans réflexion déplace simplement la confusion vers un nouvel emplacement.

Laissons au tome assembler les pièces dans un flux de travail quotidien. Un nouveau prospect est saisi dans Dynamics 365 et une règle d'attribution détermine qu'il doit en être responsable, peut-être en fonction de la région ou du produit. Le responsable reçoit un message Teams via un flux Power Automate l'informant qu'un travail est en attente. À mesure que le commercial met à jour le prospect et le fait avancer dans le processus de vente, le tableau de bord Power BI change pour montrer à l'équipe le pipeline actuel de l'équipe automne. 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écialisées à un moyen cible et d'y participer. Dataverse maintient les informations métiers organisées et sécurisées pendant que ces outils remplissent leurs fonctions.

Cette différence est importante. L'automatisation n'est pas un système de classement et un tableau de bord n'est pas une base de données client. Chaque outil a une fonction distincte mais ils peuvent tous fonctionner à partir du même source. Le savoir aide à choisir le bon outil au lieu de traiter chaque feuille de calcul ou liste simple comme si elle devait gérer un processus métier complet. Complet.

Quand Dataverse est approprié, est-ce qu'il ne remplace pas ? Voici le point essentiel. Choisissez Dataverse lorsque plusieurs personnes et applications doivent travailler avec des données métiers connectés. Vous avez besoin de règles d'accès claires et de processus répétés. Dataverse gère cela mais il ne remplace pas tout le reste. Excel reste votre outil de référence pour la liste personnelle et liste rapide. Les listes SharePoint fonctionnent bien pour le suivi simple au sein d'une équipe. Si vous êtes un développeur nécessitant un contrôle approfondi, SQL reste un choix solide. Alors quand Dataverse est-il vraiment adapté ? Lorsque vos données doivent être connectées aux applications Dynamics 365, à l'automatisation et aux rapports sans créer de copies supplémentaires, sans créer de copies supplémentaires. C'est là qu'ils brillent. Mais en conclusion, une base commune de nombreux outils métiers.

Voici donc l'essentiel à retenir. Dynamics 365 et Dataverse fonctionnent mieux lorsque toutes vos données, règles, sécurité, applications, automatisation et rapports partagent une fondation commune. Abonnez-vous à Microsoft Knowledge Nuggets sur n365.fm 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 fonctionnel.