Cloud Engineer Lab
Cloud Engineer Lab
Cloud Engineer Lab
Cloud Engineer Lab
© 2026
Build Your First Intune Power BI Dashboard Using OData

Build Your First Intune Power BI Dashboard Using OData

Not another 'what is Power BI' post. The full journey from the Intune Data Warehouse to a published dashboard, with real entities, relationships, and DAX.

9 min read
Share

Automating an Intune compliance report with PowerShell and Graph is one way to turn raw device data into something a manager can actually read. This is the other one, and it's the one built for genuine self-service reporting: connect Power BI directly to Intune's own reporting data store and build a real dashboard, not a static export.

text
Microsoft Intune

Intune Data Warehouse

OData Feed

Power BI Desktop

Power Query

Data Model

Relationships

DAX

Dashboard

Power BI Service

Stage 1-2: Microsoft Intune and the Intune Data Warehouse

Power BI never connects to live Intune operational data directly. It connects to the Intune Data Warehouse, a separate, reporting-optimised copy of that data, refreshed on its own schedule, specifically so heavy analytical queries never compete with the actual MDM service managing real devices.

Open the Intune admin centre

Navigate to Reports → Data warehouse.

Copy the OData feed URL

This page shows the tenant-specific feed URL. Copy it, you'll paste this directly into Power BI in a moment.

Confirm you have the right role

Reading from the data warehouse requires an account with sufficient Intune RBAC permissions (an Intune administrator role, at minimum read access to devices and reports). A account without this will authenticate successfully but see no data.

This is not real-time data

The warehouse refreshes on its own cycle, not continuously. A device that enrolled ten minutes ago won't necessarily show up yet. Build dashboards for trends and posture, not for "what's happening right this second," that's what the Intune admin centre itself is for.


Stage 3: The OData Feed and What's Actually in It

OData is a REST-based protocol for querying data over HTTP, and the Intune Data Warehouse exposes its schema as a set of queryable entities. The ones that matter for this dashboard:

EntityWhat it holds
devicesOne row per managed device: platform, OS version, manufacturer, model, compliance state, enrollment date
datesA standard date dimension table, used to build any time-based trend
ownerTypesCorporate vs personal ownership classification
enrollmentsEnrollment events, including enrollment type and timestamp
deviceCompliancePolicyStatesPer-device, per-policy compliance results

Exact column names vary by tenant and API version

Microsoft occasionally revises the warehouse schema. Treat the entity and column names above as a map of what to look for, not a literal copy-paste reference, and check the actual field list in Power Query once you're connected.


Stage 4: Power BI Desktop

Get Data → OData Feed

In Power BI Desktop's ribbon, Home → Get Data → OData Feed.

Paste the feed URL

Paste the URL copied from the Intune admin centre.

Sign in with an Organizational account

Choose Organizational account at the authentication prompt, not anonymous or a Microsoft account, and sign in with the account that has the RBAC role confirmed in Stage 2.

Select the entities you actually need

In the Navigator window, tick devices, dates, ownerTypes, enrollments, and deviceCompliancePolicyStates. Don't select every available entity, each one adds load time and model complexity you don't need for this dashboard.

Choose Transform Data, not Load

This opens Power Query, where the real shaping work happens before anything hits your data model.


Stage 5: Power Query

Rename columns for clarity

Raw warehouse column names are rarely dashboard-friendly. Rename as you go, OS to Operating System, ComplianceState to Compliance Status, whatever makes the eventual DAX and visuals easier to read.

Fix data types explicitly

Confirm date columns are actually typed as Date, not Text, this is the single most common reason a time-based visual silently fails to sort correctly later.

Remove columns you won't use

Every unused column is dead weight in the model. If a field isn't feeding a visual or a relationship, remove it here rather than carrying it forward.

Filter out rows you don't want in the dashboard

Retired or deleted device records, if the entity includes them, usually don't belong in a "current fleet posture" dashboard. Filter them out now, not with a DAX workaround later.

Close & Apply

This loads the shaped tables into the actual data model.


Stage 6: Data Model

Think of this as a small star schema: devices is your fact table, one row per device, and dates, ownerTypes, and the compliance entity are the dimension tables that give those device rows context. This mental model is what makes Stage 7 make sense, rather than just clicking lines between tables and hoping.


Stage 7: Relationships

Switch to Model view

The diagram view in Power BI Desktop's left-hand navigation.

Connect devices to dates

Drag from the device enrollment date field to the dates table's date key. This is what makes an enrollment trend chart possible at all.

Connect devices to ownerTypes

Link the ownership type field on devices to ownerTypes, so a device ID resolves to a readable "Corporate" or "Personal" label instead of a raw code.

Connect devices to deviceCompliancePolicyStates

Usually on a shared device ID field, this is what lets a compliance visual pull accurate per-device state.

Check cardinality on each relationship

These should all be one-to-many (one date, one owner type, one policy state row relating to many devices), with a single, predictable filter direction. A relationship pointing the wrong way is the most common reason a visual shows numbers that look almost right but aren't.


Stage 8: DAX

A handful of measures cover everything this dashboard needs. Write these in a new, dedicated measures table rather than scattering them across the model, it keeps the model organised as it grows.

text
Total Devices = COUNTROWS(devices)
 
Compliant Devices =
CALCULATE(
    COUNTROWS(devices),
    devices[Compliance Status] = "Compliant"
)
 
Compliance % = DIVIDE([Compliant Devices], [Total Devices])
 
Windows Devices =
CALCULATE(COUNTROWS(devices), devices[Platform] = "Windows")
 
iOS Devices =
CALCULATE(COUNTROWS(devices), devices[Platform] = "iOS")
 
Android Devices =
CALCULATE(COUNTROWS(devices), devices[Platform] = "Android")

Build the percentage measures, not just the counts

A card showing "1,412 compliant devices" means very little on its own. Compliance % next to it, backed by DIVIDE (which safely handles a zero denominator instead of erroring), is what actually tells a manager whether that number is good or bad.


Stage 9: The Dashboard

Total Devices

A single Card visual bound to the Total Devices measure. This anchors the whole page.

Windows / iOS / Android

A Donut chart with devices[Platform] as the legend and Total Devices as the value, giving an immediate read on fleet composition.

Device Ownership

A Bar chart with ownerTypes[Owner Type] on the axis and Total Devices as the value, Corporate vs Personal.

OS Versions

A Bar chart (or table, if the version list is long) breaking Total Devices down by the OS version field, the fastest way to spot a large population still sitting on an outdated build.

Enrollment Trends

A Line chart with the dates table's month field on the axis and Total Devices as the value, this is exactly why the Stage 7 relationship to dates had to be correct.

Compliance

A Bar chart or Gauge, Compliant Devices against Total Devices, or a simple two-category bar (Compliant vs Non-compliant) using Compliance %.

Manufacturer

A Bar chart with the device manufacturer field on the axis, useful for procurement and warranty conversations as much as security ones.

Platform Distribution

A Treemap or Matrix crossing Platform by Ownership, a slightly deeper cut than the simple donut, showing whether personal devices skew toward a specific platform.


Stage 10: Power BI Service

Publish from Power BI Desktop

File → Publish → Publish to Power BI, choosing the workspace this dashboard belongs in.

Configure scheduled refresh

In the Power BI Service, open the dataset's settings and configure a refresh schedule. Because the OData feed is itself a cloud HTTPS endpoint, this typically doesn't require an on-premises data gateway, just valid, saved credentials for the scheduled refresh to authenticate with.

Build a proper Dashboard on top of the report, if pinning visuals across pages

A Power BI Dashboard (distinct from the Report you built in Desktop) lets you pin specific tiles from one or more reports onto a single page for executives who want the headline numbers without navigating report pages.

Share through a workspace or an app, not individual file exports

Publishing to a workspace and distributing access through Power BI's own sharing model keeps everyone looking at the same live, refreshing data, rather than emailing a .pbix file that goes stale the moment it's sent.


Summary

StageWhere it happensWhat you get
Intune → Data WarehouseIntune admin centreA reporting-optimised copy of device data
OData FeedIntune admin centreThe queryable entities Power BI will connect to
Power BI Desktop → Power QueryPower BI DesktopClean, renamed, correctly-typed tables
Data Model → RelationshipsPower BI Desktop, Model viewA working star schema, not just loose tables
DAXPower BI DesktopThe actual measures every visual depends on
DashboardPower BI Desktop, Report viewEight visuals answering real fleet-posture questions
Power BI Servicepowerbi.comA shared, scheduled-refresh dashboard, not a static file

The version of this that actually gets used by a manager three months from now is the one where the relationships were built correctly in Stage 7 and the refresh was actually configured in Stage 10, not the one with the prettiest visuals on day one.


Which of these eight visuals did you find the most useful once it was actually live? Enrollment Trends is the one I see teams underrate going in, and lean on most once budget or procurement conversations come up. Drop a comment with what earned its place on your dashboard.

CChetan Yamger

Written by

Chetan Yamger

Cloud Engineer · AI Automation Architect · Modern Workplace Consultant

Cloud Engineer, AI Automation Architect, and Modern Workplace Consultant based in Amsterdam, Netherlands. Specializing in scalable, secure enterprise solutions with Microsoft Azure, Intune, PowerShell, and AI-driven automation using ChatGPT, Gemini, and modern LLM technologies.

Cloud & Modern WorkplaceMicrosoft Intune & MDMAzure & Microsoft 365AI AutomationPrompt EngineeringPowerShell & Graph APIWindows AutopilotConditional Access & Zero TrustSCCM / MECM & MSIXVDI / WVDPower BINode.js & Next.js
Newsletter

Stay in the loop.
New articles, straight to you.

Deep-dive technical articles on Intune, PowerShell, and AI — no noise, no spam.

New article notifications
No spam, ever
Free forever

Discussion

Share your thoughts — your email stays private

Leave a comment

0/2000

Your email is used to prevent spam and will never be displayed.