Welkom bij Microsoft Knowledge Nubbets. Ik ben Mo Peters. Het onderwerp van vandaag zorgt vaak voor verwarring. Wat is Dataverse nu precies? Is het een database, een app of een verborgen Dynamics 365 dienst die alleen IT-ers moeten begrijpen? Hier is de simpelste definitie. Dataverse is de gedeelde gegevensfundering achter veel Dynamics 365 ervaringen. Zie Dynamics 365 als een kantoorpand. Sales, klantenservice en andere apps zijn de kamers waar mensen werken, terwijl Dataverse het archiefsysteem en de regels achter de muren is. Aan het eind van deze aflevering weet je waar Dynamics gegevens wonen en hoe één klantupdate kan verschijnen in saleswerk, automatisering en rapportages. Maar voordat we in productnamen duiken, beginnen we bij de zakelijke puinhoop. Dit lost één gedeelde plek op. Stel je in plaats van losse kopieën een bedrijf voor met een sales team, een support team en een financieel team.

Sales houdt klantgegevens bij in een spreadsheet. Support werkt in een aparte tool voor klantvragen. Finance heeft klantnamen in zijn eigen systeem staan. Iemand anders slaat email threads op in een gedeelde mailbox, terwijl weer een ander noties is bewaard in een map die niemand anders kan vinden. Dezelfde klant bestaat nu op vijf plekken. Die opzet voelt in het begin normaal, omdat elk team alleen het stukje werk voor hun neus ziet. Maar hier is het punt. Zodra een klant het telefoonnummer, adres, bedrijfsnaam of hoofdcontactpersoon wijzigt, beginnen de problemen. Sales werkt de spreadsheet bij. Support ziet dit niet. Finance stuurt documenten nog steeds naar het oude adres. Dan exporteert iemand een lijst, maakt deze handmatig schoon, mailt deze 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 met hun werk om gegevens te vergelijken. Managers vragen zich af waarom een rapport niet overeenkomt met het salesysteem. Een supportmedewerker opent een ticket voor een klant van wie de gegevens al ergens anders staan, alleen net even anders. Niemand probeert er een puinhoop van te maken. De puinhoop ontstaat door kopieën. Twintig jaar geleden betekenden aparte systemen aparte servers, aparte databases en aparte teams die hun eigen informatie bijhielden. Het koppelen ervan vergt de maatwerk, geplande imports en veel handmatige controle. Een wijziging op de ene plek bereikte een ander systeem misschien morgen, volgende week of nooit. Dataverse geeft bedrijfsapps een gedeelde plek voor dit soort informatie. In gewone taal, 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 losse notices, bestanden en onsamenhangende spreadsheet tabbladen te bestaan.

Je kunt het zien als het archief van het bedrijf, maar dan één waar meerdere goedgekeurde tools tegelijkertijd gebruik van kunnen maken. Een klant komt één keer voor 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 kan zien. Toegang heeft nog steeds regels nodig, en daar komen we zo op terug. Het betekent dat goedgekeurde apps kunnen werken met dezelfde bedrijfsinformatie 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 praat over het integreren van Dynamics 365 met Dataverse, denken ze vaak aan twee aparte producten waar een koppeling tussen nodig is. Voor veel Dynamics 365 apps is dat niet het geval. De gegevens bevinden zich 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 actueel blijven. Je kunt voortbouwen op hetzelfde fundament met gebruik van dezelfde bedrijfsinformatie die Dynamics 365 al gebruikt. 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 ieder van hen doen. Nu is het zo dat Dataverse niet elk systeem van een bedrijf vervangt.

Een bedrijf kan nog steeds financiële software, sectorale tools, magazijnssystemen, websites of oudere applicaties gebruiken die hun eigen data bevatten. 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, verkoopwerk, ondersteuningswerk, taken en follow-ups. Die records kunnen samenleven met één bron die goedgekeurde tools kunnen lezen en bijwerken. Dus, open dat archief samen met mij. Zodra je ziet hoe Dataverse de informatie organiseert, wordt de hele Dynamics 365 connectie veel gemakkelijker te begrijpen. De archieftabellen, rijen, kolommen en relaties. Laten we dat archief openen. Binnen Dataverse staat informatie en tabellen. Denk erover als een echte archiefkast met aparte lades. Eén lade bevat bedrijven, een andere bevat personen en een derde bevat ondersteuningsverzoeken.

Je gooit niet elk papiertje in één enorme laden in de hoop dat iemand het later kan uitzoeken. Elke lade heeft een taak. In Dataverse bevat een tabel dus één type bedrijfsinformatie. Een account-tabel bevat meestal bedrijven waar u mee werkt. Een contact-persoon-tabel bevat individuele personen. Een lead-tabel bevat potentiële klanten voordat ze echte klanten worden. Een casu-stabel bevat ondersteuningsverzoeken, terwijl een activiteiten-tabel werkt zoals telefoontjes, e-mails, afspraken en taken bijhoudt. Dat zijn standaard-tabellen. Microsoft levert deze mee omdat de meeste bedrijven klanten, mensen, werk en gesprekken moeten bijhouden. U hoeft niet opnieuw het wiel uit te vinden voor iets algemeens als een standaard-tabel al aan uw behoefte voldoet. Maar elk bedrijf heeft ook zijn eigen specifieke werkzaamheden. Een trainingsbedrijf moet misschien cursussen en certificaten bijhouden. Een vastgoedbedrijf heeft misschien gebouwen, eenheden en inspecties nodig.

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

Zo krijgt bedrijfsinformatie een betrouwbare vorm. Zonder kolommen typte een telefoonnummer in een notitievak, voegt een andere toe aan een naamveld en voert iemand anders het misschien helemaal niet in. Met een duidelijke contacttabel werkt iedereen met dezelfde set details op dezelfde plekken. 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 een automatisering kan reageren wanneer een eigenaar wijzigt. De informatie wordt niet zomaar ergens opgeslagen. Het heeft labels die aan gekoppelde tools vertellen wat elk onderdeel betekent. Begin met de standaardtabellen wanneer deze aansluiten bij uw zakelijke behoefte. Als u aan bedrijven verkoopt, beschrijven accounts en contactpersonen al een patroon dat de meeste mensen begrijpen. Als u klant ondersteuning biedt, geven casussen u een startpunt.

Voeg dan alleen aangepaste tabellen toe als 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, het andere klantoverzicht en een derde partner contact EU. 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 eraan bouwen. Het volgende onderdeel is waar die lades met elkaar gaan samenwerken. Een contactpersoon hoort bij een account. Maria werkt voor Contoso Looted. In plaats van het adres, het hoofdtelefoonnummer en de bedrijfsgegevens van Contoso opnieuw in de rij van Maria te typen, kan Dataverse een relatie leggen tussen de contacttabel en de accounttabel. Maria is gekoppeld aan Contoso en die link is belangrijk omdat bedrijfsinformatie bij het bedrijf blijft.

Als Contoso van kantooradres verandert, werkt iemand de accountreis slecht één keer bij. Elke gerelateerde contactpersoon kan nog steeds naar hetzelfde bedrijf verwijzen zonder een eigen verouderde kopie te bewaren. Relaties verbinden ook een support ticket met de klant die het heeft ingediend. Ze kunnen een verkoopkans verbinden met de gesprekken, e-mails, vergaderingen en taken rondom die deal. Wanneer een verkoper een verkoopkans opent, kunnen ze de bijbehorende activiteiten zien in plaats van te zoeken in irrelevante notices en agenda's. De informatie heeft context. Je kijkt niet alleen naar een ticketnummer. Oh, je kunt zien bij welke klant het hoort. Je bekijkt niet alleen een contactpersoon. Je kunt het bedrijf zien dat aan die persoon is gekoppeld. Die koppelingen houden de gegevens bruikbaar zonder dat je steeds dezelfde feiten op meerdere plekken hoeft te typen. Een kleine opmerking over de naamgeving voordat je oudere handleidingen leest of video's bekijkt.

Je hoort wellicht de termen entiteit, veld en record. Dat zijn oudere dataverse termen. Microsoft gebruikt nu tabel in plaats van entiteit, kolom in plaats van veld en rij in plaats van record. De betekenis is niet veranderd. Oh, een oudere handleiding die zegt dat je een entiteit moet maken, bedoelt het maken van een tabel. Een veld is een kolom en een record is een rij. Beide sets woorden kennen voorkomt dat je denkt dat je een ander product hebt gevonden. Tabellen organiseren dus de informatie en de relaties die zijn verbonden. Maar een goed georganiseerde kast heeft ook controle nodig. Iemand moet beslissen wat mensen kunnen invoeren, wijzigen en veilig kunnen inzien. De regels en de receptie achter de gegevens. Gedeelde gegevens werken alleen als de juiste mensen er veilig mee kunnen werken. Een verkoper heeft klantgegevens nodig. Een supportmedewerker heeft een ticketgeschiedenis nodig.

Een manager heeft een breder overzicht nodig. En een externe partner heeft misschien alleen toegang nodig tot een klein deel van het proces. Ze zouden niet allemaal dezelfde informatie moeten zien. Denk aan een klantrecord met een privénoticie, een onderhandelde prijs en een openstaand supportticket. 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 bied je hiervoor de nodige controles. De eerste controle begint bij identiteit. Wanneer je inlogt met je bedrijfsaccount, identificeert Microsoft EntraID je. Zie EntraID als de receptie bij de ingang van het kantoor. Je komt aan, toont je badge en de receptionist controleert wie je bent voordat je naar binnen mag. Dataverse gebruikt die identiteit om te weten welke gebruiker met de gegevens werkt. Het stopt niet bij de vraag of deze persoon naar binnen mag.

Het vraagt ook wat deze persoon mag doen nadat hij binnen is. Daar komen beveiligingsrollen om de hoek kijken. Een beveiligingsrol is een set machtigingen gekoppeld aan een functie of verantwoordelijkheid. Je 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 verkoopkansen lezen, aanmaken en bijwerken. Mogelijk mag deze persoon geen belangrijke klantinformatie verwijderen. Een supportmedewerker mag cases aanmaken en bijwerken, maar geen verkoopkansen wijzigen. De machtigingen kunnen betrekking hebben op het lezen, aanmaken, wijzigen en verwijderen van rijen. Dit betekent dat toegang niet afhangt van het onthouden van welke knoppen in elke app moeten worden verborgen. De machtigingen liggen bij de gegevens zelf, dus dezelfde kaders gelden overal waar die dataverse gegevens verschijnen.

Vervolgens kun je de toegang nog verder inperken. Rijbeveiliging bepaalt met welke individuele rijen een persoon kan werken. Een verkoper ziet misschien alleen de klanten die van hem zijn, terwijl een salesmanager de klantrijen van het hele team kan zien. Beiden gebruiken dezelfde accounttabel. Ze zien alleen niet hetzelfde deel 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 informatie opent over een klant die ze niet hoeven in te zien. Sommige informatie heeft nog strengere bescherming nodig. Kolombeveiliging kan individuele kolommen in een tabel beschermen. Misschien mag een gebruiker een klantrij openen, maar geen persoonsgegevens, salaris, bankgegevens of privé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 over die grenzen heen werkt. Dit betekent niet dat elk bedrijf een ingewikkeld beveiligingsplan nodig heeft. Een klein team heeft misschien slechts 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 de 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 veranderen wat gebruikers zien op basis van de informatie die zij invoeren. Dezelfde regel is van toepassing op alle apps die die tabel gebruiken. Dit is belangrijk, want u wilt niet dat de ene app onvolledige gegevens accepteert terwijl een andere app ze weigert. De regel hoort bij de bedrijfsinformatie, niet bij één scherm dat deze toevallig weergeeft. Dataverse kan ook logica op de achtergrond uitvoeren om bedrijfsprocessen consistent te houden. Het detail dat u moet onthouden is eenvoudig. De gegevens komen met regels, niet alleen met opslag. De basisomvat 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 werkelijk betekent, de meeste mensen horen Dynamics 365 integratie met dataverse en stellen zich twee afzonderlijke systemen voor die verbonden zijn door een connector.

Het ene systeem bevat de klantgegevens, het andere systeem heeft een kopie nodig, dus iemand stelt een synchronisatie in, wacht tot deze is uitgevoerd en hoopt dat er onderweg niets misgaat. Dat beeld is logisch voor veel zakelijke hulpmiddelen. Maar hier is het punt, voor Dynamics 365 Sales en Dynamics 365 Customer Service is de verbinding veel nauwer dan dat. Deze apps gebruiken dataverse als hun gedeelde gegevensbasis. Het zijn geen afzonderlijke databases die klantgegevens heen en weer sturen om elkaar te begrijpen. Ze werken vanaf het begin met dezelfde bedrijfsinformatie. Stel u voor, u bent een verkoper en u maakt een nieuw bedrijf aan in Dynamics 365 Sales. U voegt het hoofdcontact toe en u begint te werken aan een mogelijke deal. Die details worden onmiddellijk onderdeel van de gedeelde gegevens die de app gebruikt. Later neemt die klant contact op met de ondersteuning. De ondersteuningsmedewerker 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 ondersteuningstool. De medewerker koppelt de ondersteuningscase eenvoudig aan die klant en ziet de geschiedenis die helpt begrijpen wat er aan de hand is. Sales ziet de deal. Support ziet de case en beide teams werken rondom dezelfde klant. Dat betekent natuurlijk niet dat elk scherm er hetzelfde uitziet of dat elk team hetzelfde proces volgt. Sales heeft leads, verkoopkansen, telefoontjes en vergaderingen nodig. Klantenservice heeft cases, wachtrijen en servicehistorie nodig. Elke Dynamics 365 app biedt mensen hulpmiddelen voor hun werk, terwijl de onderliggende bedrijfsinformatie overal verbonden kan zijn. Die gedeelde basis is wat men vaak bedoelt bij Dynamics 365 en dataverse integratie. Het gaat niet alleen om data van A naar B verplaatsen. Het gaat om apps die met dezelfde rijen, relaties, regels en toegangscontroles werken.

Laten we vanaf het begin een eenvoudig verkooptraject doorlopen. Een lead komt binnen via een website of evenement. Een verkoper werkt met die lead, leert de persoon kennen en zet de lead om in een klantrelatie en een verkoopkans. Gesprekken, e-mails, afspraken en taken kunnen allemaal aan dat werk worden gekoppeld. Het team hoeft dus niet in verschillende tools naar het volledige verhaal te zoeken. Als de klant later hulp nodig heeft, kan een support case aan diezelfde klant worden gekoppeld. De support medewerker ziet niet alleen een naam en e-mailadres. Zij kunnen werken binnen de context van de reeds bekende klantrelatie. Ondertussen kan het verkoopteam zien dat de klant een openstaand serviceprobleem heeft om onvoorbereid een verlengingsgesprek te vermijden. Een klantrelatie kan verschillende soorten werk ondersteunen. Dat is veel nuttiger dan simpelweg een overeenkomende klantnaam in twee systemen bijhouden.

U wordt wellicht ook de term common data model, soms afgekoord tot CDM. Laat de naam het niet mysterieuzer maken dan het is. Het betekent simpelweg dat Microsoft standaard bedrijfstabelpatronen biedt voor zaken die veel bedrijven bijhouden, zoals accounts, contactpersonen, activiteiten en cases. Deze patronen geven Dynamics 365 en Dataverse apps een gedeelde basis taal. Een account staat voor een bedrijf. Een contactpersoon staat voor een persoon. Een activiteit houdt werk rond een zakelijke relatie bij. U kunt de instellingen voor uw bedrijf aanpassen en eigen tabellen toevoegen, maar u hoeft niet telkens vanaf nul te beginnen. Wanneer de ene app een accounttabel begrijpt en een 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 na aflopen notitie toe te voegen.

U kunt een power app bouwen die werkt met dezelfde dataverse tabellen die Dynamics 365 al gebruikt. Het is niet nodig om klanten naar een nieuwe lijst te exporteren voor die app. De buitendienstmedewerker opent de app, vindt de klant en werkt de bezoekinformatie bij. De gegevens blijven verbonden met de klantrelatie die Sales 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 gegevensmodel. Je kiest de dataverse tabellen, definieert hun relaties, stelt formulieren en weergaven in en past beveiligingsrollen toe. Power Apps gebruikt die structuur vervolgens om een werkende zakelijke app ervaring te creëren. Zie het als het inrichten van een werkbank rondom de tools en materialen die het team daadwerkelijk gebruikt. De tabellen beschrijven het werk.

Relaties verbinden de onderdelen met elkaar. Formulieren bieden mensen een plek om details in te voeren en te bekijken. Weergaven helpen hen de rijen te vinden die aandacht vereisen. Beveiliging bepaalt wat elke 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 contractbeheerders een gerichte plek geeft om klantafspraken bij te houden. Beiden 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 bewerken of elke kolom moet zien. De rolgebaseerde rijtoegang en bedrijfsregels bepalen nog steeds wat er gebeurt. Een veldtab kan iemand precies de klantdetails en acties bieden die nodig zijn, zonder de rest van de bedrijfsgegevens bloot te stellen.

Dus de integratie van Dynamics 365 met dataverse is niet langer een kabel die twee verre kamers verbindt. Dynamics 365 apps, aangepaste apps en bedrijfsprocessen kunnen allemaal vanuit hetzelfde gedeelde fundament werken. Zodra je dat ziet, wordt de volgende vraag duidelijk. Wat kan er nog meer gebruik maken van diezelfde klantupdate binnen het verbonden Microsoft platform? Hoe werkt het verbonden platform in de praktijk? Een gedeelde klantupdate wordt nuttig wanneer de tools eromheen kunnen reageren. Power Automate regelt het vervolgwerk door een wijziging in een dataverse rij in de gaten te houden 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 informeren, een bericht in Teams plaatsen of een vervolgtaak aanmaken. Niemand hoeft de hele dag een gedeelde inbox in de gaten te houden.

De lead verandert en de volgende stap wordt automatisch gestart. Power Automate heeft geen aparte kopie van de lead nodig om dat werk te doen. Het kan reageren op de rij in dataverse met gebruik van dezelfde klant en eigendomsdetails die de sales app gebruikt. En dat houdt de 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 nog Power B. Een salesmanager wil wellicht de huidige pipeline inzien. Een klantenservicemanager wil wellicht weten hoeveel aanvragen er deze week zijn binnengekomen, welke nog openstaan of welke klanten het vaakst contact opnemen met de supportafdeling. Power B kan rapporteren over dataverse bedrijfsgegevens, zodat deze teams de voortgang kunnen zien zonder elke vrijdagmiddag nieuwe spreadsheets te hoeven exporteren. Het rapport is gebaseerd op de bedrijfsgegevens die mensen al gebruiken.

Dit betekent dat een pijplijn grafiek kan veranderen naarmate kansen zich ontwikkelen. Een dashboard voor aanvragen kan de huidige werkdruk tonen terwijl medewerkers de dossiers bijwerken. Het punt is niet dat een dashboard vervangt dat mensen de details controleren. Het geeft hen een duidelijker overzicht van het werk voordat ze bepalen wat aandacht vereist. Power Apps voegt een andere route toe aan hetzelfde proces. Stel je een buitendienstmedewerker voor die op locatie bij een klant aankomt. Zij hebben geen Dynamics 365 sales ervaring nodig. Ze hoeven misschien alleen de klant op te zoeken, de details van het bezoek door te nemen, te bevestigen wat er is gebeurd en een notitie of foto toe te voegen. Een gerichte Power App kan hen die beperkte ervaring bieden. Een accountteam heeft wellicht 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 op de achtergrond met dezelfde beheerde dataverse informatie wordt gewerkt. De persoon ziet de tool die past bij hun dagelijkse werkzaamheden. Het bedrijf behoudt de verbonden informatie. Soms begint die informatie buiten dataverse. Een bedrijf kan een lijst van een online bron hebben die onderdeel moet worden van de bedrijfsgegevens. Power Query kan gegevens uit ondersteunde online bronnen halen, ze tijdens het importeren opschonen en in de juiste dataverse tabel laden. Dit is handig wanneer een externe bron informatie bevat die uw Dynamics en Power Platform tools moeten gebruiken. U moet nog steeds bepalen wat er in dataverse thuishoort en hoe dit verbonden moet worden met de bestaande tabellen. Gegevens importeren zonder die overweging verplaatst de verwarring simpelweg naar een nieuwe locatie. Laten we de stukjes samenvoegen tot één alledaagse flow.

Een nieuwe lead komt binnen in Dynamics 365. Een toewijzingsregel controleert wie de eigenaar van die lead moet zijn, bijvoorbeeld op basis van regio of product. De eigenaar ontvangt een teamsbericht via een Power Automate Flow, zodat deze weet dat er werk klaar ligt. Terwijl de verkoper de lead bijwerkt en door het verkoopproces leidt, verandert het Power B dashboard om het team, ons team en de huidige pijplijn weer te geven. Eén update start nuttig werk op verschillende plaatsen. Power Automate verplaatst werk van de ene stap naar de volgende. Power B helpt mensen het werk inzichtelijk te maken. Power Apps bieden specifieke teams een gerichte manier om deel te nemen. Dataverse houdt de bedrijfsinformatie georganiseerd en veilig terwijl deze tools hun werk doen. Dat verschil is belangrijk. Automatisering is niet het archiefsysteem en een dashboard is niet de klantendatabase. Elke tool heeft zijn eigen taak, maar ze kunnen allemaal werken vanuit dezelfde bron.

Dat weten helpt je de juiste tool te kiezen, in plaats van elk spreadsheet of simpele lijst te gebruiken 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 moeten werken met gekoppelde bedrijfsgegevens. Je hebt duidelijke toegangsregels en herhaalbaar processen nodig. Dataverse regelt dat, maar het vervangt niet alles. Excel blijft je beste keuze voor persoonlijke analyses en snelle lijsten. SharePoint lijsten werken goed voor eenvoudig bijhouden binnen Teams. En als je een ontwikkelaar bent die diepe controle nodig heeft, blijft SQL een sterke keuze. Dus wanneer past dataverse echt? Wanneer je gegevens verbonden moeten zijn tussen Dynamics 365, apps, automatisering en rapporten zonder een nieuwe kopie te maken. Dat is waar het uitblinkt. Nu de conclusie één fundament, veelzakelijke tools.

Dus dit is de kern van de zaak. Dynamics 365 en dataverse werken het best wanneer al je gegevens, regels, beveiliging, apps, automatisering en rapporten één gemeenschappelijke basis delen. Abonneer je op Microsoft Knowledge Nuggets op M365FM voor meer duidelijke handleidingen over Dynamics 365, Power Platform en Microsoft 365. Bekijk daarna onze aflevering over model Driven apps om te zien hoe dataverse tabellen veranderen in een werkende bedrijfsapp.