Een verkoper werkt een klantadres bij. Later opent financiën hetzelfde dossier en ziet nog steeds het oude adres. Dus, welk adres is het juiste? Jarenlang betekende dit dat iemand gegevens moest exporteren, een spreadsheet bewerken, e-mailen en dezelfde update twee keer in een tweede app moest typen. Dynamics 365 Jewelright verandert dat. Het verbindt financiële en operationele apps met klantapps op basis van dataversen, zodat gedeelde records zoals klanten en orders automatisch synchroon blijven. Je bent bij mij, ik ben Milko Peters van M365FM en dit kennisfragment legt Jewelright in begrijpelijke taal uit. We bespreken wat er verplaatst, hoe het verplaatst, waar Jewelright past en waar het niet past. Laten we eerst beginnen met het zakelijke probleem dat de behoefte hieraan creëerde. Het probleem dat Jewelright oplost. Stel je een bedrijf voor waar twee groepen aan dezelfde klant werken, maar dagelijks totaal verschillende apps gebruiken.

Financiële en operationele apps verzorgen het backoffice werk. Dat gaat over geld, voorraad, producten, orders, inkoop en de toeleveringsketen. Dit is waar een bedrijf bijhoudt wat het verkoopt, wat het kan leveren, wat het verschuldigd is en wat een klant moet betalen. Klant apps richten zich op werk dichter bij de klant. Verkoopteams volgen leads en creëren kansen. Klantenservice behandelt vragen en cases. Vield service plant taken en stuurt mensen naar locaties. Projectteams volgen het werk dat aan een klant is beloofd. Ander werk vereist andere schermen. Een verkoper hoeft niet door een financieel scherm te spitten om enkel een contactpersoon bij te werken na een telefoontje. Maar een financiële gebruiker heeft klant- en ordergegevens nodig die overeenkomen met wat sales ziet, want facturen en leveringen hangen af van die informatie. Zonder verbinding wordt één klant stilletjes twee records.

Sales noteert misschien Northwind Bike, terwijl financiën Northwind Bicycle Company noteert. Oh, het ene dossier heeft het nieuwe adres, het andere stuurt facturen nog naar het oude kantoor. Beide dossiers zien er op zichzelf logisch uit, maar ze beschrijven niet langer dezelfde zakelijke relatie. Eerst duiken kleine problemen op. Iemand kan een klant niet vinden omdat de naam in een andere app anders is. Een verkoper belooft een prijs of controleert de voorraad, maar de informatie komt niet overeen met de operationele kant. Financiën moet een order verwerken, maar de klantgegevens vereisen een check, een e-mail en nog een handmatige update. Vervolgens stapelen die kleine problemen zich op. Iemand exporteert klantgegevens naar een spreadsheet. Een ander corrigeert een paar rijen en importeert ze ergens anders. Weer iemand anders voert een nieuwe klant in beide apps in omdat niemand weet welk record als eerste verschijnt.

Al snel zijn er duplicaten, verschillende adressen en wordt er meer tijd besteed aan het controleren van data dan aan het gebruiken ervan. Dit gebeurt niet omdat mensen slordig zijn. Het gebeurt omdat de systemen van mensen vragen om de verbinding te zijn. Mensen kopiëren gegevens. Mensen onthouden welke app eerst komt. Mensen zien fouten pas als ze al een ander team hebben bereikt. Die aanpak werkte toen bedrijfssystemen gescheiden bleven en teamsvertragingen accepteerden. Maar als verkoop, service, financiën en operations gedurende de dag allemaal dezelfde klantinformatie nodig hebben, is een spreadsheet een gebrekkig hulpmiddel voor overdracht. Denk aan een eenvoudig gesprek over een bestelling. Een klant belt de verkoopafdeling en vraagt, hoe kunnen jullie volgende week leveren en wat gaat dat kosten? Aanhalingsteken. Het verkoopteam heeft product, prijs en voorraadgegevens nodig om antwoord te geven.

Zodra de klant akkoord gaat, hebben financiën en operations de juiste klant- en bestelgegevens nodig om de verkoop te verwerken. Beide kanten hebben dezelfde feiten nodig. Verkoop heeft die feiten nodig in de app waar verkopers werken. Financiën en operations hebben ze nodig in de app waar zij bestellingen, geld en levering beheren. Het doel is niet om elk team in één gigantisch scherm te dwingen. Het doel is dat gedeelde records een duidelijke, afgesproken route volgen. Dat is waar Jewelright in beeld komt. Wat is Jewelright eigenlijk? Dus, wat is Jewelright precies? Dit is de eenvoudigste definitie. Jewelright is de ingebouwde verbinding van Microsoft die geselecteerde gegevens synchroniseert tussen Dynamics 365 Finance & Operations apps en Dataverse. Dataverse is de gedeelde gegevensfundering achter veelzakelijke Microsoft apps. Dynamics 365 Sales, Customer Service, Field Service en delen van project operations maken er allemaal gebruik van.

Power Apps en Power Automate kunnen het ook gebruiken. Je hoeft niet te weten hoe Dataverse elk afzonderlijk record opslaat om Jewelright te begrijpen. Zie het gewoon als het gemeenschappelijke gegevensgebied aan de kant van de klant-apps van Dynamics 365. Stel je een kantoorgebouw voor met een front-office en een back-office. De front-office regelt de gesprekken met klanten, verkopers, servicemedewerkers, buitendienstmedewerkers. Zij hebben allemaal schermen nodig die hen helpen met mensen te praten, verzoeken te volgen en werk te beheren. De back-office regelt het werk dat het bedrijf draaiende houdt. Onze financiële administratie, voorraad, bestellingen, inkoop, levering. Beide kantoren werken voor hetzelfde bedrijf, maar zonder een goede verbinding tussen hen moet iemand informatie van de ene naar de andere kant brengen. Ze nemen een geprint formulier mee, sturen een e-mail of kopiëren gegevens naar een ander systeem.

Het werk wordt nog steeds gedaan, maar het duurt langer en details kunnen onderweg veranderen. Jewel Right is als een bemande binnendeur tussen die twee kantoren. Wanneer een ondersteund record aan de ene kant verandert, geeft Jewel Right de bijbehorende wijziging via die deur door aan de andere kant. Het combineert niet elke app tot één gigantische app. Sales kan nog steeds in sales werken. Finance kan nog steeds in finance werken. Elk team behoudt de schermen voor het eigen werk, terwijl geselecteerde gedeelde informatie achter de schermen verbonden blijft. Dat woord ondersteund is belangrijk. Jewel Right kopieert niet blindelings elk stukje data in beide systemen. Het werkt via gedefinieerde verbindingen tussen records die bij elkaar horen. Microsoft noemt deze verbindingen tabelmappings. Een tabel is simpelweg een plek waar een app één type record opslaat. Een klantentabel slaat klanten records op.

Een producttabel slaat product records op. Een adreestabel slaat adresgegevens op. Een tabelmapping vertelt Jewel Right welke tabel in finance en operations gekoppeld is aan welke tabel in dataverse. Zie een tabelmapping als een overeengekomen vertaalblad. De ene kolom identificeert een record aan de ene kant. De andere kolom identificeert het bijbehorende record aan de andere kant. De rest van het blad legt uit welke velden bij elkaar horen. Onze naam, telefoonnummer, adresregel. Die afspraak levert de verbindingsregels. Zonder dat zouden twee apps verschillende labels kunnen gebruiken of dezelfde gegevens op verschillende plekken opslaan. Een mapping vertelt Jewel Right hoe die details zich tot elkaar verhouden. Zo hoeven de apps niet telkens door een persoon geïnterpreteerd te worden. Mensen horen de naam Jewel Right vaak en gaan ervan uit dat elke wijziging altijd beide kanten opgaat.

Soms is dat ook zo. Bij een ondersteunde tweerichtingsmapping kan een wijziging in dataverse het gerelateerde record in finance en operations bijwerken. Een ondersteunde wijziging in finance en operations kan ook het gerelateerde record in dataverse bijwerken. Beide kanten kunnen deelnemen aan hetzelfde gedeelde record. Dat is het Jewel gedeelte. De update gebeurt bijna in realtime. Het gaat snel terwijl mensen werken in plaats van te wachten op een geplande taak die s'nachts draait. Een gebruiker werkt een ondersteund record bij en de verbinding verstuurt die update terwijl het werk nog actueel is. Bijna realtime betekent geen magie of nul vertraging. Het betekent dat de verbinding gebouwd is voor live zakelijk werk, niet voor een dagelijkse bestandsuitwisseling. Als iemand een detail wijzigt, hoeft het gerelateerde team niet tot morgenochtend te wachten om het te zien. Dat verandert de manier waarop teams kunnen werken.

De frontoffice kan data gebruiken die uit de backoffice komt. De backoffice kan ondersteunde updates ontvangen van klantgerichte apps. Dataverse wordt de datafundering aan de ene kant, finance en operations blijft de operationele fundering aan de andere kant... ...en Jewel Right houdt de goedgekeurde gedeelde records verbonden. Toch heeft een live interne deurregels nodig. Voordat je een record in beide richtingen laat reizen, moet je weten waar dat record moet beginnen... ...wie het mag wijzigen en welke kant leidend moet zijn als de twee apps het niet is zijn. Welke gegevens kunnen worden verplaatst en welk systeem beheert ze? Dus, welke records kan Jewel Right verbonden houden? De algemene voorbeelden beginnen met de records die veel afdelingen dagelijks delen. Klantgegevens, adressen, contactpersonen, producten, leveranciers, bedrijfsgegevens en referentie informatie voor financiën en belastingen.

Denk eens even na over een klantrecord. Sales heeft de naam van de klant, de hoofdcontactpersoon, het telefoonnummer en het afleveradres nodig. Finance heeft het juridische klantrecord, factuurgegevens en informatie voor orders en facturen nodig. Als elke afdeling een eigen aparte klantenlijst bijhoudt, besteedt het bedrijf tijd aan het vergelijken van records in plaats van het bedienen van de klant. Met de juiste Jewel Right Maps kunnen die teams werken met gekoppelde klantgegevens. Dat betekent niet dat salesgebruikers plotseling de finance-app moeten leren. Het betekent dat zij met klantinformatie in Dynamics 365 sales kunnen werken, terwijl financegebruikers met de gerelateerde klantinformatie in finance werken. De klant blijft op beide plaatsen herkenbaar als dezelfde klant. Adressen zijn ook belangrijk. Een klant kan een factuuradres, een afleveradres en misschien een locatie hebben waar een servicemedewerker langs moet gaan.

Deze details kunnen niet zomaar als platte tekst in één vakje worden gekopieerd, omdat elk adres een andere functie heeft. Jewel Right ondersteunt de gedeelde recordstructuur die nodig is voor die relatie. Contactpersonen volgen hetzelfde patroon. Een klantbedrijf kan een inkoper, een contactpersoon voor crediteuren en een servicemanager hebben. Sales moet weten wie de beslissingen neemt. Finance moet weten waar factuurvragen naartoe moeten. Service moet weten wie er op locatie wacht. Gekoppelde records helpen elk team de mensen te zien die bij de klant horen, zonder die informatie in elke app opnieuw te hoeven invoeren. Producten zijn een ander algemeen voorbeeld. Een verkoper moet weten wat het bedrijf verkoopt, wat het product kost en of voor voorraad beschikbaar is. Die antwoorden komen meestal van de operationele kant van het bedrijf, omdat daar product, voorraad, inkoop en uitvoering worden beheerd.

Daarom begint productinformatie vaak in finance en operations. Een operatieteam maakt en bereidt daar een product voor. Zodra dat product klaar is voor klantgericht werk, kan Jewel Right de gerelateerde productdetails naar dataverse sturen. Salesgebruikers kunnen vervolgens het product in hun eigen app selecteren en bespreken zonder dat iemand de productlijst een tweede keer hoeft in te voeren. Dat helpt verkoopgesprekken gebaseerd te houden op wat het bedrijf daadwerkelijk kan leveren. Prijs- en voorraadgegevens kunnen via de verbonden apps ook de verkoopafdeling bereiken. In plaats van te gokken of een item bestaat, of de prijs is veranderd, of dat de voorraad een belofte kan waarmaken, kan het salesteam werken met informatie die gekoppeld is aan de operationele kant. Dat neemt de noodzaak voor een goed verkopershef niet weg. Het neemt één vermijdbare reden weg voor een verkoper om het magazijn te bellen om basisgegevens te bevestigen.

Leveranciersinformatie kan ook worden gekoppeld waar een bedrijfsproces dat vereist. Bedrijfsgegevens, organisatiestructuren, financiële referentiegegevens en belastinggegevens kunnen belangrijk zijn voor zowel de klantkant als de operationele kant. De exacte records hangen af van de apps en processen die een bedrijf gebruikt, maar het patroon blijft hetzelfde. Deel de records die op beide plaatsen hetzelfde moeten betekenen. Ga er nu niet vanuit dat elk record in beide richtingen moet reizen. Sommige apps ondersteunen twee RichTings updates. Een wijziging kan beginnen in dataverse en naar finance en operations gaan, of beginnen in finance en operations en naar dataverse gaan. Die aanpak past bij records waarbij beide partijen een geldige zakelijke reden hebben om goedgekeurde details bij te werken. Andere maps werken in één richting. Producten geven ons een nuttig voorbeeld. In veel bedrijven beheert finance en operations het aanmaken van producten omdat operations de productmaster, voorraad, eenheden en andere details beheert die nodig zijn voor verkoop en levering.

Het product stroomt vervolgens naar dataverse, waar verkoop- en serviceteams het kunnen gebruiken. Dat is een duidelijke regel. Het product heeft geen twee teams nodig die concurrerende versies maken. Eén kant maakt en beheert het product, de andere kant ontvangt en gebruikt het als onderdeel van zijn werk. Elk gedeeld record heeft zo'n beslissing nodig. Waar begint dit record? Wie kan het bewerken? Als een naam, adres, prijs of klassificatie er verkeerd uitziet, welk team herstelt dit dan? Die vragen klinken eenvoudig, maar ze voorkomen later veel verwarring. Een verbinding kan een wijziging zeer snel doorvoeren. Als niemand heeft afgesproken wie verantwoordelijk is voor die wijziging, kan het net zo snel een fout doorvoeren. Kies een eigenaar voor het record en, indien nodig, voor individuele details binnen dat record. Verkoop kan bijvoorbeeld de relatiegegevens en primaire contactinformatie van een klant beheren.

Finance kan betalingsgerelateerde details beheren. Operations kan product- en voorraatgegevens beheren. De exacte verdeling hangt af van hoe uw bedrijf werkt, maar het moet worden vastgelegd en begrepen door de mensen die de apps gebruiken. Er zijn ook twee termen die u mogelijk ziet nadat JewelWrite Dataverse uitbreidt, party en company. Een party is de manier van Microsoft om op consistente wijze met een persoon of organisatie om te gaan. Het helpt mensen, organisaties, contactpersonen en adressen te verbinden zonder elke relatie als een apart, niet gerelateerd record te behandelen. Een company helpt Dataverse de zakelijke bedrijfscontext te begrijpen die wordt gebruikt door Finance & Operations. U hoeft op de eerste dag nog geen expert te zijn in beide termen. Weet gewoon dat ze bestaan, want Finance & Operations beheert bedrijfstructuren die klantapps moeten herkennen wanneer gegevens tussen beide kanten worden uitgewisseld.

Zodra gegevens in beide richtingen kunnen reizen, is het proces rondom die gegevens net zo belangrijk als de gegevens zelf. Hoe een wijziging tussen de apps reist Laten we één wijziging door het systeem volgen en kijken wat er daadwerkelijk gebeurt. Een verkoopmedewerker voert een telefoongesprek met een klant die net naar een nieuw kantoor is verhuisd. Tijdens dat gesprek opent de medewerker het klantrecord in Dynamics 365 Sales en werkt het straatadres bij. Vrij eenvoudig, toch? Vervolgens slaan ze het record op. Daar begint het interessante gedeelte. Sales slaat die wijziging op in Dataverse, de datakant voor klantgerichte apps. Vervolgens controleert JewelWrite de koppeling die klant en adresgegevens tussen deze site en Finance & Operations verbindt. Het verstuurt de bijbehorende wijziging automatisch door. Geen exportbestand in een gedeelde map dat wacht tot iemand het oppakt. Niemand hoeft Finance te e-mailen met een bericht als Hé, werk dit adres alsjeblieft bij.

De koppeling weet al welke velden zijn verbonden en stuurt de ondersteunde wijziging direct door naar het gerelateerde klantrecord in Finance & Operations. Zo kan een gebruiker bij Finance dat klantrecord later openen, het bijgewerkte adres zien en een order verwerken of factuur voorbereiden zonder vertraging. Dat is het praktische resultaat, simpel en duidelijk. Twee mensen blijven in verschillende apps werken, maar niemand hoeft dezelfde klantgegevens opnieuw in te voeren. De verkoopmedewerker werkt in een scherm dat is ontworpen voor klantgesprekken. De Finance-gebruiker werkt in een scherm dat is gebouwd voor financiële werkzaamheden. Iedereen ziet de klantinformatie die zij daadwerkelijk nodig hebben, precies waar ze die nodig hebben. En de reis werkt ook in de andere richting. Stel je voor dat Finance ondersteunde klantinformatie bijwerkt in Finance & Operations. Stel dat een Finance-gebruiker een detail corrigeert dat bij het operationele klantrecord hoort.

Jewel Right gebruikt de koppeling in omgekeerde richting en stuurt die gerelateerde update naar dataverse. Vervolgens kunnen Sales, Customer Service of elke andere dataverse gebaseerde app het oppikken. Deze verbinding is synchroon voor het normale dagelijkse werk. Synchroon betekent dat de apps de gerelateerde update proberen te voltooien op hetzelfde moment, in plaats van deze in een achtergrondtaak te plaatsen die pas 20 minuten later draait. Als de verbinding de update niet kan voltooien, moet dat probleem onmiddellijk aandacht krijgen, niet stilletjes verborgen blijven totdat iemand een mismatch opmerkt. Dat gedrag is logisch voor gedeelde bedrijfsgegevens. Je wilt niet dat een klantadres, productdetail of andere gedeelde informatie urenlang uit elkaar loopt omdat een bedstaak nog niet is uitgevoerd. Mensen nemen beslissingen op basis van wat ze op dat moment op hun scherm zien. De verbinding houdt beide kanten dus dicht bij elkaar terwijl er wordt gewerkt.

Toch vereist live werk soms een gecontroleerde pauze. Jewel Right bevat opties voor afspelen, pauseren en inhalen. Afspelen betekent dat de mapping actief is en ondersteunde wijzigingen normaal worden verwerkt. Pauseren stopt de mapping tijdelijk wanneer een team gepland onderhoud moet uitvoeren, een probleem moet onderzoeken of een wijziging veilig wil doorvoeren. Maar pauseren is geen permanente parkeerplek. Terwijl een mapping is gepauseerd, kunnen wijzigingen in de wachtrij komen voor een beperkte tijd en ruimte. Wanneer de mapping wordt hervat, verwerkt de inhaalfunctionaliteit deze wachtende wijzigingen. Dit helpt teams om te herstellen na een geplande onderbreking. Iemand moet echter verantwoordelijk zijn voor die pauze en weten wanneer de mapping weer moet draaien. Voordat dit alles in het dagelijkse werk begint, is er nog een stap, de initiële synchronisatie. De initiële synchronisatie brengt bestaande records van beide kanten naar een gezamenlijk startpunt.

Denk aan een bedrijf dat al klanten heeft in finance en operations en klant records in dataverse. De verbinding kan niet zomaar worden ingeschakeld in de veronderstelling dat elk bestaandrecord al perfect overeenkomt. Er is een startlijn nodig. De initiële synchronisatie helpt om bestaande gegevens over te zetten voordat gebruikers vertrouwen op live updates. Dat werk vereist zorgvuldigheid, omdat dubbele records, onvolledige adressen en oude testgegevens niet magisch verdwijnen zodra een synchronisatie start. Ze kunnen zelfs sneller problemen veroorzaken als de records niet voldoen aan de afgesproken regels. Zodra de mappings draaien, hebben de beheerders van Jewelright een duidelijk overzicht nodig om de status te controleren. Jewelright biedt gecombineerde activiteiten en foutenlogboeken, zodat beheerders kunnen zien wat de verbinding heeft verwerkt en waar problemen zijn opgetreden. Ze kunnen ook waarschuwingen en drempelwaarden instellen.

Dat betekent dat de juiste personen op de hoogte zijn van problemen voordat gebruikers ze ontdekken door een ontbrekende of mislukte update. Dat ondersteuningsperspectief is belangrijk, want elke fout heeft een oorzaak. Misschien ontbreekt er een verplicht veld. Misschien is een gerelateerd record nog niet gearriveerd. Misschien heeft iemand gegevens gewijzigd op een manier die niet in de mapping past. Het opnieuw proberen van een misluktrecord zonder de oorzaak aan te pakken, leidt meestal tot dezelfde fout. Een goed beheerde Jewelright-opstelling bewaakt de verbinding, lost de oorzaak van fouten op en houdt de mappings gericht op records die echt verbonden moeten blijven. Waar Jewelright het beste past? Jewelright past het beste wanneer uw bedrijf Dynamics 365 Finance of Supply Chain Management gebruikt... ...in combinatie met klantgerichte apps zoals Sales, Customer Service, Field Service of Project Operations.

Deze apps ondersteunen verschillende onderdelen van hetzelfde zakelijke proces. Het ene team spreekt met de klant, het andere team plant leveringen, beheert voorraad, volgt kosten of verstuurd facturen. Wanneer beide groepen gedurende de dag met gerelateerde records moeten werken, kan Jewelright dat werk verbinden zonder dat iedereen dezelfde app hoeft te gebruiken. Neem als voorbeeld een prospect-to-cash-proces. Een verkoper werkt met een potentiële klant in Dynamics 365 Sales. Ze houden het contact bij, bespreken producten, maken een offerte en werken toe naar een order. Tijdens dat gesprek heeft de verkoper klantgegevens, productinformatie, prijzen en orderinformatie nodig die betrekking hebben op de financiële kant van het bedrijf. Zodra de verkoop definitief is, neemt Finance & Supply Chain Management het werk over dat na de toezegging volgt. Dit omvat de orderafhandeling, voorraad, facturering en financiële administratie.

Jewelright helpt om die twee onderdelen verbonden te houden. Verkopers kunnen werken in de klantapp die bij hun baan past, terwijl Finance & Operations de transactie beheren in de app die voor hun werk is gebouwd. De klant wordt zo niet twee aparte verhalen, het ene verteld door Sales en het andere door Finance. Field Service is een ander goed voorbeeld. Stel je een bedrijf voor dat technici stuurt om apparatuur te installeren, repareren of onderhouden op klantlocaties. De buitendienstmedewerker heeft klantgegevens nodig, details over het werk en informatie over het klantasset van het item dat het bedrijf heeft geïnstalleerd of ondersteund. Achter de schermen moet het bedrijf ook onderdelen, kosten, inkoop en het geld dat aan dat werk is gekoppeld, bijhouden. Field Service richt zich op het plannen en afronden van het bezoek. Finance & Operations richt zich op de operationele en financiële administratie daaromheen.

Wanneer die records goed verbonden zijn, staat het werk van een technicus niet los van de gebruikte onderdelen, de kosten van het werk of het klantrecord dat eraan is gekoppeld. Project Operations volgt hetzelfde patroon, vooral voor bedrijven die werk per project verkopen. Een projectteam kan klantwerk, tijd van medewerkers, geplande kosten en projectmijlpalen beheren. Finance moet de financiële kant zien van inkoop, kosten, facturering en rapportage. Zonder verbinding kunnen projectmanagers te veel tijd besteden aan het najagen van finance voor updates, terwijl finance wacht tot projectteams bevestigen wat er is gebeurd. Verbonden project records geven beide groepen een duidelijker beeld van het werk naarmate het verschuift van een klanttoezegging naar financiële activiteit. Er is hier ook een breder power platform voordeel, want aangezien de klant app dataverse gebruikt, kan goedgekeurde data in dataverse power apps en power automate ondersteunen.

Een bedrijf kan een kleine app bouwen voor een intern team of een flow maken die reageert wanneer een bedrijfsrecord een bepaald punt bereikt. Dat betekent niet dat elk finance en operationsrecord plotseling in elke power app thuis hoort. Dit betekent dat gekoppelde records deel kunnen uitmaken van een bredere set zakelijke tools, zolang het bedrijf dat tool zorgvuldig kiest en de gegevens goed beveiligt. Eén grens moet duidelijk blijven. JewelWrite ondersteunt Dynamics 365 Business Central niet. Business Central kan via andere methoden verbinding maken met Microsoft producten, maar JewelWrite is bedoeld voor de finance en operations kant van Dynamics 365 en op dataverse gebaseerde klant apps. Het is ook geen tool om zomaar elke tabel te kopiëren die je kunt vinden. Een record moet worden verplaatst omdat mensen hetzelfde operationele record op beide plekken nodig hebben, niet omdat het kopiëren van data veiliger voelt.

JewelWrite vervangt bovendien geen breder integratieplan wanneer een bedrijfrapportage feeds, koppelingen met systemen van derden of een grote datamigratie nodig heeft. Elke dataverbinding als dezelfde taak behandelen zorgt snel voor problemen. Limite, voorbereiding en veel voorkomende fouten Zie JewelWrite als een handelijke overeenkomst tussen twee systemen. Ze spreken af om bepaalde gedeelde records synchroon te houden, maar het is geen magische pijpleiding voor elke tabel, elk rapport of extern systeem. Controleer voordat je het instelt welke integraties er al bestaan. Als een oude verbinding en JewelWrite beide hetzelfde klantrecord bijwerken, kun je snel conflicten creëren. Dat is een hoofdpijndossier dat je niet wilt. Spreek daarom eerst de basis af. Hoe gaan jullie namen invoeren? Welke juridische entiteit is eigenaar van welk record? Wie mag wijzigingen aanbrengen? Welke beveiligingsrollen heeft elk team nodig?

Verwijder dubbele en onvolledige records voor de eerste synchronisatie. Begin met de vooraf gebouwde maps van Microsoft. Deze verbinden al veel gebruikte records. Aangepaste tabellen en velden, die vereisen zorgvuldige tests. En controleer gerelateerde tabellen en mapafhankelijkheden, want soms moet een record eerst bestaan voordat een ander record kan synchroniseren. Plan je eerste synchronisatie op basis van de hoeveelheid data die je hebt. Behandel het niet als een lichtschakelaar die je even tijdens de lanche omzet. Dat zal problemen veroorzaken. Een gepauzeerde map heeft nog steeds een eigenaar en een herstartplan nodig. Wachtrijen met wijzigingen en mislukte records blijven niet eeuwig staan. Hou de activiteitslogboeken, fouten, waarschuwingen en drempelwaarden in de gaten. Wanneer iets mislukt, zoek dan naar het ontbrekende veld, het foutieve record of de gebroken regel erachter. Herhaaldelijk opnieuw proberen lost slechte data niet op.

Wanneer je Jewel Ride ziet als een gecontroleerde brug, valt alles op zijn plek. Conclusie, één gedeeld zakelijk gesprek. Jewel Ride houdt ondersteunde gedeelde records in beweging tussen finance en operations en je op dataverse gebaseerde klantapps. Op die manier kunnen teams werken vanuit verbonden bedrijfsgegevens. Abonneer je op je favoriete podcastplatform voor meer kennis van mij, meer kopeters op m365.fm en deel deze aflevering met iemand die sales, service en finance nog steeds koppelt via weer een ander spreadsheet.