Dynamics 365-rapportering behöver inte längre en datapipeline som man bygger och sedan lägger ner år på att underhålla. Microsoft uppdaterade dokumentationen för Link to Fabric den 29 september, och bilden den beskriver är ovanligt snygg: Link to Fabric sitter nu högst upp i det nya fönstret. Länkdata sida i Power Apps, markerad som det rekommenderade sättet att få ut Dataverse för analys, medan Azure Synapse Link har flyttats till en sekundär Andra länkar avsnitt. Bakom den skriver en snabbare synkroniseringsmotor direkt från Dataverse-databasen till Delta Parquet. För alla team som har arbetat med ett extraktionsjobb så att ekonomiavdelningen kan se pipeline bredvid intäkterna, är det en bra vecka.
Vinsten sträcker sig djupare än snabbare uppdateringar. Tre ändringar som samlas, val på tabellnivå, nyckelfri autentisering och en ändringshistorik på radnivå som kallas Change Data Feed, flyttar arbete från en anpassad version till konfiguration. De team som får ut mest av det är de som behandlar tabellistan som ett medvetet designbeslut snarare än ett standardbeslut att acceptera, eftersom det enda valet nu bestämmer både kostnaden och tydligheten för allt nedströms.
Vad har Microsoft ändrat för Dynamics 365-rapportering?
Konsolideringen är den synliga delen. Varje väg för att flytta Dataverse-data ut för analys börjar nu med en Länkdata sidan, Tygalternativet har en Rekommenderad märket, och du kan inte längre skapa en Azure Synapse-länk från Tabeller område alls. Anslutningar stöder tre autentiseringsmetoder: ett organisationskonto, ett tjänsteprincipal som byggs från hyresgäst-ID, klient-ID och nyckel, eller en arbetsyteidentitet. Microsoft nämner arbetsyteidentitet som det rekommenderade alternativet i enkla ordalag, eftersom det tar bort behovet av att hantera hemligheter och undviker det som dokumentationen kallar det vanligaste installationsfelet för Fabric-länkar, felkonfiguration av tjänsteprincipal. Tabellhantering har också blivit en fristående yta, så att lägga till eller ta bort tabeller innebär inte längre att redigera själva länken.
Motorn under är den väsentliga delen. Synkronisering med låg latens, som Microsoft också kallar Fast Fabric, skriver direkt från Dataverse-databasen till Delta Parquet och tar bort det mellanliggande CSV-steget som den tidigare pipelinen använde. Det tar bort ett helt hopp ur kedjan och, med det, en uppsättning felpunkter. Dataflödet för finans- och verksamhetstabeller når nu upp till en miljon eller fler poster per timme per tabell, jämfört med ett tidigare intervall på ungefär 100 000 till 700 000. Den har varit allmänt tillgänglig sedan juli, den rullas ut per station och aktiveras själv utan anmälningskrav, och du kan bekräfta det genom att leta efter Låg latensläge flagga på din Fabric-länk.
Hur integrerar man CRM med ERP-data för rapportering?
Om din Dataverse-miljö är länkad till en Dynamics 365 finans- och verksamhetsmiljö låter tabellväljaren dig välja finans- och verksamhetstabeller bredvid dina Dataverse-tabeller, och båda hamnar i samma Fabric-lakehouse som OneLake-genvägar. En enda fråga kan sedan följa en affärsmöjlighet fram till den faktura den blev, utan anpassad integration mellan CRM och ERP och inget andra lager att hålla jämna steg med. Rapporteringen läser lakehouse-systemet medan Dynamics 365 fortsätter att hantera applikationen. Så den praktiska vägen till CRM- och ERP-rapportering på ett ställe är nu konfiguration snarare än utveckling: välj tabellerna, peka en semantisk modell mot SQL-analysslutpunkten och låt synkroniseringen hålla dem aktuella.
För tillverknings- och byggkunder är detta den koppling som alltid har varit dyr att bygga och obekväm att lita på, eftersom offert-, order- och leveransdata låg ett system ifrån den affär som skapade den. Två detaljer är värda att känna till innan du börjar. Finans- och drifttabeller väljs inte automatiskt när du skapar länken, så du lägger till dem medvetet. Och synkronisering med låg latens förväntar sig en stödd version, med lägsta plattforms- och applikationsversioner publicerade för versionerna 10.0.47, 10.0.48 och 10.0.49, vilket du kan kontrollera under. Hjälp och stöd sedan Om. Om du installerar den senaste kvalitetsuppdateringen för din version rensas den.
Varför är det bättre att välja bord än att synkronisera allt?
Som standard väljer guiden varje Dataverse-tabell med aktiverad ändringsspårning, vilket i en mogen organisation är många tabeller. Endast de tabeller du väljer förbrukar lagringsutrymme i Fabric, och Delta Parquet-repliken räknas mot din Dataverse-databaskapacitet, så väljaren är en kostnadskontroll snarare än en formalitet. Eftersom tabellhantering nu är en egen yta är listan enkel att återkomma till när rapporteringsbehoven stabiliseras. Det finns också ett praktiskt tak som är värt att planera kring: miljöer med fler än 2 000 aktiva Dataverse-tabeller kan misslyckas med att länka alls, vilket gör ett väl genomtänkt val till den snabbare vägen såväl som den billigare.
Teknisk skuld i CRM är den ackumulerade kostnaden för anpassningar, fält, integrationer och lösningar som var och en var meningsfull när de lades till och som nu saktar ner varje ändring. En tabelllista är ett ovanligt bra ställe att se den. Om ingen kan säga vilken av fyrahundra synkroniserade tabeller en rapport faktiskt läser, så är det skulden som synliggörs, och synlig skuld är billig att agera på. Att rensa en tabell tar bort dess OneLake-genväg och stoppar synkroniseringen utan att röra något i Dataverse, så hela övningen är reversibel och låg risk. Väldigt få granskningar ger dig så mycket insikt för det lilla åtagandet.
Vad ger Change Data Feed intäkter från verksamheter?
Intäktshantering är den funktion som äger systemen, data och processer som kopplar samman marknadsföring, försäljning och kundframgång, så pipeline kan mätas och prognostiseras från början till slut istället för avdelning för avdelning. De svåraste rapporteringsfrågorna är historiska: i vilket skede affärer stannar, hur prognosen såg ut för tre tisdagar sedan, hur lång tid kvalificeringen faktiskt tar. Change Data Feed besvarar dem från plattformen. Det är en Delta Lake-funktion som registrerar infogningar, uppdateringar och borttagningar på radnivå tillsammans med metadata som identifierar varje ändringstyp, och synkronisering med låg latens sparar ungefär 24 timmar av det, vilket Microsoft pekar på tidsresor och trattanalys.
Det här är precis det arbete som RevOps-team har byggt upp för hand i ett decennium: ett nattligt jobb med att skriva in fasvärden i en historiktabell så att någon kan rekonstruera en tratt senare. Nu är det en inställning, under Inställningar, Produkt sedan Drag i Power Platform administrationscenter. En varning, som nämndes en gång: Ändringsdataflödet är minnes- och beräkningsintensivt och kan öka synkroniseringslatensen, så aktivera det i miljön där funnelfrågorna faktiskt finns och landa allt du behöver utöver 24 timmar i en nedströmstabell. Det är en liten del av modelleringen i utbyte mot att ett ömtåligt ögonblicksbildsjobb tas bort, och det är en byteshandel som de flesta team gärna accepterar.
Varför är CRM-datakvalitet viktig när rapporteringen ligger så här nära?
CRM-datakvalitet är viktig eftersom varje nedströmsnummer ärver den. När analyslagret är en anpassad version tenderar dålig data att repareras i tysthet under transporten, och rensningslogiken blir den verkliga affärsdefinitionen utan att någon bestämmer att den ska göra det. Länk till Fabric förkortar avståndet: den replikerar de tabeller du väljer till Delta Parquet, rapporter läser det och stegvisa uppdateringar visas vanligtvis inom en timme. Så en scenrepresentant som hoppar över eller ett ägarfält som lämnas tomt når forumet samma morgon. Den omedelbarheten är fördelen. Den omvandlar datakvalitet från en osynlig skatt till något som är tillräckligt synligt för att åtgärdas.
Ännu bättre är att förberedelserna som det belönar är arbete värt att göra ändå. Ändringsspårning måste vara aktiverad för att en tabell ska synkroniseras, vilket är en användbar inventering av vad organisationen faktiskt anser vara en intressant post. Fältdisciplin lönar sig dubbelt, eftersom schemareglerna här är tydliga och enkla att utforma kring: att lägga till en kolumn stöds och tar upp till en timme att sprida, att ta bort en skickar nullvärden vidare snarare än att ta bort den, och att ändra en kolumns datatyp eller precision stöds inte, så tabellen behöver tas bort och läggas till igen. Godkänn era typer en gång så fortsätter synkroniseringen helt enkelt att köras.
Vad bör du ställa in först, och hur mäter du avkastningen?
Det finns en kort, konkret lista för den kommande veckan. Kontrollera om din länk redan innehåller Låg latensläge flagga. Bekräfta att du har Fabric-kapacitet i samma Azure-geografi som Dataverse-miljön, vilket är ett krav och, för europeiska organisationer som bevakar digital suveränitet, ett bra sådant, eftersom analysrepliken finns kvar i regionen. Flytta anslutningen till arbetsytans identitet. Trimma sedan tabellistan. Om du länkar om en befintlig profil för att hämta den nya motorn är det fyra skillnader som förtjänar att titta närmare på först: tidsstämplar skrivs som INT64 snarare än INT96, tomma strängar bevaras istället för att bli nullvärden, borttagningsvektorer innebär att Synapse serverlösa SQL-arbetsbelastningar ska flyttas till Fabric SQL-analysslutpunkten och långsiktigt lagrade data visas inte via genvägar förrän Microsoft har slutfört sin migrering. Återlänkning utlöser en fullständig initial synkronisering, så boka in det för en lugn helg.
Att mäta CRM-ROI på en förändring som denna fungerar bäst när man baslinjebedömer innan man länkar. De ärliga måtten är beslutslatens, hur lång tid det tar att besvara en pipeline-fråga, och förtroende, hur många rapporter en ledare läser utan att kontrollera antalet i applikationen igen. Båda förbättras snabbt här och båda är lätta att fånga upp nu. Det är också här en oberoende CRM-partner förtjänar sin plats. En oberoende partner arbetar över flera plattformar och får betalt för resultatet snarare än licensen, så råd om vad som ska synkroniseras, vad som ska tas bort och om analyslagret alls hör hemma i Fabric kommer utan en leverantörskarta bifogad. Vid ett beslut som omfattar Dynamics 365, Dataverse, Fabric och vad som redan driver din rapportering, är den neutraliteten det praktiska värdet.
Siroccos perspektiv
Vi arbetar med Salesforce, HubSpot och Dynamics 365, och det som slår oss med den här releasen är hur mycket av det som är vanlig god praxis och som äntligen blir standard. Nyckellös autentisering istället för en roterande hemlighet. En avsiktlig tabelllista istället för allting. Ändringshistorik från plattformen istället för ett jobb som någon har skrivit och ingen äger. Våra kunder som får ut mest av Link to Fabric är de som lägger två veckor på tabellvalet och fältdefinitionerna innan de bygger en enda rapport, eftersom de två veckorna också förbättrar routing, ägarskap och prognoser i själva CRM-systemet. Om du redan har läst vår anteckning om hur Microsofts automatiserade CRM-identifiering, detta är samma rörelse som når datalagret: inventering först, sedan beslut, sedan byggande.
Inriktningen här är uppmuntrande. Rapporteringsskiktet under Dynamics 365 håller på att bli något du konfigurerar och styr snarare än något du utvecklar och försvarar, och det ger fördelen till organisationer med tydliga definitioner och tydligt ägarskap. Om du vill ha en andra åsikt om vilka tabeller som hör hemma i ditt hus, eller om Fabric är rätt plats för din CRM-rapportering överhuvudtaget, diskuterar vi gärna igenom det. Boka en konsultation och vi börjar med det du redan har.
Kontakta oss
Om du funderar på vilka Dynamics 365-tabeller som hör hemma i Fabric, eller om din CRM-rapportering ska finnas där överhuvudtaget, tittar vi gärna på det tillsammans med dig.
