Welkom bij Microsoft Knowledge Nuggets. Ik ben Mirko Peters. Het onderwerp van vandaag zorgt vaak voor verwarring. Wat is dataverse precies? Is het een database, een app of een verborgen Dynamics 365 dienst die alleen IT-ers begrijpen? Hier is de simpelste definitie. Dataverse is de gedeelde datafundering achter veel Dynamics 365 ervaringen. Zie Dynamics 365 als een kantoorgebouw. Sales, klantenservice en andere apps zijn de kamers waar mensen werken, terwijl dataverse het archiefsysteem en de regels achter de muren vormt. Aan het eind van deze aflevering weet je waar Dynamics data woont en hoe één klantupdate kan verschijnen in verkoopwerk, automatisering en rapportage. Maar voordat we in productnamen duiken, beginnen we met de zakelijke chaos die dit oplost. Eén gedeelde plek. In plaats van losse kopieën, stel je een bedrijf voor met een verkoopteam, een supportteam en een financieel team.

Sales houdt klantgegevens bij in een spreadsheet. Support werkt in een aparte case tool. Finance heeft klantnamen in hun eigen systeem. Iemand anders slaat email threads op in een gedeelde mailbox, terwijl een ander noties is bewaard in een map die niemand anders kan vinden. Dezelfde klant bestaat nu op vijf plekken. Die opzet voelt in eerste instantie normaal, omdat elk team alleen een eigen deel van het werk ziet. Maar het punt is, zodra een klant hun telefoonnummer, adres, bedrijfsnaam of hoofdcontactpersoon wijzigt, beginnen de problemen. Sales werkt het spreadsheet bij, support ziet het niet, Finance stuurt documenten nog naar het oude adres. Dan exporteert iemand een lijst, maakt deze handmatig schoon, e-mailt hem rond en plotseling geloven drie mensen dat hun kopie de juiste is. Welke lijst moet je vertrouwen? Die vraag kost meer tijd dan je zou denken. Medewerkers stoppen om records te vergelijken.

Managers vragen waarom een rapport niet overeenkomt met het verkoopsysteem. Een supportmedewerker opent een case voor een klant waarvan de gegevens al ergens anders staan, net even anders. Niemand probeert er een puinhoop van te maken. De chaos komt voort uit kopieën. Twintig jaar geleden betekenden aparte systemen aparte servers, aparte databases en aparte teams die hun eigen informatie bewaarden. Ze koppelen kostenmaatwerk, geplande imports en veel handmatige controles. Een wijziging op de ene plek bereikt een ander systeem misschien morgen, volgende week of nooit. Dataverse geeft zakelijke apps een gedeelde plek voor dit soort informatie. In gewone mensentaal, Dataverse is Microsoft's cloud data platform voor bedrijfsinformatie. Het slaat die informatie op in gestructureerde tabellen, zodat de data een duidelijke vorm heeft in plaats van als willekeurige noticies, losse bestanden en losgekoppelde spreadsheet tabbladen te bestaan.

Je kunt het zien als het archief van het bedrijf, waar meerdere goedgekeurde tools tegelijkertijd gebruik van kunnen maken. Een klant staat maar één keer in dataverse. Die klant kan opduiken in Dynamics 365 Sales wanneer een verkoper aan een deal werkt. Dezelfde klantgegevens kunnen verschijnen in Dynamics 365 Customer Service wanneer een medewerker een ondersteuningsverzoek afhandelt. Een power-app kan dezelfde klantinformatie gebruiken voor een buitendienstmedewerker of accountmanager zonder dat iemand de gegevens eerst naar een nieuwe app hoeft te kopiëren. Eén klanttrei, één gedeeld referentiepunt. Dit betekent niet dat elk team plotseling alles ziet. Toegang vereist nog steeds regels, en daar komen we zo op terug. Het betekent dat goedgekeurde apps met dezelfde bedrijfsinformatie kunnen werken in plaats van hun eigen concurrerende versie daarvan te bouwen. Dit is waarom Dynamics 365 en Dataverse zo natuurlijk op elkaar aansluiten.

Dynamics 365 apps zoals Sales en Customer Service gebruiken Dataverse om de gegevens waarmee ze werken op te slaan en te beveiligen. Maar hier is het punt, wanneer iemand spreekt over het integreren van Dynamics 365 met Dataverse, denken ze vaak aan twee aparte producten die een connector nodig hebben. Voor veel Dynamics 365 apps is dat niet het geval. De gegevens staan al in Dataverse. Je haalt geen klantenlijst uit Dynamics 365 om deze naar een andere database te kopiëren, in de hoop dat beide kanten up-to-date blijven. Je kunt voortbouwen op hetzelfde fundament en dezelfde bedrijfsinformatie gebruiken die Dynamics 365 al hanteert. Dat verandert het gesprek. In plaats van de vraag, hoe synchroniseren we deze twee klantenlijsten, kun je vragen welke mensen en apps moeten met dit klantrecord werken en wat mag elk daarvan doen. Dataverse vervangt natuurlijk niet elk systeem dat een bedrijf bezit.

Een bedrijf kan nog steeds financiële software, sectorspecifieke tools, magazijnsystemen, websites of oudere applicaties met eigen data gebruiken. Dataverse is geen tovermiddel dat elk extern systeem van de ene op de andere dag verwijderd. Wat het je biedt, is een centrale plek voor de bedrijfsgegevens die verbonden apps moeten delen. Klantgegevens, verkoopactiviteiten, ondersteuningstaken, opdrachten en opvolging. Die records kunnen samen bestaan in één bron die goedgekeurde tools kunnen lezen en bijwerken. Dus, open dat archief samen met mij. Zodra je ziet hoe Dataverse de informatie daarbinnen organiseert, wordt de volledige Dynamics 365 connectie veel gemakkelijker te begrijpen. Het archief, tabellen, rijen, kolommen en relaties. Laten we dat archief openen. Binnen Dataverse staat informatie in tabellen. Zie het als een echte archiefkast met aparte lades. O, de ene lade bevat bedrijven, een andere mensen en een derde ondersteuningsverzoeken.

Je gooit niet alle papieren in één enorme lade in de hoop dat iemand het later kan uitzoeken. Elke lade heeft een eigen functie. In Dataverse bevat een tabel dus één type bedrijfsinformatie. Een account-tabel bevat meestal bedrijven waar u mee werkt. Een contactpersoon-tabel bevat individuele personen. Een lead-tabel bevat potentiële klanten voordat ze echte klanten worden. Een casus-tabel bevat ondersteuningsverzoeken, terwijl een activiteiten-tabel werkt zoals telefoontjes, e-mails, afspraken en taken bijhoudt. Dat zijn standaardtabellen. Microsoft levert deze omdat de meeste bedrijven klanten, personen, werk en gesprekken moeten bijhouden. U hoeft niet direct een nieuwe tabel uit te vinden voor iets algemeens als een standaardtabel al voldoet. Maar elk bedrijf heeft ook zijn eigen specifieke werkzaamheden. Een opleidingsinstituut moet wellicht cursussen en certificaten bijhouden. Een vastgoedbedrijf heeft mogelijk gebouwen, eenheden en inspecties nodig.

Een fabrikant kan apparatuurcontroles of servicebezoeken bijhouden. In die gevallen kunt u aangepaste tabellen maken die aansluiten bij het werk dat uw bedrijf echt doet. Zie een aangepaste tabel als het toevoegen van een nieuwe lade aan de kast met een duidelijk label. Elke tabel bevat nu rijen. Een rij is één item in die lade. Een rij in de contactpersoon-tabel zou bijvoorbeeld Maria Gomez kunnen zijn, iemand bij een klantbedrijf. Haar rij bevat haar eigen gegevens, gescheiden van elke andere contactpersoon in het systeem. Kolommen beschrijven de details die u per rij wilt bewaren. De contactrij van Maria kan kolommen hebben voor haar voornaam, achternaam, e-mailadres, telefoonnummer, functietitel, bedrijf, recordeigenaar en status. Een kolom bepaalt welk type informatie op die plek hoort, dus een e-mailkolom verwacht een e-mailadres en een statuskolom kan goedgekeurde statuskeuzes bevatten.

Zo krijgt bedrijfsinformatie een betrouwbare vorm. Zonder kolommen typt de een een telefoonnummer in een notitieveld, de ander voegt het toe aan een naamveld en weer iemand anders voert het helemaal niet in. Met een duidelijke contacttabel werkt iedereen met dezelfde set details op dezelfde plaatsen. Die structuur helpt apps ook om de gegevens te begrijpen. Een formulier kan de juiste vakjes tonen. Een rapport kan contactpersonen groeperen op status en automatisering kan reageren wanneer een eigenaar verandert. De informatie wordt niet zomaar opgeslagen. Het heeft labels die verbonden tools vertellen wat elk onderdeel betekent. Begin met de standaardtabellen wanneer deze aansluiten bij uw bedrijfsbehoefte. Als u aan bedrijven verkoopt, beschrijven accounts en contactpersonen al een patroon dat de meeste mensen begrijpen. Als u klantondersteuning biedt, geven casussen u een startpunt. Voeg daarna alleen aangepaste tabellen toe waar uw bedrijf informatie heeft die niet in de ingebouwde patronen past.

Dit voorkomt een veelvoorkomend probleem, het maken van vijf verschillende tabellen die allemaal klant betekenen. Het ene team noemt het cliënt, een ander klantbeheer en een derde partnercontact. Al snel weten mensen niet meer welke tabel ze moeten gebruiken. Duidelijke standaardtabellen en zorgvuldig benoemde aangepaste tabellen houden het systeem begrijpelijk naarmate meer mensen ermee werken. Het volgende onderdeel is waar die lades met elkaar gaan samenwerken. Een contactpersoon hoort bij een account. Maria werkt voor Contoso Limited. In plaats van het adres, het hoofdnummer en de bedrijfsgegevens van Contoso steeds opnieuw bij Maria in te voeren, kan dataverse een relatie leggen tussen de tabel voor contactpersonen en de tabel voor accounts. Maria is gekoppeld aan Contoso en die koppeling is belangrijk omdat bedrijfsinformatie bij het bedrijf hoort. Als Contoso van kantooradres verandert, hoeft iemand de accountgegevens slechts één keer bij te werken.

Elke gekoppelde contactpersoon verwijst dan direct naar het juiste bedrijf zonder zelf een verouderde kopie te bewaren. Relaties verbinden ook een ondersteuningsaanvraag met de klant die deze heeft ingediend. Ze kunnen een verkoopkans verbinden aan de telefoongesprekken, e-mails, afspraken en taken rondom die deal. Wanneer een verkoper een verkoopkans opent, ziet diegene direct de bijbehorende activiteiten, in plaats van te moeten zoeken inlossen notices en agenda's. De informatie krijgt zo context. Je kijkt niet alleen naar een ticketnummer, je ziet bij welke klant het hoort. Je bekijkt niet alleen een contactpersoon, je ziet ook het bedrijf dat aan die persoon is gekoppeld. Die koppelingen houden de gegevens bruikbaar zonder dat je steeds dezelfde feiten op meerdere plaatsen hoeft in te voeren. Een kleine opmerking over de naamgeving voordat je oudere handleidingen leest of video's bekijkt.

Mogelijk hoor je de termen entiteit, veld en record. Dat zijn oudere termen voor dataverse. Microsoft gebruikt nu tabel in plaats van entiteit, kolom in plaats van veld en rij in plaats van record. De betekenis is onveranderd. Een oudere handleiding waarin staat dat je een entiteit moet maken, bedoelt eigenlijk een tabel, een veld is een kolom en een record is een rij. Beide sets termen kennen voorkomt dat je denkt dat je met een ander product te maken hebt. Dus tabellen ordenen de informatie en relaties verbinden deze met elkaar. Maar een goed georganiseerde kast heeft nog steeds beheer nodig. Iemand moet bepalen wat mensen mogen invoeren, wijzigen en veilig inzien. De regels en de receptie. Gegevens in dataverse werken pas echt goed als de juiste mensen er veilig mee kunnen werken. Een verkoper heeft klantgegevens nodig, een supportmedewerker de ticketgeschiedenis, een manager een breder overzicht en een externe partner heeft misschien slechts toegang nodig tot een klein deel van het proces.

Ze hoeven niet allemaal dezelfde informatie te zien. Denk aan een klantrecord met een privé noticie, een onderhandelde prijs en een openstaand support ticket. Elke gebruiker volledige toegang geven, brengt snel risico's met zich mee. Iedereen zo streng beperken dat ze hun werk niet kunnen doen, creëert een ander probleem. Dataverse biedt u hiervoor de juiste hulpmiddelen. En het eerste hulpmiddel begint bij identiteit. Wanneer u zich aanmeldt met uw bedrijfsaccount, identificeert Microsoft EntraID u. Zie EntraID als de receptie bij de ingang van het kantoor. U komt aan, laat uw badge zien en de receptionist controleert wie u bent voordat u naar binnen mag. Dataverse gebruikt die identiteit om te weten welke gebruiker met de gegevens werkt. Het stopt niet bij de vraag, mag deze persoon naar binnen? Het vraagt ook, wat mag deze persoon doen nadat hij binnen is? Dat is waar beveiligingsrollen om de hoek komen kijken.

Een beveiligingsrol is een set machtigingen gekoppeld aan een functie of verantwoordelijkheid. U kunt één rol maken voor verkoopmedewerkers, een andere voor klantenservice medewerkers en weer een andere voor managers. Elke rol kan de toegang tot een tabel beheren. Een verkoper mag bijvoorbeeld accounts, contactpersonen, leads en verkooppansen lezen, maken en bijwerken. Het kan zijn dat zij belangrijke klantinformatie niet mogen verwijderen. Een supportmedewerker kan cases maken en bijwerken, maar geen verkooppansen wijzigen. De machtigingen kunnen betrekking hebben op het lezen, maken, wijzigen en verwijderen van rijen. Dit betekent dat toegang niet afhangt van of iemand onthoudt welke knoppen in elke app moeten worden verborgen. De machtigingen zijn gekoppeld aan de gegevens zelf. De schelden dezelfde kaders overal waar die dataverse gegevens verschijnen. Vervolgens kunt u de toegang nog verder verfijnen.

Beveiliging op rijniveau bepaalt met welke individuele rijen een persoon kan werken. Een verkoper ziet wellicht alleen de eigen klanten, terwijl een verkoopmanager de klantrijen van het hele team kan zien. Beiden gebruiken dezelfde accounttabel. Ze zien alleen niet hetzelfde gedeelte ervan. Die opzet helpt mensen zich op hun eigen werk te concentreren, terwijl managers het nodige overzicht houden. Het verkleint ook de kans dat iemand klantinformatie opent waarvoor zij geen toegangsreden hebben. Sommige informatie heeft nog strengere beveiliging nodig. Beveiliging op kolomniveau kan individuele kolommen binnen een tabel beschermen. Misschien mag een gebruiker een klantrij openen, maar geen persoonsgegevens, salaris, bankgegevens of financiële notices zien. De klantrij blijft beschikbaar voor het werk dat ze moeten doen. De beveiligde kolom blijft beperkt toegankelijk. Voor grotere bedrijven kunnen bedrijfseenheden grenzen creëren tussen organisatieonderdelen.

Een bedrijf kan regio's, divisies of dochterondernemingen scheiden die met verschillende klantgroepen werken. Bedrijfseenheden helpen vorm te geven hoe toegang werkt over die grenzen heen. Dit betekent niet dat elk bedrijf een ingewikkeld beveiligingsplan nodig heeft. Een klein team heeft misschien maar een paar duidelijke rollen nodig. Een groter bedrijf heeft wellicht meer lagen nodig omdat teams, regio's en verantwoordelijkheden verschillen. Het punt is dat dataverse toegang kan afstemmen op hoe het bedrijf daadwerkelijk werkt. Toegangsbeheer beschermt wie bij de gegevens kan, maar regels beschermen ook de kwaliteit van de gegevens zelf. Een bedrijfsregel kan vereisen dat iemand een telefoonnummer invoert voordat een nieuw contact wordt opgeslagen. Het kan een voorwaarde controleren, zoals het vereisen van een reden wanneer een case wordt gesloten. Het kan ook aanpassen wat gebruikers zien op basis van de ingevoerde informatie.

Dezelfde regel is van toepassing op alle apps die die tabel gebruiken. Dit is belangrijk omdat je niet wilt dat de ene app onvolledige gegevens accepteert terwijl de andere ze afwijst. De regel hoort bij de bedrijfsinformatie, niet bij één scherm dat deze toevallig toont. Dataverse kan ook logica op de achtergrond uitvoeren om bedrijfsprocessen consistent te houden. Het detail dat je moet onthouden is simpel. De gegevens komen met regels, niet alleen met opslag. De basis bevat dus de informatie, de mensen die ermee mogen werken en de regels die het bruikbaar houden. Zodra Dynamics 365 op diezelfde basis werkt, heeft het geen traditionele brug nodig om bij zijn eigen bedrijfsgegevens te komen. Wat Dynamics 365 integratie echt betekent, de meeste mensen horen Dynamics 365 integratie met dataverse en stellen zich twee aparte systemen voor verbonden door een connector. Eén systeem bevat de klantgegevens, een ander systeem heeft een kopie nodig, dus stelt iemand een synchronisatie in, wacht tot die draait en hoopt dat er onderweg niets misgaat.

Dat beeld klopt voor veel zakelijke tools. Maar hier, bij Dynamics 365 Sales en Dynamics 365 Customer Service is de verbinding veel hechter. Deze apps gebruiken dataverse als hun gedeelde gegevensbasis. Het zijn geen twee aparte databases die klantrijden heen en weer sturen om elkaar te begrijpen. Ze werken vanaf het begin met dezelfde bedrijfsinformatie. Laten we het concreet maken. Stel je voor dat je een verkoper bent en een nieuw bedrijf aanmaakt in Dynamics 365 Sales. Je voegt het hoofdcontact toe en begint aan een mogelijke deal te werken. Die details worden direct onderdeel van de gedeelde gegevens die de app gebruikt. Later neemt die klant contact op met de support. De supportmedewerker kan met exact dezelfde bedrijfs- en contactgegevens werken. Niemand hoeft een lijst uit sales te exporteren of de klant opnieuw aan te maken in een aparte support tool. De medewerker koppelt simpelweg de support case aan die klant en ziet de geschiedenis die helpt begrijpen wat er aan de hand is.

Sales ziet de deal, support ziet het dossier en beide teams werken rondom dezelfde klant. Dat betekent natuurlijk niet automatisch dat elk schermer identiek uitziet of dat elk team hetzelfde proces volgt. Sales heeft leads, verkoopkansen, telefoontjes en afspraken nodig. Klantenservice heeft dossiers, wachtrijen en servicehistorie nodig. Elke Dynamics 365 app biedt mensen tools die specifiek voor hun werk zijn gebouwd. Terwijl de bedrijfsinformatie erachter overal verbinding kan maken waar nodig, is die gedeelde basis wat mensen vaak bedoelen wanneer ze praten over Dynamics 365 en dataverse integratie. Het gaat niet hoofdzakelijk om het verplaatsen van gegevens van punt A naar punt B. Het gaat erom dat apps vanaf het begin met dezelfde rijen, relaties, regels en toegangscontroles werken. Laten we een eenvoudig verkooptraject doorlopen. Een lead komt binnen via een website of een evenement.

Een verkoper werkt met die lead, leert meer over de persoon en zet de lead om in een klantrelatie en een verkoopkans. Telefoontjes, e-mails, afspraken en taken kunnen allemaal gekoppeld worden aan dat werk. Dus het team hoeft niet in aparte tools te zoeken om het verhaal compleet te maken. Als de klant later hulp nodig heeft, kan een support dossier gekoppeld worden aan diezelfde klant. De support medewerker ziet niet alleen een naam en e-mailadres. Zij kunnen werken in de context van de klantrelatie die al is geïdentificeerd. Ondertussen kan het salesteam zien dat de klant een openstaand serviceprobleem heeft, zodat ze niet onvoorbereid een vernieuwingsgesprek ingaan. Een klantrelatie kan verschillende soorten werk ondersteunen, wat veel nuttiger is dan alleen een overeenkomende klantnaam in twee systemen bijhouden. Misschien hoort u ook de term common data model, soms afgekoord tot cdm.

Laat de naam het niet mysterieuzer laten klinken dan het is. Het betekent simpelweg dat Microsoft algemene zakelijke tabelpatronen biedt voor zaken die veel bedrijven bijhouden, zoals accounts, contactpersonen, activiteiten en dossiers. Deze patronen geven Dynamics 365 en dataverse gebaseerde apps een gedeelde basisstaal. Een account staat voor een bedrijf. Een contactpersoon staat voor een persoon. Een activiteit volgt het werk rondom een zakelijke relatie. U kunt de instellingen voor uw bedrijf aanpassen en indien nodig eigen tabellen toevoegen, maar u begint niet telkens vanaf nul. Wanneer de ene app een accounttabel begrijpt en de andere app diezelfde tabel gebruikt, verwijzen beide apps naar hetzelfde type bedrijfsinformatie. Dit verandert ook wat u kunt bouwen. Stel dat uw buitendienst een eenvoudige app nodig heeft om een klant op te zoeken, een bezoek te bevestigen en een notitie toe te voegen na de afspraak.

U kunt een power-app bouwen die werkt met dezelfde dataverse tabellen die al door Dynamics 365 worden gebruikt. Het is niet nodig om klanten te exporteren naar een nieuwe lijst, alleen voor die app. De buitendienstmedewerker opent de app, vindt de klant en werkt de bezoekgegevens bij. De gegevens blijven gekoppeld aan de klantrelatie die verkoop- of klantenservice al gebruikt, onderworpen aan de beveiligingsregels die we eerder bespraken. Voor meer gestructureerd zakelijk werk kun je een modelgestuurde app bouwen. Een modelgestuurde app begint met een datamodel. Je kiest de dataverse tabellen, definieert hun relaties, stelt formulieren en weergaven in en past beveiligingsrollen toe. Power Apps gebruikt vervolgens die structuur om een werkende zakelijke app ervaring te creëren. Zie het als het inrichten van een werkbank rondom de gereedschappen en materialen die het team daadwerkelijk gebruikt.

De tabellen beschrijven het werk, relaties verbinden de onderdelen. Formulieren bieden mensen de mogelijkheid om details in te voeren en te bekijken. Weergaven helpen hen de rijen te vinden die aandacht vereisen. Beveiliging bepaalt wat ieder persoon kan openen of wijzigen. Een modelgestuurde app kan naast Dynamics 365 bestaan omdat beide met dataverse werken. Misschien behandelt Dynamics 365 zelfs het volledige verkoopproces, terwijl een kleinere modelgestuurde app contractmanagers een gerichte plek biedt om klantafspraken bij te houden. Beide kunnen met gerelateerde klantgegevens werken zonder een tweede klantendatabase aan te maken. Natuurlijk vereist die toegang nog steeds zorgvuldigheid. Alleen omdat een app met een dataverse tabel kan werken, betekent dit niet dat elke gebruiker elke rij moet kunnen bewerken of elke kolom moet zien. De rol, rijtoegang en bedrijfsregels bepalen nog steeds wat er gebeurt.

Een veldtab kan iemand precies de klantdetails en acties geven die ze nodig hebben, zonder de rest van het bedrijf of andere gegevens bloot te stellen. Dus, de integratie van Dynamics 365 met dataverse is nu als een kabel die twee verre kamers verbindt. Dynamics 365 apps, aangepaste apps en bedrijfsprocessen kunnen allemaal vanuit dezelfde gedeelde basis werken. Zodra je dat inziet, wordt de volgende vraag duidelijk. Waar kun je diezelfde klantupdate nog meer voor gebruiken binnen het verbonden platform van Microsoft? Hoe het verbonden platform in het echte werk functioneert. Een gedeelde klantupdate wordt pas nuttig wanneer de tools eromheen kunnen reageren. Power Atomate regelt het vervolgwerk door toezicht te houden op een wijziging in een dataverse rij en een actie te starten wanneer die wijziging plaatsvindt. Bijvoorbeeld, een nieuwe lead komt binnen in Dynamics 365 sales. Een flow kan de toegewezen verkoper op de hoogte stellen, een bericht in Teams plaatsen of een vervolgtaak aanmaken.

Niemand hoeft de hele dag een gedeelde inbox in de gaten te houden. De lead wijzigt en de volgende stap start automatisch. Power Atomate heeft geen aparte kopie van de lead nodig om dat werk te kunnen doen. Het kan reageren op de rij in dataverse met gebruik van dezelfde klant en eigendomsgegevens die de verkoop-app gebruikt. Zo blijft automatisering dicht bij het bedrijfsproces in plaats van te vertrouwen op iemand die een bestand exporteert en een handmatige e-mailketen start. Dan is er Power B. Een verkoopmanager wil misschien de huidige pijplijn zien. Een klantenservice-manager moet misschien zien hoeveel cases deze week zijn binnengekomen, welke cases openstaan of welke klanten het vaakst contact opnemen met de ondersteuning. Power B kan rapporteren over dataverse bedrijfsgegevens, zodat die teams het werk kunnen zien zonder elke vrijdagmiddag nieuwe spreadsheet exports te maken. Het rapport is gebaseerd op de bedrijfsgegevens die mensen al gebruiken.

Dat betekent dat een pijplijn-grafiek kan veranderen naarmate kansen vorderen. Een case-dashboard kan de huidige werkdruk tonen terwijl agenten cases bijwerken. Het punt is nu dat een dashboard vervangt dat mensen handmatig details moeten controleren. Het geeft hen een duidelijker beeld van het werk voordat ze beslissen wat aandacht nodig heeft. Power Apps voegt een ander pad toe aan hetzelfde proces. Stel je een buitendienstmedewerker voor die aankomt op een klantlocatie. Ze hebben niet de volledige Dynamics 365 verkoopervaring nodig. Ze hoeven misschien alleen de klant te vinden, de bezoekgegevens te bekijken, te bevestigen wat er is gebeurd en een notitie of foto toe te voegen. Een gerichte Power App kan hen die compactere ervaring bieden. Een accountteam heeft misschien een app nodig voor het beoordelen van klantovereenkomsten. Een manager heeft misschien een eenvoudige app nodig voor het goedkeuren van een verzoek.

Elke app kan zich richten op één taak terwijl deze achter de schermen werkt met dezelfde beheerde dataverse informatie. De persoon ziet de tool die bij zijn dag past. Het bedrijf behoudt de verbonden informatie. Soms begint die informatie buiten dataverse. Een bedrijf heeft misschien een lijst uit een online bron die onderdeel moet worden van de bedrijfsgegevens. Power Query kan gegevens ophalen uit ondersteunde online bronnen, deze tijdens het importeren, opschonen en in de juiste dataverse tabel laden. Dit is nuttig wanneer een externe bron informatie bevat die uw Dynamics en Power Platform tools moeten gebruiken. U moet nog steeds beslissen wat thuishoort in dataverse en hoe dit moet worden gekoppeld aan de bestaande tabellen. Gegevens importeren zonder die overweging verplaatst de verwarring alleen maar naar een nieuwe locatie. Laat Atom de stukjes in één dagelijkse stroom samenbrengen.

Een nieuwe lead komt binnen in Dynamics 365 en een toewijzingsregel controleert wie de eigenaar van die lead moet zijn, wellicht op basis van regio of product. De eigenaar ontvangt een teamsbericht via een Power Atomate Flow, zodat ze weten dat er werk op hen wacht. Terwijl de verkoper de lead bijwerkt en door het verkoopproces verplaatst, verandert het Power B dashboard om het team de huidige pijplijn van Team Atom te tonen. Eén update start nuttig werk op verschillende plaatsen. Power Atomate verplaatst werk van de ene stap naar de volgende. Power B helpt mensen het werk te zien. Power Apps bieden specifieke teams een gerichte manier om bij te dragen. Dataverse houdt bedrijfsinformatie georganiseerd en veilig terwijl die tools hun werk doen. Dat verschil is belangrijk. Automatisering is geen archiefsysteem en een dashboard is geen klantendatabase. Elke tool heeft een eigen taak, maar ze kunnen allemaal vanuit dezelfde bron werken.

Dat weten helpt je de juiste tool te kiezen in plaats van elk spreadsheet of elke lijst te behandelen alsof het een heel bedrijfsproces moet aansturen. Wanneer dataverse past en wat het niet vervangt? Dit is het punt. Kies voor dataverse wanneer meerdere mensen en apps met verbonden bedrijfsgegevens moeten werken. Je hebt duidelijke toegangsregels en herhaalbaar processen nodig. Dataverse regelt dat, maar het vervangt niet alles. Excel is nog steeds je go-to voor persoonlijke analyses en snelle lijsten. SharePoint-lijsten werken goed voor eenvoudige teamtracking. En als je een ontwikkelaar bent die diepgaande controle nodig heeft, blijft SQL een sterke keuze. Dus, wanneer past dataverse echt? Wanneer je data verbonden moet zijn tussen Dynamics 365 apps, automatisering en rapporten zonder een extra kopie te maken. Dat is waar het uitblinkt. Maar, de conclusie, een fundament, vele zakelijke tools.

Dus, dit is de kern van de zaak. Dynamics 365 en dataverse werken het best wanneer al je data, regels, beveiliging, apps, automatisering en rapporten één gemeenschappelijke basis delen. Abonneer je op Microsoft Knowledge Nuggets op M365.fm voor meer begrijpelijke handleidingen over Dynamics 365, Power Platform en Microsoft 365. Bekijk vervolgens onze aflevering over modelgestuurde apps om te zien hoe dataverse tabellen veranderen in een werkende zakelijke app. www.mp4信.drink