Microsoft Fabric for Dynamics 365 og CRM: dataplattformen under analysen

Microsoft Fabric for Dynamics 365 og CRM: dataplattformen under analysen

Når ledelsen ser på et Power BI-dashboard, ser de toppen av en stabel. Tallene er bare det øverste laget. Under ligger spørsmålet som avgjør om analysen er til å stole på: hvor kommer dataene fra, og hvordan kom de dit?

For organisasjoner på Dynamics 365 har svaret historisk vært en blanding av eksporter, Synapse Link, datavarehus og integrasjoner noen bygde for noen år siden. Microsoft Fabric er Microsofts forsøk på å samle dette i ett lag — med OneLake som felles datasjø under hele Power Platform-stacken.

Denne artikkelen forklarer hva Fabric faktisk er, hvordan Dynamics 365-data kobles til det uten ETL, hva det koster, og — viktigst — når det lønner seg og når det ikke gjør det.

Hva er Microsoft Fabric — og hvordan henger det sammen med Dynamics 365?

Microsoft Fabric er en samlet analyseplattform som binder sammen datateknikk, datavarehus, sanntidsanalyse, datavitenskap og Power BI i én tjeneste. Kjernen er OneLake: én logisk datasjø for hele organisasjonen, der alle data lagres i åpent Delta-Parquet-format i stedet for i hver sin silo.

Poenget er ikke å erstatte Dynamics 365 eller Dataverse. Dynamics forblir systemet der data oppstår. Fabric er laget der data fra mange kilder samles, foredles og gjøres klart for analyse og AI. Power BI er fortsatt vinduet de fleste ser inn gjennom — men i Fabric leser det fra et felles fundament, ikke fra en kopi ingen helt vet alderen på.

Slik kobler Dataverse seg til Fabric — uten ETL

Den viktigste endringen for D365-kunder er koblingen mellom Dataverse og Fabric. Med noen få klikk — enten fra Power Apps' maker-portal eller fra Fabric — opprettes en snarvei (shortcut) i OneLake som peker rett på Dataverse-tabellene dine.

Det spesielle er hva som ikke skjer: ingen eksport, ingen ETL-pipeline, ingen tredjeparts-integrasjonsverktøy. Tabellene dukker opp i et Fabric-lakehouse som om de var kopiert dit, men det er en referanse til der dataene faktisk ligger i Dataverse. Data eksponeres i Delta-Parquet-format, som alle Fabric-arbeidslaster forstår — så du kan analysere dem med Spark, SQL og Power BI uten transformasjon.

To ting er verdt å merke seg. Snarveiene er skrivebeskyttet — Fabric leser fra Dataverse, men skriver ikke tilbake (det beskytter kildesystemet, og er i tråd med prinsippet om at masterdata foredles, ikke endres vilkårlig). Og for kilder utenfor Dataverse kan Fabric Mirroring speile data fra eksisterende systemer kontinuerlig inn i OneLake med lav forsinkelse.

Hva det ser ut som i praksis for Dynamics 365

Det abstrakte blir konkret når du ser hva som faktisk kobles sammen. To mønstre vi møter ofte hos Dynamics 365-kunder:

Salg + økonomi + marked i én modell

Salgsdata fra Dynamics 365 Sales kombinert med økonomidata fra Business Central, markedsføringsdata fra en ekstern plattform (for eksempel HubSpot) og webtrafikk fra GA4 — i samme analysemodell. Selgerne ser salgspipeline i CRM og økonomi ser fakturering i ERP, men ledelsen vil se ordreinngang, margin og pipeline i én rapport. Fabric samler kildene i OneLake og gjør dem tilgjengelige som én modell — uten at noen av kildesystemene endres.

Service + ERP + sensordata for prediktivt vedlikehold

Servicehistorikk fra Dynamics 365 Customer Service kombinert med ERP-data, IoT-/sensordata og garantidata. Sammen gir det grunnlag for å forutse feil før de skjer — ikke bare rapportere dem etterpå. Ingen av kildene alene er nok; verdien ligger i å lese dem sammen.

Direct Lake, import eller DirectQuery: hvordan Power BI leser fra Fabric

Når data ligger i OneLake, kan Power BI lese dem på tre måter. Valget avgjør både ferskhet og ytelse.

• Import. Data kopieres inn i Power BI-modellen. Raskest spørringer, men krever planlagt oppdatering — tallene er så ferske som siste oppdatering.
• DirectQuery. Power BI spør kilden live ved hver visning. Alltid ferskt, men tyngre på ytelse ved store volum.
• Direct Lake. Den nye, Fabric-spesifikke modusen: Power BI leser Delta-tabellene i OneLake direkte, uten import og uten den klassiske DirectQuery-straffen. Du får tilnærmet import-ytelse med tilnærmet sanntids-ferskhet — forutsatt at du har kapasiteten som kreves.

Direct Lake er grunnen til at mange vurderer Fabric i det hele tatt. Men den forutsetter en Fabric-kapasitet, og mange som vil ha Direct Lake i produksjon starter vurderingen rundt F64-nivået — sammen med flere samtidige brukere og datapipelines.

Hva Fabric koster — og hvor F64-terskelen ligger

Fabric kjøpes som kapasitet, ikke per bruker. Kapasiteten måles i F-SKU-er. Veiledende listepriser i 2026: F2 starter rundt 263 USD per måned, mens F64 ligger rundt 5 257 USD per måned (priser varierer med region og avtale).

F64 er terskelen som betyr mest. På F64 eller større kan brukere med kun en gratis Power BI-lisens (og leser-rolle) se Power BI-innhold — under F64 må hver leser ha Power BI Pro. F64 er også nivået mange starter vurderingen rundt for Direct Lake og flere samtidige brukere. For en organisasjon som skal distribuere rapporter bredt, er regnestykket ofte F64-kapasitet mot summen av Pro-lisenser.

Med andre ord: den reelle Fabric-beslutningen handler sjelden om F2 mot F4. Den handler om man trenger F64-laget eller ikke — og det avhenger av hvor mange som skal lese, og om man vil ha Direct Lake.

Mønster: En mellomstor organisasjon med rundt 120 Power BI-lesere hadde Pro-lisens på alle. Da de regnet på det, lå den årlige Pro-kostnaden nær en F64-kapasitet — men F64 ga dem også Direct Lake, OneLake og rom for datapipelines på kjøpet. Poenget var ikke at Fabric var gratis; det var at de allerede betalte for halve plattformen uten å få resten.

Når Fabric er riktig for Dynamics 365 — og når det ikke er det

Fabric er ikke et standardvalg for enhver D365-kunde. For en mindre organisasjon som bare trenger noen dashboards på ren D365-data, er Dataverse-connectoren i Power BI fortsatt den enkleste og rimeligste veien — og helt tilstrekkelig.

Fabric begynner å lønne seg når:

• dere kombinerer Dynamics 365 med data fra ERP, web, økonomisystem eller andre kilder i samme analyse
• datavolumet eller historikken er for stort til å importere komfortabelt i Power BI
• mange skal lese rapporter, og F64-laget med gratis lesere blir billigere enn Pro til alle
• dere bygger mot AI og agentisk CRM, der modellene trenger ett pålitelig datafundament
• dere vil bort fra eldre Synapse Link-eksporter og spredte kopier

Og den motsatte testen er like viktig: hvis dere ikke kan svare på hvilke beslutninger den samlede dataplattformen skal støtte, er Fabric et infrastrukturprosjekt på jakt etter et formål. Da bør dere vente.

Fabric som fundament for AI og agentisk CRM

Den strategiske grunnen til å bygge på Fabric nå er ikke rapportering — det er det som kommer etter. Agentiske AI-funksjoner i Dynamics 365 og Copilot leser fra data for å foreslå og handle. En agent som leser fra rotete, motstridende data tar rotete beslutninger — bare raskere og i større skala.

Et felles datafundament i OneLake — med Dataverse som kilde og et tynt foredlingslag over — er forutsetningen for at AI på toppen skal være til å stole på. Fabric er ikke AI. Men det er gulvet AI-en står på.

Konklusjon

Power BI viser tallene. Fabric og OneLake avgjør om tallene er verdt å vise. For D365-kunder er den gode nyheten at koblingen er enklere enn før: Dataverse lenker rett inn i Fabric, uten ETL. Den vanskelige delen er ikke teknisk — det er å vite hvilke data som skal samles, hvem som skal lese dem, og hvilke beslutninger de skal bære.