How to Build Power BI Report from Dynamics 365 CRM Data

What Most Guides Get Wrong About D365 & Power BI Reporting

Most tutorials on connecting Power BI to Dynamics 365 start with a dangerously simple premise: just use the built-in Dataverse connector, pick your tables, and drag-and-drop fields onto a chart. This advice isn’t wrong, but it’s deceptively incomplete. It’s the equivalent of telling someone how to build a car by showing them the gas pedal.

This approach works for a demo with 1,000 records. In the real world, with 500,000 opportunity records and 100,000 accounts, this method builds reports that take 5-15 minutes to refresh a single visual. Within 3 months, users abandon it because it’s slower than running an Advanced Find in Dynamics, completely defeating the project’s purpose and wasting the initial $5,000-$10,000 investment.

The first flawed assumption is that the connection method is just a simple choice. The standard Dataverse connector directly queries the operational database’s API. This is fine for small datasets, but it creates a performance bottleneck and is subject to API throttling, a problem that affects an estimated 30% of large-scale implementations. The real work isn’t connecting; it’s architecting a data flow that doesn’t cripple your CRM’s performance.

The second, and more damaging, flawed assumption is that report building is about making pretty visuals. Novices spend 80% of their time in the report design canvas, agonizing over colors and chart types. Experts, in contrast, spend 80% of their time in the Power Query Editor and the Data Model view—the engine room of Power BI.

Focusing on visuals first is a surefire path to failure. You create a beautiful dashboard that either displays the wrong numbers or takes an eternity to load. The second-order effect is a complete loss of trust in the data from business stakeholders, a setback that can take 6-12 months to recover from.

Finally, most guides completely skip the concept of a data strategy. They encourage you to pull in the entire Account and Opportunity table with all 200+ columns. This is like trying to drink from a firehose. Without a clear strategy defining which 3-5 business questions you’re answering, you create a tangled web of tables and relationships that is impossible to maintain or validate.

This lack of strategy is why many D365 reporting projects are abandoned within 4-6 months. The signal that distinguishes a professional from an amateur is this: the professional starts by asking “What decisions will this report drive?” and works backward to the data. The amateur starts with the data and hopes to find some insight, which rarely happens.

Building on these common failures, it’s clear we need a more robust mental model for how reporting projects should actually be structured. This leads us to a framework that prioritizes the data foundation over the visual presentation.

How D365 Reporting Actually Works: The ‘Data First’ Framework

To avoid the pitfalls we just discussed—slow reports, inaccurate data, and lost credibility—you need to adopt a ‘Data First’ framework. This approach inverts the common advice by treating the visual dashboard as the final, and frankly easiest, step in a much more critical process. Think of it as a three-layer cake: the foundation, the structure, and the decoration.

The first layer is your Data Connection & Sourcing. This is your choice between the Dataverse connector, Azure Synapse Link, or a direct SQL replication. As we saw, choosing the wrong method based on simplicity rather than scale is a primary failure mode. This choice dictates the speed and reliability of your entire system.

The second, and most important, layer is the Data Model & Transformation. This happens in Power Query and the Model view. Here, you clean, shape, and relate your data into a performant structure, typically a Star Schema. A well-designed model can reduce data size by 90% and increase report interaction speed by over 300%. This is the work that separates a dashboard that gets used from one that gets abandoned.

The final layer is the Visualization & Calculation (DAX). This is the part everyone sees—the charts, graphs, and KPIs. While visually important, its accuracy and speed are entirely dependent on the quality of the two layers beneath it. Writing DAX (Data Analysis Expressions) is how you define your key metrics, like Year-over-Year Growth or Sales Cycle Length.

Building a report is like building a house. You wouldn’t pick out paint colors (visuals) before pouring a solid foundation and erecting a strong frame (the data model). The ‘Data First’ framework ensures your project is built to last, delivering insights that are both fast and trustworthy. An investment of 3-5 weeks in proper modeling at the beginning can save you 6 months of rework and frustration down the line.

With this foundational framework understood, let’s walk through the exact, step-by-step process of implementing it, from a blank Power BI file to a fully functional sales dashboard.

Step-by-Step Guide: From Blank Canvas to Live Sales Dashboard

Applying the ‘Data First’ framework we just outlined, we can now build a report methodically. This process should take an experienced analyst 40-60 hours for the initial version, but for a team learning the ropes, budget 80-120 hours over 3-6 weeks. Success at each step is critical for the final outcome.

Step 1: Define Your Core Business Questions

Before you even open Power BI, spend 2-4 hours with stakeholders to define the 3-5 critical questions this dashboard must answer. This is not a technical task; it’s a business task. A reliable pattern is to focus on questions that drive action.

1. Good Question: “Which lead sources generate the highest revenue per lead after 90 days?” This drives marketing budget decisions.
2. Bad Question: “Can I see all our accounts?” This is simple data retrieval, not analytics. Use a Dynamics 365 View for that.
3. Document these questions. They become the acceptance criteria for the entire project. The project is successful only when these questions are answered clearly and accurately.

This step is complete when you have a signed-off list of questions. Without this, you’re just exploring data, which is not the goal of a business dashboard. This clarity prevents scope creep that derails 50% of BI projects.

Step 2: Connect to Dynamics 365 Dataverse

Now, open Power BI Desktop. The initial connection is straightforward, but one choice here has massive performance implications. For this guide, we’ll start with the standard connector, as it’s the most common entry point.

1. In Power BI Desktop, go to Get Data > Power Platform > Dataverse.
2. Enter your Dynamics 365 environment URL (e.g., `yourorg.crm.dynamics.com`).
3. Choose a Connectivity mode. Your two options are Import and DirectQuery. The trade-off is clear: Import is fast for the user but data is only as fresh as the last refresh; DirectQuery is live data but can be slow. For 95% of analytical scenarios, start with Import. This is a critical decision heuristic.
4. The Navigator window will appear. Do NOT just check the boxes next to the tables you need. Instead, click ‘Transform Data’ immediately to open the Power Query Editor. This is a crucial habit to build.

This connection step takes about 10 minutes. Success is defined by having the Power Query Editor open with your selected tables loaded, ready for the most important phase: shaping.

Step 3: Shape Your Data in Power Query (The 80% Rule)

This is where the magic happens and where 80% of your development time should be spent. The goal here is to be ruthless: remove everything you don’t need to answer your core questions. Every column and row you remove makes your report faster.

1. Select Columns: For your Opportunity table, instead of loading all 250 columns, use the “Choose Columns” feature and select only the 10-15 you need (e.g., `opportunityid`, `name`, `actualvalue`, `estimatedclosedate`, `ownerid`, `accountid`, `statecode`). This single action can reduce refresh times by 70%.
2. Filter Rows: You likely don’t need opportunities from 10 years ago. Add a filter step to only keep records from the last 2-3 years. Also, filter for active records, for example, `statecode` equals ‘Won’ or ‘Lost’, excluding ‘Open’ if you’re analyzing closed business.
3. Handle Option Sets: Dynamics 365 option sets (like ‘Lead Source’) come in as numbers. You’ll need to bring in the `stringmap` entity or create conditional columns to map the numbers (e.g., 1, 2, 3) to their text labels (‘Web’, ‘Referral’, ‘Partner’). This is a common failure point that trips up 60% of new developers.
4. Create a Date Dimension: Do not rely on date fields in your data. Create a dedicated Date table in Power Query. You can find standard M scripts for this with a quick search for “Power BI Date Table M Script” from sources like SQLBI.

This shaping phase can take 2-4 weeks. It is complete when your tables are lean, clean, and contain only the data necessary to answer your business questions. Your preview in Power Query should load quickly.

Step 4: Build the Star Schema Data Model

With your tables shaped, you now move to the Model view in Power BI to establish relationships. The goal is a Star Schema: a central ‘Fact’ table (like Opportunities) surrounded by ‘Dimension’ tables (like Accounts, Users, Date, Products).

1. Identify your Fact table. It contains the numbers you want to analyze (e.g., `actualvalue`).
2. Identify your Dimension tables. They contain the attributes you want to slice by (e.g., Account Name, Salesperson, Date).
3. Drag the key fields to create relationships (e.g., drag `accountid` from Opportunities to `accountid` in Accounts).
4. Ensure all relationships are one-to-many (one Account has many Opportunities) and have a single filter direction. Avoid bi-directional relationships, as they can cause ambiguity and poor performance. Power BI often suggests them, but you should manually override this in 90% of cases.

A well-structured model is the blueprint for a performant report. This part takes a few hours of work but relies on weeks of proper data shaping. Success is a clean, star-like diagram with no complex loops or bi-directional filters.

Step 5: Write Core DAX Measures

Now you can finally start calculating your metrics. Do not create calculated columns if you can use a measure. Measures are calculated on the fly and don’t consume memory in the same way, making your model smaller and faster.

1. Create a new table just for your measures to keep them organized.
2. Write your base measures first. For example: `Total Revenue = SUM(Opportunities[actualvalue])`.
3. Build more complex measures using the `CALCULATE` function. For example, to get revenue from a specific source: `Web Revenue = CALCULATE([Total Revenue], ‘Opportunities'[leadsourcecode] = 1)`.
4. Add time intelligence. Using your Date table, you can write: `YTD Revenue = CALCULATE([Total Revenue], DATESYTD(‘Date'[Date]))`.

This is an iterative process that can take 1-2 weeks. Start simple and validate each number against Dynamics 365 before building more complex logic.

Step 6: Design the Visuals and Publish

This is the last step. Because you’ve done the hard work, this part is easy. Drag your new measures and dimension fields onto the canvas.

1. Start with simple tables and matrix visuals to validate your numbers. This is a critical quality assurance step.
2. Once validated, convert them into charts (bar, line, etc.) that best answer your core business questions from Step 1.
3. Publish the report to the Power BI Service. Go to the dataset settings and configure the scheduled refresh. With a Pro license, you can schedule up to 8 refreshes per day. Set the Data Source credentials using OAuth2 and an organizational privacy level.

The first pass of visualization should only take a day. The entire project culminates here, with a fast, accurate, and actionable dashboard. This leads us to consider which underlying connection technology is best for your specific scale and needs.

Choosing Your Approach: Dataverse vs. Data Lake vs. SQL

Building on the implementation steps, your long-term success heavily depends on the data connection architecture you choose. The default Dataverse connector is a great start, but it has boundary conditions where it breaks down. Making the right choice upfront can save you a full project rewrite in 12-18 months.

Here is a decision heuristic to guide your choice:

IF your total data volume across key tables (like Accounts, Contacts, Opportunities) is less than 1 million rows AND you don’t need to blend it with many other data sources AND your reports can tolerate a 15-30 minute refresh time, THEN the standard Dataverse Connector in Import mode is your best option. The cost is included in your Power BI license ($10/user/month). The trade-off is that you are directly querying the live D365 API, which can be slow and is subject to throttling. This is the 80/20 solution for small to medium businesses.

IF you have large data volumes (>1 million rows), are experiencing slow refreshes, or need to combine D365 data with other systems (like an ERP), THEN you should use Azure Synapse Link for Dataverse. This feature continuously exports your D365 data to an Azure Data Lake in a highly optimized format. Power BI then connects to the data lake, not D365. The cost is typically low, around $50-$300/month in Azure consumption. The setup takes a few hours, and the ROI is a massive performance boost—refreshes can be 50-80% faster—and zero performance impact on your D365 users. The trade-off is a slightly more complex initial setup.

IF you are a large enterprise with a dedicated data team, have complex data warehousing needs, and require granular control over transformations and data history, THEN you might replicate your D365 data into a dedicated Azure SQL Database. This is the most powerful but also the most expensive and complex option, often costing $1,000-$5,000+ per month and requiring specialized ETL (Extract, Transform, Load) expertise. You sacrifice simplicity for ultimate control and performance. This is the wrong choice for 95% of companies, but essential for the other 5%.

The key takeaway is that your connection method should evolve with your data maturity. Starting with the Dataverse connector is fine, but recognizing when to graduate to Azure Synapse Link is what distinguishes a sustainable BI strategy from a short-term fix. This leads us to a deeper dive into mastering each of these options.

Mastering the Dataverse Connector

For many teams, the standard Dataverse connector is the entry point. Using it effectively means understanding its limitations and optimizing within them. Success isn’t just about connecting; it’s about connecting responsibly to avoid performance issues.

How to Do This

1. In Power BI Desktop, select Get Data > Power Platform > Dataverse.
2. Enter your environment URL (`yourorg.crm.dynamics.com`) and choose Import mode.
3. In the Navigator, select your required tables (e.g., account, opportunity, systemuser). Crucially, click Transform Data, not Load.
4. In the Power Query editor that opens, immediately perform two actions on each table: use Choose Columns to select only the fields you need, and then use Filter Rows to remove irrelevant data (e.g., inactive accounts, opportunities older than 3 years).
5. For option set fields that show up as numbers, you will need to import the `stringmap` entity, filter it for your specific option sets, and merge it with your primary table to get the text labels.

Real Numbers

• Initial Setup Time: 15-30 minutes.
• Cost: Included with Power BI Pro/Premium license ($10-$20/user/month).
• Performance Impact: A report with 5 tables and 100k rows each can take 10-25 minutes to refresh if unoptimized. By selecting only necessary columns, this can be reduced to 3-7 minutes.
• ROI: For small teams, this approach provides 80% of the value for 20% of the complexity, enabling quick insights within 1-2 weeks of development.

Common Mistakes

The most common mistake, seen in over 60% of self-service projects, is loading entire tables. Loading all 250+ columns from the Opportunity table when you only need 15 is the primary cause of slow refreshes and model bloat.

Another frequent error is failing to handle D365’s polymorphic lookup fields (like the ‘Customer’ field on an Opportunity, which can be an Account or a Contact). These require special handling in Power Query to expand correctly, and ignoring them leads to incomplete or inaccurate data.

Success Checklist

• You are using Import mode, not DirectQuery.
• Every table in Power Query has a “Removed Other Columns” step near the beginning.
• Every table has a “Filtered Rows” step to reduce the data volume.
• You have a dedicated, marked Date table in your model.

Once your data volumes grow or refresh times become unacceptable, it’s time to graduate from this method to a more scalable architecture like Azure Synapse Link.

Optimizing with Azure Synapse Link for Dataverse

When the standard connector isn’t enough, Azure Synapse Link for Dataverse is the logical next step. It decouples your reporting from your operational CRM, providing a significant boost in performance and scalability. This is the professional’s choice for any serious D365 reporting project.

How to Do This

1. Navigate to the Power Apps maker portal (make.powerapps.com).
2. In the left pane, select Azure Synapse Link and create a new link.
3. Connect to your Azure subscription and select a resource group and an Azure Data Lake Gen2 storage account. This is where your D365 data will be stored as CSV files.
4. Select the D365 tables you want to export. The initial sync can take several hours for large tables, but subsequent updates are near-real-time.
5. In Power BI Desktop, instead of connecting to Dataverse, select Get Data > Azure Data Lake Storage Gen2.
6. Connect to the storage account you configured. You will now build your report from the CSV files in the lake, which places zero load on your D365 instance.

Real Numbers

• Initial Setup Time: 2-4 hours.
• Cost: Azure consumption fees, typically $50 – $300 per month for storage and processing. This is a marginal cost for the performance gain.
• Performance Impact: Report refresh times are typically 50-80% faster than the Dataverse connector because reading from a data lake is highly optimized. A 20-minute refresh can become a 4-minute refresh.
• ROI: For data-heavy organizations, this investment pays for itself within 3-6 months through time saved on waiting for reports and increased user adoption due to better performance.

Common Mistakes

The primary mistake is misunderstanding the data format. Data is stored as raw CSVs, so you must explicitly set data types in Power Query (e.g., text, whole number, date). A failure to do so, which happens in about 40% of first-time implementations, results in incorrect sorting and calculations.

Another issue is not enabling the append-only mode for data that requires historical tracking. By default, Synapse Link provides the current state of records, not a history of changes.

Success Checklist

• Your Synapse Link profile is active and shows a ‘Synced’ status for all tables.
• Your Power BI file’s data source is an Azure Storage Account, not a D365 environment.
• Each query in Power Query has a “Changed Type” step where data types are explicitly set.
• Your report refreshes complete successfully and reliably in the Power BI Service.

With data flowing efficiently through either the connector or Synapse Link, the next bottleneck to address is the structure of your data model itself.

Building a Performance-Tuned Data Model

Your connection method gets the data into Power BI, but the data model determines how efficiently it can be queried. A well-designed model is the difference between a report that feels snappy and one that makes users stare at a spinning icon. The goal is always a simple, clean star schema.

How to Do This

1. Identify Fact & Dimension Tables: Go through your queries from the previous step. The table with your core metrics (like revenue, quantity from the Opportunity table) is your Fact Table. Tables with descriptive attributes (like Accounts, Users, Products) are your Dimension Tables.
2. Create a Date Table: If you haven’t already, create a dedicated calendar table in Power Query. After creating it, go to the Table Tools in Power BI and use the “Mark as Date Table” feature. This enables powerful time intelligence functions.
3. Establish Clean Relationships: In the Model view, drag keys from your dimension tables to your fact table (e.g., `systemuserid` from Users to `ownerid` in Opportunities). Ensure the relationship is one-to-many and the cross-filter direction is ‘Single’.
4. Hide Key Fields: To prevent report builders from using the wrong fields, right-click and hide the foreign key columns in your fact table (e.g., hide `ownerid` in the Opportunity table). This forces users to use the fields from the dimension tables (like ‘Owner Name’ from the User table), ensuring correct filtering.

Real Numbers

• Time Investment: Proper data modeling should account for 30-40% of your total project time. This isn’t just a 1-hour task.
• Performance Impact: A star schema can be 50-70% smaller in memory than a single flat table, and visual interactions can be up to 300% faster.
• Failure Rate: An estimated 70% of performance problems in self-service Power BI projects are caused by a poorly designed data model, not slow data sources.

Common Mistakes

The most common mistake is creating a model that mirrors the transactional database structure of Dynamics 365. D365 is optimized for writing single records quickly (normalized), while a Power BI model should be optimized for analyzing millions of records at once (denormalized into a star schema).

Another critical error is leaving bi-directional relationships active. While sometimes necessary, they are a primary cause of ambiguous filter contexts and slow performance. They should be used sparingly and with deep understanding.

Success Checklist

• Your model diagram looks like a star, with dimension tables surrounding fact tables.
• All relationships are one-to-many (or one-to-one).
• You have a dedicated table marked as a Date Table.
• Foreign keys in fact tables are hidden from the report view.

Once your model is solid, you can start defining the business logic using the DAX language.

Troubleshooting Common D365 Reporting Failures

Even with a perfect plan, you’ll encounter issues. The key is to diagnose them quickly. Here are the most common problems and their solutions.

Problem: “My report refresh is extremely slow or times out.” (Happens in ~45% of initial projects)

Solution: The cause is almost always pulling too much data. Go back to the Power Query Editor. For every single table, use “Choose Columns” and be ruthless about removing everything you don’t need. Then, add a “Filter Rows” step to remove old or irrelevant records. A model with 10 tables of 50 columns each will refresh much slower than the same model with only 10 columns per table.

Problem: “My numbers in Power BI don’t match the numbers in Dynamics 365.” (Happens in ~60% of projects)

Solution: This usually comes from one of two places. First, check your filters in Power Query. You are likely including records that are filtered out in the D365 view you’re comparing against (e.g., inactive opportunities). Second, check your model relationships. An incorrect or inactive relationship will cause your filters (slicers) to not propagate correctly, leading to incorrect totals.

Problem: “I get a credential error when I try to schedule the refresh online.”

Solution: In the Power BI Service, go to the Dataset settings. Under “Data source credentials,” click “Edit credentials.” Make sure the authentication method is set to `OAuth2` and the Privacy level is set to `Organizational`. Then, sign in with a user account that has at least read access to all the tables in your report within Dynamics 365. This error happens in about 30% of first-time deployments.

Problem: “My option set or lookup fields are just showing numbers or IDs.”

Solution: This is expected behavior. You need to explicitly bring in the related tables in Power Query. For lookups (e.g., Account on an Opportunity), bring in the Account table and merge it. For option sets, you need to either build a manual mapping table or connect to the `stringmap` entity to get the text labels associated with the numbers.

Knowing these common failure modes allows you to recognize when this entire approach might be overkill for your needs.

When Power BI + Dynamics 365 Is the Wrong Choice

Power BI is an incredible tool, but it’s not the right solution for every problem. Insisting on using it when a simpler tool would suffice is a common form of over-engineering that wastes time and money. Here are specific conditions where you should choose an alternative.

Skip this if you need true real-time operational data embedded in a D365 form. Power BI’s refresh is, at its fastest, every 15-30 minutes. If a user needs to see data update the instant they save a record, use built-in Dynamics 365 Dashboards and Views instead. They are truly real-time and designed for this exact purpose.

Skip this if you have a budget of less than $1,000 and zero in-house technical expertise. While the licensing is cheap, the time investment to learn data modeling is significant. If you just need basic CRM reporting and have no one to build it, consider a CRM with simpler, built-in reporting like HubSpot, or stick to basic D365 reports and Excel exports. The cost of a consultant to build a proper dashboard starts at $5,000-$15,000.

Skip this if your reporting needs are very simple and your data volume is tiny (e.g., less than 10,000 total records). The complexity of setting up a data model, refreshes, and workspaces is overkill if all you need is a weekly export of new leads. A simple saved View in D365 exported to Excel will get you the answer in 5 minutes, versus the 40+ hours required to build a sustainable Power BI solution.

The pattern is clear: use Power BI for aggregated analytical reporting (trends over time, strategic analysis), and use built-in D365 tools for real-time operational reporting. Choosing the right tool for the job is the first step to success.

Comparison Table: Connection Methods

To summarize the technical approaches, choosing the right connection method is a critical decision based on your specific trade-offs between cost, performance, and complexity. The following table provides an opinionated guide to help you decide.

Dimension	Dataverse Connector (Import)	Dataverse Connector (DirectQuery)	Azure Synapse Link
Cost	Included in Power BI License ($10/user/mo)	Included in Power BI License ($10/user/mo)	$50 – $300/mo Azure consumption
Data Freshness	Scheduled (up to 8x/day on Pro)	Near Real-time	Near Real-time (in Data Lake)
Report Performance	Fast (data is in-memory)	Slow (queries D365 API live)	Very Fast (queries optimized data lake)
Setup Complexity	Low (5 minutes)	Low (5 minutes)	Medium (2-4 hours)
Impact on D365	High during refresh (API load)	High with every user click (API load)	Zero
Best For	Small to medium datasets, simple analytics, teams new to Power BI.	Specific visuals needing live data where performance is not a concern.	Medium to large datasets, enterprise reporting, performance-critical dashboards.
Avoid If	You have >1 million rows or your refresh takes >30 mins.	You need an interactive, fast dashboard. This is rarely the right choice.	Your budget is zero and your data is very small.

My position is clear: for any serious, long-term reporting initiative on top of Dynamics 365, Azure Synapse Link is the superior architecture. The small increase in setup complexity and cost is overwhelmingly justified by the massive gains in performance, scalability, and the decoupling from the operational CRM system.

Frequently Asked Questions

How much does a Power BI license cost?

A Power BI Pro license, which is required to share reports, costs $10 per user per month. There is also a Premium per User license at $20/user/month that offers larger data models and more frequent refreshes. The initial development can be done with the free Power BI Desktop application.

How long does building the first sales dashboard take?

For an experienced developer or consultant, building a comprehensive, well-modeled sales dashboard typically takes 40-60 hours (1-2 weeks). For a team learning Power BI and data modeling principles as they go, a more realistic timeline is 80-120 hours (3-4 weeks) to get to a reliable version 1.0.

What Dynamics 365 security role does the connecting user need?

The user account used for the data source credentials needs a security role with read permissions for all the tables (entities) included in your report. It’s a best practice to create a dedicated, read-only ‘Power BI Service Account’ role in D365 for this purpose. This ensures the reporting user can’t accidentally modify data and has access to exactly what it needs.

What’s the real ROI of building a D365 Power BI dashboard?

The ROI is typically measured in efficiency gains and improved decision-making. Companies often see a 10-15% reduction in sales cycle time because managers can spot stalled opportunities faster. Marketing teams can improve lead-to-opportunity conversion rates by 5-10% by reallocating budget away from underperforming lead sources. The project cost (e.g., $10,000 for a consultant) is often recouped within 6-9 months.

What happens if we hit the Dataverse API limits?

This is a major risk when using the standard connector. Dynamics 365 has API protection limits that prevent any single user from making too many requests. A large Power BI refresh can easily hit these limits, causing the refresh to fail. This is a primary reason to use Azure Synapse Link, which completely bypasses the Dataverse API for reporting and eliminates this risk entirely. About 25% of large implementations using the direct connector will face throttling issues.

How do I handle Dynamics 365 choice/option set fields?

In Power BI, choice fields load as numbers, not text labels. The correct way to handle this is to bring the `stringmap` table into Power Query, filter it to only the entity and attribute you need (e.g., `opportunity` and `leadsourcecode`), and then merge this query with your opportunity table to bring in the text labels. This process takes about 15-30 minutes per option set and is a fundamental skill for D365 report builders.

Can I embed Power BI reports back into Dynamics 365?

Yes, you can embed Power BI reports directly into D365 dashboards or forms. This provides context-sensitive analytics right where users work. The configuration is done within D365 and typically takes less than 1 hour to set up the first embedded report. This dramatically increases the adoption and utility of your reports.