How to Connect Power BI to Dynamics 365: 2026 Guide

TL;DR

• Use the Dataverse connector for Dynamics 365 Sales, Customer Service, Field Service, and other model-driven apps.
• Use the Dynamics 365 Business Central connector for Business Central. Prefer API pages or queries over UI pages exposed as OData web services.
• For Dynamics 365 Finance and Supply Chain Management, use the product’s analytical architecture, such as Entity store and analytical workspaces, rather than assuming the Dataverse steps apply.
• Choose Import or DirectQuery deliberately, publish to a controlled workspace, configure refresh, and test report access with representative user roles.

Which Power BI connection should you use?

Use the connector that matches the Dynamics 365 product storing the data. Dynamics 365 is a product family, so a single “Dynamics 365 connector” is not the correct route for every application. Identify the workload and deployment before selecting a Power BI connection method.

Dynamics 365 workload	Recommended starting point	Power BI behavior to plan for
Sales, Customer Service, Field Service, and other model-driven apps	Microsoft Dataverse connector	Import or DirectQuery
Business Central online	Dynamics 365 Business Central connector using API pages or queries	Import with service refresh
Business Central on-premises	Business Central on-premises connector and OData configuration	Gateway and authentication planning
Finance and Supply Chain Management	Entity store, analytical workspaces, or the supported analytics architecture for the environment	Product-specific DirectQuery, embedded, and deployment requirements

Microsoft documents the Dataverse connector, Business Central Power BI architecture, and Finance Entity store integration separately. Confirm the application and deployment type before creating the semantic model.

What do you need before connecting?

Prepare the environment URL, a licensed organizational account, table-level read access, and Power BI Desktop before opening the connector. The account should have only the Dynamics 365 permissions required for the report. Define the reporting scope, owner, workspace, and sharing audience at the same time.

For Dataverse, verify these prerequisites:

• The user can open the target Dynamics 365 environment and read the required Dataverse tables.
• The Dataverse TDS endpoint is enabled. Microsoft lists TCP port 1433 as the automatic connection route and 5558 as an alternative when the first port is blocked.
• Power BI Desktop is current enough to expose the Microsoft Dataverse connector.
• The report owner has an approved Power BI workspace and a defined sharing audience.
• Data owners have agreed which tables, columns, date ranges, and business definitions belong in the model.

Do not grant write or administrator access merely to build a read-only report. If the environment contains production customer, employee, or financial data, document the intended audience before the first publication.

How do you connect Power BI to Dataverse-based Dynamics 365 apps?

Select the Dataverse connector in Power BI Desktop, sign in, choose the environment, and load only the tables needed by the report. This is the current Microsoft-documented path for analytics over Dataverse tables. Confirm table permissions and reconcile a controlled sample before publishing the model.

1. Open Power BI Desktop.
2. Select Get data, then search for Dataverse.
3. Select Connect.
4. Sign in with an organizational account that can read the target environment.
5. Select the environment in Navigator.
6. Choose the required tables. Use Transform Data if columns, rows, or data types need to be reduced before loading.
7. Select Import or DirectQuery when Power BI prompts for a connectivity mode.
8. Build relationships and measures, then validate totals against a controlled Dynamics 365 view or export.

The server value is the Dataverse environment host, not an arbitrary Dynamics 365 page URL. If you need to confirm it, Microsoft explains how to find the Dataverse environment URL.

Avoid selecting every table. A smaller model is easier to secure, validate, refresh, and maintain when solutions add or rename columns.

Should you choose Import or DirectQuery?

Choose Import when scheduled refresh meets the business requirement; test DirectQuery when queries must run against Dataverse closer to viewing time. The correct choice depends on freshness, query load, model design, capacity, and report interaction patterns. Measure both options with representative data and users before deciding.

Consideration	Import	DirectQuery
Data storage	Copies selected data into the Power BI semantic model	Queries the source as users interact with the report
Refresh	Requires semantic-model refresh for source changes	Does not import table data on a schedule, although caches and metadata still need management
Report behavior	Usually more predictable for interactive reports	Depends more directly on source and network query performance
Source load	Concentrated around refresh operations	Generated by report queries and user interactions
Best fit	Curated models with an agreed refresh window	Cases where fresher source queries justify the operational trade-offs

Microsoft lists both modes as supported capabilities for the Dataverse connector. Run a representative test rather than labeling DirectQuery “real time.” Record page response time, source-query behavior, concurrency, and data freshness under the expected user load.

For larger Dataverse analytics architectures, evaluate Azure Synapse Link for Dataverse with Power BI instead of treating the operational application as an unlimited reporting warehouse.

How do you shape Dynamics 365 data without breaking the model?

Reduce the data in Power Query, preserve stable keys, and define business measures explicitly. A technically successful connection does not guarantee that a sales pipeline, case backlog, or revenue measure matches the organization’s operational definition. Reconcile each important measure to an approved source view and period.

Use this modeling sequence:

1. Start with a documented reporting question and its owner.
2. Select only the tables and columns required to answer it.
3. Filter closed historical periods only when the retention rule permits it.
4. Confirm data types, choice labels, dates, currencies, and time-zone handling.
5. Build relationships from stable identifiers rather than display names.
6. Create measures with clear names and written definitions.
7. Reconcile totals with an approved Dynamics 365 view for a fixed date range.

Query folding can reduce work performed after data leaves the source, but do not assume every transformation folds. Review the query plan where the connector supports it and compare refresh behavior before and after a change.

If the report combines ERP and CRM records, agree on shared keys and ownership first. Our guide to Power Platform integration with ERP systems explains the wider integration choices behind cross-system reporting.

How do you connect Power BI to Business Central?

Use the Dynamics 365 Business Central connector, then select the environment, company, and published API data needed by the model. For Business Central online, Microsoft recommends API pages or queries instead of OData web services based on UI pages. Validate the selected company and ledger totals before publication.

1. Open Get data in Power BI Desktop.
2. Select Dynamics 365 Business Central.
3. Sign in with the organizational account used for Business Central.
4. Expand the environment and company in Navigator.
5. Select supported API pages or queries for the required entities.
6. Transform and load the data, then reconcile it with Business Central reports or ledger entries.
7. Publish the report and configure its data-source credentials in the Power BI service.

Microsoft’s Business Central Power BI setup guidance says API pages and queries are the recommended online method. UI pages exposed as OData can change when Microsoft, an extension, or an app changes the page, which can break dependent reports.

Business Central on-premises has different setup requirements. Microsoft documents that the deployment must enable OData V4 and use a supported authentication method; Windows authentication is not supported for this integration. Follow the Business Central on-premises connection guide and plan the gateway before publication.

If Business Central data must also appear in Dataverse, review the integration boundary before duplicating it in Power BI. The Business Central and Dataverse integration guide covers that decision.

How do you connect Power BI to Dynamics 365 Finance?

Use the Finance and Supply Chain Management analytics architecture supported by the target environment. Do not apply Dataverse instructions to Finance tables unless the required data is intentionally available through Dataverse. Confirm the supported reporting layer, environment type, security design, and deployment path before building the model.

Entity store is a reporting-oriented operational data store containing aggregate measurements. Microsoft’s Entity store documentation describes Power BI DirectQuery models over those schemas and notes that Entity store refresh is managed in the application.

For embedded experiences, analytical workspaces place Power BI reports inside Finance and Supply Chain Management workspaces. Review Microsoft’s analytical workspace guidance before replacing or extending a standard report.

Before implementation, confirm:

• Whether the environment is cloud or on-premises
• Whether a standard analytical workspace already covers the requirement
• Which aggregate measurement or supported data product owns the required fields
• How the report moves between development, test, and production
• Which legal entities and security roles each audience may see

Avoid reporting directly against an operational schema merely because a connection can be made. Use the product’s supported analytics layer and validate the deployment path with the environment administrator.

How should refresh and credentials be configured?

Configure refresh in the Power BI service after publication, assign a responsible owner, and test failure notifications. Import models need a data refresh to reflect source changes; DirectQuery models have different cache and visual-refresh behavior. Record the expected freshness and prove it with a successful service-side refresh.

After publishing:

1. Open the semantic model settings in the target workspace.
2. Confirm the cloud connection or gateway mapping.
3. Set data-source credentials with an approved account or service principal where the connector supports it.
4. Choose a refresh schedule that matches the documented freshness requirement.
5. Enable failure notifications for the operational owner.
6. Run a refresh and inspect refresh history.
7. Reconcile a sample of refreshed values with the source.

Microsoft’s Power BI data refresh guidance distinguishes data refresh, cache refresh, tile refresh, and report-visual refresh. That distinction matters when a user says a dashboard is “stale”: first identify which layer failed to update.

An on-premises gateway is generally required when the Power BI service cannot connect directly to an on-premises data source. Keep the gateway current, cluster it where availability requirements justify that design, and document who owns its credentials and recovery.

How do you secure a published Dynamics 365 report?

Secure the source connection and the Power BI artifact as separate control planes. Dynamics 365 permissions govern what the connection identity can retrieve; Power BI workspace roles, app audiences, sharing permissions, and row-level security govern who can consume the published model.

Use these controls before release:

• Apply least privilege to the source identity.
• Keep development reports out of production workspaces.
• Define row-level security from stable identity attributes and test each role.
• Use Power BI apps or managed audiences rather than broad ad hoc sharing.
• Review export, Analyze in Excel, build, and reshare permissions.
• Test with representative user accounts instead of relying only on View as role.
• Recheck access after team, territory, legal-entity, or ownership changes.

Do not assume Dynamics 365 row ownership automatically reproduces itself in a Power BI semantic model. Document the expected access matrix and verify both positive and negative cases.

Why does the connection or refresh fail?

Start with the exact error, then test the environment URL, identity, permissions, network path, and schema in that order. Re-entering credentials repeatedly can hide the real fault without fixing it. Capture the timestamp, activity ID, workspace, semantic model, and recent changes before escalating the issue.

Symptom	Likely checks
Environment does not appear in Navigator	Confirm tenant, environment URL, license, table access, and TDS endpoint settings
Sign-in succeeds but tables are missing	Check Dataverse table privileges or Business Central permissions for the connection identity
Dataverse connection times out	Check whether TCP port 1433 is open; follow Microsoft’s documented 5558 alternative if required
Desktop refresh works but service refresh fails	Check cloud-connection credentials, gateway mapping, privacy levels, and unsupported dynamic source definitions
Refresh breaks after a solution update	Look for renamed or removed tables and columns, then refresh the schema in Desktop and repair dependent measures or visuals
Users see blank or excessive data	Test Power BI permissions and row-level security separately from Dynamics 365 source access
DirectQuery report is slow	Inspect source queries, relationships, measures, visual count, concurrency, and network latency

Record the first failing timestamp, activity ID, semantic model, workspace, connection identity, and recent source changes. That evidence makes Microsoft support or partner escalation more productive.

How do you validate the report before release?

Validate definitions, totals, security, refresh, and user workflows before distributing the Power BI app. A polished visual can still be wrong, inaccessible, or based on stale data. Use representative accounts and fixed source samples so every result can be repeated after a model, connector, or security change.

Use a release checklist:

• Reconcile agreed measures to Dynamics 365 for a fixed sample period.
• Test empty, duplicate, reopened, canceled, and reassigned records.
• Confirm currency and time-zone conversions.
• Run refresh with the production connection method.
• Review refresh history and failure notifications.
• Test every Power BI audience and row-level security role.
• Confirm drill-through links and embedded pages open for non-admin users.
• Record the model owner, data owner, support contact, and change process.

Repeat this validation after a Dynamics 365 solution change, Business Central extension update, Finance data-model change, or security redesign.

When should you involve a Dynamics 365 partner?

Involve a partner when the model spans products, requires an enterprise analytics architecture, exposes regulated data, or cannot meet refresh and performance requirements with a supported connector. The engagement should begin with the reporting questions, source systems, security matrix, and measurable acceptance criteria.

Our Dynamics 365 services cover integration architecture, Power Platform delivery, data modeling, security review, and controlled deployment.