Power BI + Dynamics 365 Sales: Dashboardene som faktisk brukes

På tvers av prosjekter vi har vært en del av, ser vi et tilbakevendende mønster: mange Power BI-dashboards bygd for D365 Sales slutter å bli åpnet etter de første to ukene.

Det er ikke fordi de er stygge, eller fordi tallene er feil. Det er fordi de svarer på spørsmål ingen stilte — eller fordi de svarer på riktige spørsmål, men i et format som ikke passer inn i mottakerens hverdag.

Denne artikkelen handler om hvordan du bygger Power BI-rapporter mot D365 Sales som faktisk blir brukt — og hvordan du gjenkjenner et dashboard som ikke vil bli det.

Power BI vs innebygde D365-dashboards — når er hva nok?

D365 Sales har innebygde dashboards. De er gratis, krever ingen ekstra lisens, og kan settes opp uten Power BI.

Når er de nok?

For operasjonelle visninger brukerne ser daglig — "mine åpne opportunities", "denne ukens aktiviteter", "leads tildelt meg" — er D365 sine egne dashboards mer enn nok. Power BI er overkill her.
For analyse på tvers av kunde-, kontakt- og salgsdata ("hva slags kunder konverterer best fra hvilke kampanjer?") og prognoser og trender ("hvor godt forhold mellom pipeline-vekt og faktisk bokført omsetning?") — der har Power BI tydelig fortrinn.
For CFO- og styrenivå — der lederen vil se finansielle aggregater på tvers av salg, marketing, og kanskje ERP — er Power BI nesten alltid det riktige valget.

Den vanlige feilen er å bruke Power BI til alt. Eller å bruke ingenting til noe. Mellomgrunnen — D365-dashboards for daglig drift, Power BI for analyse — fungerer bedre.

Ulike roller, ulike dashboards — hvem leser hva?

Det første spørsmålet å stille før du designer Dynamics 365 Sales-rapporteringen er ikke "hvilke data har vi?" — det er "hvem leser dette, og når?"

Vi har sett fire mottakergrupper med radikalt ulike behov:

Selgeren vil se:

Sine egne åpne opportunities sortert etter vekt og forventet avslutning
Sine planlagte aktiviteter denne uken
Sin pipeline mot kvote

Dette er ikke et "dashboard" i klassisk forstand — det er en arbeidsflate. Den åpnes flere ganger per dag, helst på mobil. Power BI er ofte for tungt her; D365 sine egne visninger er som regel bedre.

Best verktøy: D365 personlige visninger eller standard salgsdashboard.

Selger-arbeidsflate: pipeline mot kvote, åpne opportunities, top 5 deals og dagens aktiviteter — det selgeren faktisk åpner flere ganger om dagen.

Salgssjefen vil se:

Pipeline-helse på tvers av teamet (mengde, alder, vekt)
Forecast-treffsikkerhet over tid
Aktivitetsnivå per selger
Konvertering per stadium

Dette er klassisk Power BI-terreng. Det åpnes ukentlig, eller før salgsmøter. Det driver samtaler ("hvorfor har Per ingen aktiviteter denne uken?", "hvorfor har vi 12 deals i forhandlingsfasen siste 60 dager?").

Best verktøy: Power BI med planlagt oppdatering.

Salgssjef-dashboard: pipeline-helse per fase, win-rate per selger og deals over 60 dager — driver coaching-samtaler ukentlig.

CFOen vil se:

Forventet revenue per måned/kvartal
Prognose mot faktisk resultat over tid
Pipeline-konvertering i kroner
Customer Acquisition Cost vs. Customer Lifetime Value, hvis dataene er der

Dette er finansielt aggregert. Det krever ofte krysskobling mot ERP — som er den klassiske bro-saken for Power BI.

Best verktøy: Power BI mot Microsoft Fabric eller datawarehouse.

CFO-dashboard: forecast vs actual over 12 måneder, CAC og CLV/CAC-ratio, revenue per segment — finansielt aggregat på tvers av D365 og ERP.

CEO/styret vil se:

Et håndfull KPI-er, ikke en analyse
Trend over kvartal og år
Avvik fra plan

Dette er det enkleste, ikke det mest komplekse, dashboardet. Det er én side. Ti tall. En graf. Ingen filtre.

Best verktøy: Én Power BI-rapport, levert automatisk på e-post eller innebygd i Teams.

CEO/styre-rapport: ti topplinjer på én side, kvartal-trend over fire år — én autoritativ rapport, levert månedlig.

En enkelt Power BI-rapport som skal dekke alle fire grupper, blir sjelden brukt av noen av dem. Sales analytics som faktisk driver beslutninger splittes nesten alltid per rolle.

Oppsummering: D365 sales dashboard per rolle

Selger

Flere ganger daglig

Best verktøy: D365 personlig visning

Primær beslutning: Hvilke deals å følge opp i dag

Salgssjef

Ukentlig

Best verktøy: Power BI planlagt oppdatering

Primær beslutning: Hvor er salgsarbeidet i ferd med å stoppe opp

CFO

Månedlig

Best verktøy: Power BI + ERP-data

Primær beslutning: Hva kan vi realistisk forvente neste kvartal

CEO / styret

Kvartalsvis

Best verktøy: Én Power BI-rapport, innebygd i Teams

Primær beslutning: Er vi på vei mot målene våre?

Dashboard-pyramide: ulike nivåer i organisasjonen trenger ulike dashboards, men de skal alle bygge på samme datamodell.

Datamodellen under Power BI + Dynamics 365

Power BI er bare så god som datamodellen den leser fra.

Tre tilkoblings-tilnærminger til D365:

1. DirectQuery mot Dataverse. Sanntid, men ytelsen avhenger av spørringskompleksitet. Bra for små datasett og når sanntid betyr noe. Mindre bra for komplekse aggregater.

2. Import-modus med planlagt oppdatering. Power BI henter en kopi av dataene typisk hver natt. Best ytelse, men data er aldri 100 % live.

3. Dataverse → Microsoft Fabric. Den moderne tilnærmingen for organisasjoner som vil ha både D365-data og data fra andre systemer (ERP, marketing) i samme lakehouse. Mer arbeid å sette opp, men gir mest fleksibilitet langsiktig.

For de fleste SMB-er gir importmodus med daglig oppdatering den beste kombinasjonen av ytelse, kostnad og enkel drift. For organisasjoner med flere datakilder og langsiktige analysebehov blir Fabric ofte den mest fleksible arkitekturen. (Datafundament-tematikken dekkes også i CRM er ikke et masterregister.)

"Et dashboard ingen åpner er den dyreste BI-investeringen en organisasjon kan gjøre. Det koster lisens, data-engineering-tid, vedlikehold over tid, og troverdigheten til den som foreslo det. Det vanskelige med Power BI er ikke å bygge rapporter. Det er å sikre at de riktige blir brukt."
— Cartagena, fra praksis med Power BI- og D365-leveranser

Hva som gjør at et dashboard faktisk blir brukt?

Tre prinsipper vi har sett fungere:

1. Det svarer på et spesifikt spørsmål mottakeren faktisk stiller seg.

Ikke "Sales Overview". Det er for vagt. Heller "Hvilke deals er i fare denne måneden?" eller "Hvor mange leads konverterer fra hver kampanje, og hva er CAC?". Et dashboard som svarer på ett konkret spørsmål blir betydelig oftere brukt enn ett som dekker ti vage.

2. Det levereres der mottakeren allerede er.

De fleste salgssjefer tilbringer dagen i Teams, Outlook og møter — Power BI-portalen er sjelden første tilgangspunkt. Et Power BI-tile pinnet i en Teams-kanal, eller en automatisk PDF-rapport i innboks hver mandag morgen, øker faktisk bruk dramatisk.

3. Det inviterer handling, ikke bare observasjon.

"Pipeline-vekt: 14M NOK" er observasjon. "12 deals over 6 mnd gamle uten siste aktivitet" er handling. Den andre genererer en samtale, en oppfølging, en beslutning. Den første blir bekreftelse-tall.

Power BI-bygging vs. konfigurering

Power BI ut av boksen kan veldig mye uten kode. For et SMB-CRM-dashboard er det sjelden behov for DAX-magi.

Det som krever mer arbeid:

Forecast-modeller som ikke bare summerer pipeline-vekt, men trekker inn historisk konverteringsrate per stadium og selger.
Cohort-analyse av kunder over tid.
Power BI Embedded i en kunde-portal eller eksternt system.
Row-level security der ulike selgere ser ulike data.

For 80 % av organisasjoner er "ut av boksen + noen tilpassede visualer" nok. Det er sjelden Power BI-kompleksiteten som er flaskehalsen — det er data-kvaliteten under. (Se Dynamics 365 og Power Platform-oversikt for større plattform-konteksten.)

Mobil, deling og distribusjon

D365-mobilappen er primært for selgerens daglige bruk. Den fungerer for å logge en samtale, se en kontakt, oppdatere en deal — ikke for å lese en rapport.

Power BI-mobilappen, derimot, fungerer overraskende godt for ukentlig sjekk. En salgssjef kan se pipeline-helse på toget hjem fra et møte.

Distribusjon-tips som vi har sett virke:

Pinn ett dashboard per rolle i Teams. Salgssjef har sitt; CFO har sitt.
Automatiser ukentlig e-post med snapshot. Mandag 07:00, sammendrag av forrige uke.
Hold Power BI-appen åpen på en skjerm i salgskontoret. Hvis det fysiske kontoret eksisterer.

Governance — hvordan dere unngår rapport-jungelen

Power BI-miljøet vokser ofte. Et mønster vi ser jevnlig: etter 12 måneder har mange organisasjoner endt opp med 20-50 rapporter på tvers av flere workspaces, og uklare regler for hvem som kan endre hva.

Det betaler seg å sette opp tidlig:

Workspace-struktur per avdeling eller funksjon. Ikke alle dashboards i samme workspace.
Autoritative datasett. Når data-eier sier "dette er den offisielle revenue-modellen", er det den andre rapporter skal bygges på.
Lifecycle-ansvar. Hvem fjerner en rapport som ingen åpner på 90 dager?

Et CRM-Power-BI-prosjekt som ikke planlegger for governance fra dag én ender ofte med en et uoversiktlig rapportlandskap etter 18 måneder.

Mønster: En tilbakevendende observasjon fra Power BI-prosjekter: bare en liten andel av dashboardene som blir bygd i løpet av første år — ofte de som er knyttet til en konkret beslutning en konkret person tar — blir brukt jevnlig. Resten er ikke teknisk ødelagt; de matcher bare ikke en beslutning noen faktisk tar. Den synlige kostnaden er lisens og engineering-tid. Den stille kostnaden er troverdigheten til BI-funksjonen.

Realistiske leveranse-rammer og innsats

For en SMB med D365 Sales, et godt Power BI-dashboard-prosjekt:

4-8 uker fra start til go-live
2-5 dashboards som dekker de fire mottakergruppene
datavask og kvalitetssikring i D365 som forutsetning (ofte 1-2 uker i seg selv)
oppfølgingsrunder 30 og 60 dager etter for å justere det som ikke ble brukt

Vellykkede prosjekter har færre dashboards som brukes mer. Lange backlog-prosjekter med 15 dashboards har ofte 2-3 som faktisk leves med.

Når Power BI er feil verktøy

Det finnes situasjoner der Power BI er overdimensjonert:

Et team på 3-5 personer der D365 sine egne dashboards og Excel-eksport er nok
Når dataene endrer struktur ofte og rapportene må følge med
Når det reelle problemet er datakvalitet, ikke visualisering — Power BI vil bare gjøre dårlige data raskere synlige

Og situasjoner der Power BI er underdimensjonert:

Stort dataaggregat på tvers av D365, ERP, marketing-automation, eksterne kilder — Microsoft Fabric eller en dedikert datawarehouse-løsning passer bedre
Komplekse statistiske modeller — Python eller R utenfor Power BI gir mer fleksibilitet
Sanntids-ML-baserte spådommer — krever Azure ML eller lignende, ikke Power BI alene

Ofte stilte spørsmål om Power BI og Dynamics 365

Trenger jeg Power BI hvis vi allerede har Dynamics 365 Sales?

Det kommer an på hvilken type rapportering dere trenger. De innebygde D365-dashboardene dekker daglige operasjonelle spørsmål for selgere og salgssjefer. Når dere trenger å kombinere data på tvers av kilder, lage komplekse beregninger, eller distribuere rapporter til personer uten D365-lisens, blir Power BI nødvendig.

Er Power BI inkludert i Dynamics 365-lisensen?

Power BI er ikke inkludert i Dynamics 365-lisensen som standard. Muligheten til å vise Power BI-innhold i Dynamics 365 avhenger av lisensmodell og distribusjonsmåte — i de fleste tilfeller kreves Power BI Pro eller en Premium/Fabric-kapasitet. For å bygge eller eie rapporter trengs Power BI Pro (per bruker per måned). Hvis dere distribuerer rapporter bredt utenfor Dynamics 365, lønner det seg ofte med Power BI Premium kapasitets-lisens.

Hvordan koble Power BI til Dynamics 365 Sales-data?

Den enkleste veien er Microsofts Dataverse-connector i Power BI Desktop — den eksponerer alle D365-tabeller direkte. For mer komplekse modeller eller når dere trenger historiske snapshots, eksporteres data først til Dataverse Synapse Link eller Azure Data Lake, og Power BI peker på det. Det er den anbefalte arkitekturen ved stor data-volum.

Hvor mange Power BI-rapporter er for mange?

Det er ingen hard grense, men når dere passerer 20–25 aktive rapporter uten et eierskaps- og review-regime, begynner ting å rote seg til. Et nyttig signal: hvis det tar mer enn 30 sekunder for noen å finne rapporten de skal bruke, er det for mange — eller rapportene er ikke kategorisert riktig.

Hva er forskjellen mellom et dashboard og en rapport i Power BI?

I Power BI-terminologi er en rapport en samling av sider med interaktive visualiseringer bygget på én datamodell. Et dashboard er et samlet pin-board av tiles fra én eller flere rapporter, optimalisert for én skjerm. I praksis brukes ordene om hverandre, men teknisk er rapporten der analysen lever — dashboardet er der sammendraget viser seg.

Hvor mye koster det å bygge et godt Power BI-dashboard mot D365?

For ett godt dashboard på toppen av ren D365-data ligger en realistisk leveranse mellom 30 og 80 timer, avhengig av kompleksitet i beregninger og hvor mange visualiseringer som inngår. Det inkluderer datamodell, design-iterasjon med brukere, og første runde governance-konfigurasjon. Et dashboard som koster mindre er ofte bygd uten å snakke med brukerne — som er den vanligste grunnen til at det ikke åpnes senere.

Konklusjon

Et Power BI-dashboard er ikke verdifullt fordi det er pent. Det er verdifullt når noen faktisk åpner det, ofte, og gjør noe annerledes som følge av det de så.

Det krever at du vet hvem mottakeren er, hva de stiller seg av spørsmål, hvor de allerede leser sin info, og hva som genererer en handling fra dem. Alt det andre — connector, datamodell, DAX — er teknisk gjennomførbart for det meste.

D365 Sales gir dataene. Power BI gjør dem brukbare. Designet og kontekst-arbeidet er det som avgjør om de blir brukt.

De fleste organisasjoner trenger ikke 20 dashboards. De trenger 3-5 som matcher beslutninger noen faktisk tar.

Vi hjelper med å kartlegge hvilke beslutninger som faktisk trenger dashboard-støtte — og bygger de som blir åpnet. Resten lever som ad-hoc Power BI-spørringer, ikke som rapport-jungel.

Ta kontakt

---

Power BI + Dynamics 365 Sales: Dashboardene som faktisk brukes