Power BI + Dynamics 365 Sales: Dashboards That Actually Get Used

Power BI + Dynamics 365 Sales: Dashboards That Actually Get Used

Across the projects we have been part of, a recurring pattern stands out: many Power BI dashboards built for D365 Sales stop being opened after the first two weeks.

It's not because they're ugly, or because the numbers are wrong. It's because they answer questions nobody asked, or they answer the right questions in a format that doesn't fit the recipient's working day.

This article is about how you build Power BI reports against D365 Sales that actually get used, and how to recognise a dashboard that won't.

Power BI vs built-in D365 dashboards: when is which enough?

D365 Sales has built-in dashboards. They're free, require no additional licensing, and can be set up without Power BI.

When are they enough?

• For operational views users see daily ("my open opportunities", "this week's activities", "leads assigned to me"), D365's own dashboards are more than enough. Power BI is overkill here.
• For cross-entity analysis ("which customer types convert best from which campaigns?") and forecast and trend ("how well does pipeline weight match actual closed revenue?"): that's where Power BI has a clear edge.
• For CFO and board level, where the leader wants financial aggregates across sales, marketing, and possibly ERP, Power BI is almost always the right choice.

The common mistake is to use Power BI for everything. Or use nothing for anything. The middle ground (D365 dashboards for daily operations, Power BI for analysis) works better.

Different roles, different dashboards: who reads what?

The first question to ask before designing your D365 Sales reporting isn't "what data do we have?", but "who reads this, and when?"

We've seen four audience groups with radically different needs:

The salesperson wants to see:

• Their own open opportunities sorted by weight and expected close
• Their planned activities this week
• Their pipeline against quota

This isn't a "dashboard" in the classical sense. It's a working surface. It's opened multiple times per day, preferably on mobile. Power BI is often too heavy here; D365's own views are usually better.

Best tool: D365 personal views or standard sales dashboard.

The sales manager wants to see:

• Pipeline health across the team (volume, age, weight)
• Forecast accuracy over time
• Activity level per salesperson
• Conversion by stage

This is classic Power BI territory. It's opened weekly, or before sales meetings. It drives conversations ("why doesn't Per have any activities this week?", "why do we have 12 deals stuck in negotiation for 60 days?").

Best tool: Power BI with planlagt oppdatering.

The CFO wants to see:

• Expected revenue per month/quarter
• Prognose mot faktisk resultat over time
• Pipeline conversion in currency
• Customer Acquisition Cost vs Customer Lifetime Value, if the data exists

This is financially aggregated. It often requires cross-linking with ERP, which is the classic bridge case for Power BI.

Best tool: Power BI on Microsoft Fabric or data warehouse.

CEO/board wants to see:

• A handful of KPIs, not an analysis
• Trend over quarter and year
• Variance from plan

This is the simplest dashboard, not the most complex. One page. Ten numbers. One graph. No filters.

Best tool: One Power BI report, delivered automatically by email or embedded in Teams.

A single Power BI report trying to cover all four audiences rarely gets used by any of them. Sales analytics that actually drives decisions almost always splits by role.

Summary: D365 sales dashboard by role

The data model underneath Power BI + Dynamics 365

Power BI is only as good as the data model it reads from.

Three connection approaches to D365:

1. DirectQuery against Dataverse. Real time, but performance depends on query complexity. Good for small datasets and when real time matters. Less good for complex aggregations.

2. Import mode with planlagt oppdatering. Power BI pulls a copy of the data typically nightly. Best performance, but data is never 100% live.

3. Fra Dataverse til Microsoft Fabric. The modern approach for organisations wanting D365 data plus data from other systems (ERP, marketing) in the same sentral dataplattform (lakehouse). More work to set up, but most flexibility long-term.

For SMBs, Import mode with daily refresh is almost always right. For organisations with multiple data sources and long-term analytics needs, Fabric often becomes the most flexible architecture. (The data-foundation topic is also covered in CRM is not a master register.)

What makes a dashboard actually get used?

Three principles we've seen work:

1. It answers a specific question the recipient actually asks themselves.

Not "Sales Overview". That's too vague. Rather "Which deals are at risk this month?" or "How many leads convert from each campaign, and what's the CAC?". A dashboard answering one concrete question is used substantially more often than one covering ten vague ones.

2. It's delivered where the recipient already is.

The sales manager doesn't read the Power BI portal daily. They read Teams. A Power BI tile pinned in a Teams channel, or an automatic PDF in their inbox every Monday morning, dramatically increases actual use.

3. It invites action, not just observation.

"Pipeline weight: 14M NOK" is observation. "12 deals over 6 months old without recent activity" is action. The second generates a conversation, a follow-up, a decision. The first becomes a confirmation number.

Power BI building vs configuring

Power BI out of the box can do a lot without code. For an SMB CRM dashboard there's rarely need for DAX magic.

What requires more work:

• Forecast models that don't just sum pipeline weight but pull in historical conversion rates by stage and salesperson.
• Cohort analysis of customers over time.
• Power BI Embedded in a customer portal or external system.
• Row-level security where different salespeople see different data.

For 80% of organisations, "out of the box + some custom visuals" is enough. It's rarely Power BI complexity that's the bottleneck. It's data quality underneath. (See Dynamics 365 and Power Platform overview for the broader platform context.)

Mobile, sharing and distribution

The D365 mobile app is primarily for the salesperson's daily use. It works for logging a call, viewing a contact, updating a deal, not for reading a report.

The Power BI mobile app, on the other hand, works surprisingly well for weekly checks. A sales manager can see pipeline health on the train home from a meeting.

Distribution tips we've seen work:

• Pin one dashboard per role in Teams. Sales leader has theirs; CFO has theirs.
• Automate weekly email with snapshot. Monday 07:00, summary of the previous week.
• Keep the Power BI app open on a screen in the sales office. If the physical office exists.

Governance: how to avoid the report jungle

Power BI estates tend to grow. A pattern we see frequently: after 12 months, many organisations end up with 20-50 reports across several workspaces, and unclear rules for who can change what.

It pays to set up early:

• Workspace structure per department or function. Not all dashboards in the same workspace.
• Authoritative datasets. When the data owner says "this is the official revenue model", that's the one other reports should build on.
• Lifecycle ownership. Who removes a report nobody has opened in 90 days?

A CRM Power BI project that doesn't plan for governance from day one often ends in a wild west of reports after 18 months.

Pattern: A recurring observation across Power BI engagements: only a small fraction of the dashboards built over the first year, often the ones tied to a specific decision a specific person makes, get used regularly. The rest are not technically broken; they simply do not match a decision someone is actually making. The visible cost is licensing and engineering time. The quieter cost is the credibility of the BI function.

Realistic delivery timelines and effort

For an SMB on D365 Sales, a good Power BI dashboard project:

• 4-8 weeks from start to go-live
• 2-5 dashboards covering the four audience groups
• D365 data quality cleanup as a prerequisite (often 1-2 weeks in itself)
• Follow-up rounds 30 and 60 days after to adjust what wasn't used

Successful projects have fewer dashboards being used more. Long backlog projects with 15 dashboards often have 2-3 that are actually lived with.

When Power BI is the wrong tool

There are situations where Power BI is over-dimensioned:

• A team of 3-5 people where D365's own dashboards and Excel export are enough
• When data structure changes often and reports have to follow
• When the real problem is data quality, not visualisation: Power BI just makes bad data faster to see

And situations where Power BI is under-dimensioned:

• Large data aggregation across D365, ERP, marketing automation, external sources: Microsoft Fabric or a dedicated data warehouse solution fits better
• Complex statistical models: Python or R outside Power BI gives more flexibility
• Real-time ML-based predictions: requires Azure ML or similar, not Power BI alone

Conclusion

A Power BI dashboard isn't valuable because it's pretty. It's valuable when someone actually opens it, often, and does something differently as a result of what they saw.

That requires knowing who the recipient is, what they ask themselves, where they already read their information, and what generates action from them. Everything else (connector, data model, DAX) is mostly technically feasible.

D365 Sales provides the data. Power BI makes it usable. The design and context work decide whether it gets used.

---