Working with Microsoft Dataverse Connector in Power BI is usually straightforward—until you encounter a table that simply refuses to load any rows, even though the data clearly exists in the environment. This happens especially with hidden, virtual, or system-driven tables (e.g. msdyn_businessclosure, msdyn_scheduleboardsetting) which are commonly used in Field Service and Scheduling scenarios. Before jumping to a workaround, it’s important to understand why certain Dataverse tables don’t load in Power BI, what causes this behavior, and why the standard Dataverse connector may legitimately return zero rows. Causes – 1] The Table Is a Virtual or System Table with Restricted AccessSystem-managed Dataverse tables like msdyn_businessclosure are not exposed to the Dataverse connector because they support internal scheduling and platform functions. 2] No Records Exist in the Root Business Unit Data owned by child business units is not visible to Power BI accounts associated with a different BU, resulting in zero rows returned. 3] The Table Is Not Included in the Standard Dataverse Connector Some solution-driven or non-standard tables are omitted from the Dataverse connector’s supported list, so Power BI cannot load them. Solution: Export Dataverse Data Using Power Automate + Excel Sync Since Power BI can read:-> OneDrive-hosted files-> Excel files-> SharePoint-hosted spreadsheets …a suitable workaround is to extract the restricted Dataverse table into Excel using a scheduled (When the records are few) / Dataverse triggered (When there are many records and you only want a single one, to avoid pagination) Power Automate flow. What it can do –-> Power Automate can access system-driven tables.-> Excel files in SharePoint can be refreshed by Power BI Service.-> we can bypass connector restrictions entirely.-> The method works even if entities have hidden metadata or internal platform logic. This ensures:-> Consistent refresh cycles-> Full visibility of all table rows-> No dependency on Dataverse connector limitations Use case I needed to use the Business Closures table (Dataverse entity: msdyn_businessclosure) for a few calculations and visuals in a Power BI report. However, when I imported it through the Dataverse Connector, the table consistently showed zero records, even though the data was clearly present inside Dynamics 365. There are 2 reasons possible for this –1] It is a System/Platform Tablemsdyn_businessclosure is a system-managed scheduling table, and system tables are often hidden from external connectors, causing Power BI to return no data. 2] The Table Is Not Included in “Standard Tables” Exposed to Power BIMany internal Field Service and scheduling entities are excluded from the Dataverse connector’s metadata, so Power BI cannot retrieve their rows even if they exist. So here, we would fetch the records via “Listing” in Power automate and write to an excel file to bypass the limitations that hinder the exposure of that data; without compromising on user privileges, or system roles; we can also control or filter the rows being referred directly at source before reaching PBI Report. Automation steps – 1] Select a suitable trigger to fetch the rows of that entity (Recurring or Dataverse, whichever is suitable). 2] List the rows from the entity (Sort/Filter/Select/Expand as necessary). 3] Perform a specific logic (e.g. clearing the existing rows, etc.) on the excel file where the data would be written to. 4] For each row in the Dataverse entity, select a primary key (e.g. the GUID), provide the path to the particular excel file (e.g. SharePoint -> Location -> Document Library -> File Name -> Sheet or Table in the Excel File), & assign the dynamic values of each row to the columns in the excel file. 5] Once this is done, import it to the PBI Report by using suitable Power Query Logic in the Advanced Editor as follows – -> a) Loading an Excel File from SharePoint Using Web.Contents() – Source = Excel.Workbook(Web.Contents(“https://<domain>.sharepoint.com/sites/<Location>/Business%20Closures/msdyn_businessclosures.xlsx”),null,true), What this step does: -> Uses Web.Contents() to access an Excel file stored in SharePoint Online.-> The URL points directly to the Excel file msdyn_businessclosures.xlsx inside the SharePoint site.-> Excel.Workbook() then reads the file and returns a structured object containing:All sheets, Tables, Named ranges Parameters used: null → No custom options (e.g., column detection rules)true → Indicates the file has headers (first row contains column names) -> b) Extracting a Table Named “Table1” from the Workbook – msdyn_businessclosures_Sheet = Source{[Item=”Table1″, Kind=”Table”]}[Data], This would search inside the Source object (which includes all workbook elements), and look specifically for an element where: Item = “Table1” → the name of the table in the Excel fileKind = “Table” → ensures it selects a table, not a sheet with the same name & would extract only the Data portion of that table. As a result, we get Power Query table containing the exact contents of Table1 inside the Excel workbook, to which we can further apply our logic filter, clean, etc. To conclude, when Dataverse tables refuse to load through the Power BI Dataverse Connector—especially system-driven entities like msdyn_businessclosure—the issue is usually rooted in platform-level restrictions, connector limitations, or hidden metadata. Instead of modifying these constraints, offloading the data through Power Automate → Excel → Power BI provides a controlled, reliable, and connector-independent integration path. By automating the extraction of Dataverse rows into an Excel file stored in SharePoint or OneDrive, you ensure: This method is simple to build, stable to maintain, and flexible enough to adapt to any Dataverse table -whether standard, custom, or system-managed. For scenarios where Power BI needs insights from hidden or restricted Dataverse tables, this approach remains one of the most practical and dependable solutions. I Hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudFronts.com.

If you’ve been building reports in Power BI for a while, you’ve probably come across two features that sound similar but behave very differently: Drill-Through and Drill-Down. Many new users—even experienced ones, often get confused about when to use each option. Think of it like this: Both features are powerful, both help users understand data better, and both can make your reports feel more interactive. In this blog, I’ll break them down in the simplest way possible—what they are, how they work, and when to pick one over the other. When to Use Drill-ThroughUse it when: Think of Drill-Through as going from a “summary dashboard” to a “deep dive report.” Source: Microsoft A simple way to remember:Drill-Down stays in the chart. Drill-Through takes you to another page. Drill-Down vs. Drill-Through: Quick Comparison Table Feature Best Used For Where It Happens User Action Drill-Down Exploring hierarchies Inside the same visual Click on drill icons Drill-Through Opening detailed pages Across pages Right-click → Drill Through Real-World Examples 1.Drill-Down Example A sales manager wants to look at Yearly Sales, then break it down by Quarter, then by Month.No page changes, just clicking inside the same visual. 2. Drill-Through Example A CEO wants to know why a specific customer’s revenue dropped.Right-click → “Customer Details Page” → All insights in one place. To conclude, both Drill-Down and Drill-Through help users explore data, but they solve different problems. By choosing the right feature at the right time, you make your Power BI reports not only interactive, but also intuitive and enjoyable for your audience. I Hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

For data-driven companies, data insights are only as valuable as the platform that delivers them. As organizations modernize their technology stack, choosing the right reporting solution- whether SSRS, Power BI, or Paginated Reports – becomes a critical decision. With multiple options available, establishing clear evaluation criteria is essential to avoid costly missteps and future migration challenges. Are you struggling to decide which reporting tool fits your specific needs? If you’re evaluating SSRS, Power BI, or Paginated Reports for your organization, this article is for you. I’m confident this framework will help you make the right reporting tool decision and avoid common pitfalls that waste time and money. Understanding the Three Options Before we dive into the decision framework, let’s clarify what each tool actually is: SSRS (SQL Server Reporting Services) – The traditional Microsoft reporting platform that’s been around since 2004. It’s pixel-perfect, print-oriented, and runs on-premises. Power BI – Microsoft’s modern cloud-based analytics platform focused on interactive dashboards, data exploration, and self-service analytics. Paginated Reports in Power BI – The evolution of SSRS technology integrated into Power BI Service, combining traditional reporting with modern cloud capabilities. Step 1: Identify Your Primary Use Case Ask yourself this fundamental question: What is the report’s main purpose? Use Case A: Interactive Exploration and Analysis Best Choice: Power BI Choose Power BI when: Example Scenarios: Sales performance dashboards, Executive KPI monitoring, Marketing analytics platforms, Operational metrics tracking Use Case B: Precise Formatted Documents Best Choice: Paginated and SSRS Reports Choose Paginated Reports when: Example Scenarios: The Feature Comparison Matrix Power BI Standard Reports Strengths: Limitations: Paginated and SSRS Reports Strengths: Limitations: Cost Analysis: Making the Business Case Power BI & Power BI Paginated Reports Licensing Power BI Pro: $14/user/month SSRS Costs Important Note: If you’re already using Microsoft Dynamics 365 or Dynamics CRM, SSRS functionality is included at no additional cost. When SSRS is Already Available: Infrastructure Costs (If Not Using Dynamics): To conclude, I encourage you to take a systematic approach to your reporting tool decision. Identify your top 5 most important reports and categorize them by use case. This systematic approach will reveal the right decision for your organization and help you build a business case for stakeholders. Need help evaluating your specific reporting scenario? Connect with us at transform@cloudfronts.com for personalized guidance on choosing and implementing the right reporting solution. Making the right decision today will save you years of headaches and wasted resources.

Azure Databricks has become the go-to platform for data engineering and analytics, while Power BI remains the most powerful visualization tool in the Microsoft ecosystem. Connecting Databricks to Power BI bridges the gap between your data lakehouse and business users, enabling real-time insights from curated Delta tables. In this blog, we’ll walk through the process of securely connecting Power BI to Databricks, covering both DirectQuery and Import mode, and sharing best practices for performance and governance. Architecture Overview The connection involves:– Azure Databricks → Your compute and transformation layer.– Delta Tables → Your curated and query-optimized data.– Power BI Desktop / Service → Visualization and sharing platform. Flow:1. Databricks processes and stores curated data in Delta format.2. Power BI connects directly to Databricks using the built-in connector.3. Users consume dashboards that are either refreshed on schedule (Import) or query live (DirectQuery). Step 1: Get Connection Details from Databricks In your Azure Databricks workspace:1. Go to the Compute tab and open your cluster (or SQL Warehouse if using Databricks SQL).2. Click on ‘Advanced → JDBC/ODBC’ tab.3. Copy the Server Hostname and HTTP Path — you’ll need these for Power BI. For example:– Server Hostname: adb-1234567890123456.7.azuredatabricks.net– HTTP Path: /sql/1.0/endpoints/1234abcd5678efgh Step 2: Configure Databricks Personal Access Token (PAT) Power BI uses this token to authenticate securely.1. In Databricks, click your profile icon → User Settings → Developer → Access Tokens.2. Click Generate New Token, provide a name and expiration, and copy the token immediately. (You won’t be able to view it again.) Step 3: Connect from Power BI Desktop 1. Open Power BI Desktop.2. Go to Get Data → Azure → Azure Databricks.3. In the connection dialog:   – Server Hostname: paste from Step 1   – HTTP Path: paste from Step 14. Click OK, and when prompted for credentials:   – Select Azure Databricks Personal Access Token   – Enter your token in the Password field. You’ll now see the list of Databricks tables and databases available for import. To conclude, you’ve successfully connected Power BI to Azure Databricks, unlocking analytical capabilities over your Lakehouse. This setup provides flexibility to work in Import mode for speed or Direct Query mode for live data — all while maintaining enterprise security through Azure AD or Personal Access Tokens. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Power BI is one of the most popular tools for business intelligence and reporting. But out-of-the-box reports often fall short when it comes to addressing real-world business needs. To truly maximize its potential, Power BI can be customized with advanced features like conditional formatting, multi-page designs, and Row-Level Security (RLS). In this blog, we’ll walk through a practical example of customizing a Power BI report for territory-based account analysis. Even if you’re a beginner, this guide will help you understand the steps and how you can apply them in your own reports. Problem Statement The business needed to analyze accounts by sales territory. The default Power BI report had limitations: – All territories looked the same on the map, making it difficult to differentiate them. – Managers had no easy way to drill into account-level details. – Sensitive account data was visible to everyone, creating compliance risks. Clearly, a more structured and secure approach was needed. Solution Approach Using DAX, we created a measure to assign each territory a unique color. This helped managers quickly distinguish regions on the map. 2. Multi-Page Report Design We structured the report across three pages: – Page 2 – Drill-Through Account Details: Clicking on a territory brings you here to view specific accounts. – Page 3 – Tabular Data View: A table version of Page 2 for exporting and validating data. 3. Row-Level Security (RLS) RLS was applied so each Territory Manager only sees data for their assigned region. This not only secures data but also builds trust among users. Key Learnings – Beginners can start small: apply conditional formatting to bring clarity to visuals. – Multi-page design makes reports more user-friendly than cluttering everything on one screen. – RLS is essential for real-world deployments, ensuring only the right people see the right data. To conclude, by customizing Power BI with conditional formatting, multi-page design, and Row-Level Security, even a beginner can create professional-grade reports. These enhancements transform Power BI into a secure, role-based tool that aligns with how businesses actually operate. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

Are you tired of manually writing complex DAX queries for your Power Automate flows? What if Power BI has been secretly recording every optimized query for you all along? The Challenge Every Power BI Developer Faces For growing businesses, as much as their dashboards and reports are important, automating data workflows becomes equally crucial. As organizations scale, the need to extract Power BI insights programmatically increases, making efficient query extraction essential to maintaining operational flow and development productivity. If you’re considering streamlining your Power BI to Power Automate integration process, this article is for you. I’m confident this article will guide you in mastering a Power BI technique that helps you achieve these impressive productivity gains. Key Takeaways What Exactly is Performance Analyzer? Performance Analyzer is Power BI’s built-in diagnostic tool that captures every single operation happening behind the scenes when you interact with your reports. Think of it as a detailed activity log that records not just what happened, but exactly how Power BI executed each query. Most developers use it for performance troubleshooting, but here’s the secret: it’s actually your gateway to extracting production-ready DAX queries for automation. Step 1: Unleashing the Performance Analyzer Accessing Your Hidden Toolkit The Performance Analyzer isn’t hidden in some obscure menu – it’s right there in your Power BI Desktop ribbon, waiting to revolutionize your workflow. To activate Performance Analyzer: Starting Your Query Capture Session Think of this as putting Power BI under a microscope. Every interaction you make will be recorded and analyzed. The capture process: Step 2: Extracting the Golden DAX Queries Decoding the Performance Data When you expand any visual event in the Performance Analyzer, you’ll see several components: Here’s where it gets exciting: Click on “Copy query” next to the DAX Query section. Real-World Example: Sales Dashboard Automation Let’s say you have a sales dashboard with a card showing total revenue. After recording and expanding the performance data, you might extract a DAX query like this: This is pure gold – it’s the exact query Power BI uses internally, optimized and ready for reuse! The DAX queries can be used in the following areas: To conclude, I encourage you to take a close look at your current Power BI automation processes. Identify one manual reporting task that you perform weekly – perhaps a sales summary, performance dashboard update, or data quality check. Start with this simple action today: Open one of your existing Power BI reports, activate Performance Analyzer, and extract just one DAX query. Then build a basic Power Automate flow using that query. This single step will demonstrate the power of this technique and likely save you hours in your next automation project. Need practical guidance on implementing this in your organization? Feel free to connect at transform@cloudfronts.com for specific solutions that can help you develop more effective Power BI automation workflows. Taking action now will lead to significant time savings and more robust automated reporting for your business.

Data is one of the most valuable assets for modern organizations. But without the right reporting structure, decision-makers struggle to extract meaningful insights. At CloudFronts, we specialize in tailoring Power BI to meet specific client needs. In this blog, we’ll share how we customized a territory-based account analysis report for a client’s sales team—and why such customizations deliver real business value. Problem Statement The client’s leadership team faced three challenges with their existing reports: 1. Lack of clarity: Territories on the map looked identical, creating confusion. 2. No drill-down path: Managers could not move easily from high-level territory views to account-level details. 3. Data security concerns: All managers could see all account data, raising confidentiality issues. These gaps reduced adoption of the reports and slowed decision-making. Solution Approach We delivered a tailored Power BI solution with the following enhancements: 1. High-Impact Visuals with Conditional Formatting Each territory was assigned a unique color on the map, instantly improving readability. 2. Structured Multi-Page Navigation – Page 1: Territory Map – for leadership to view performance at a glance. – Page 2: Drill-Through – for Territory Managers to analyze accounts in detail. – Page 3: Tabular Data – for operations teams to validate and export account data. 3. Data Security with Row-Level Security (RLS) Each Territory Manager could only view accounts from their assigned states, ensuring sensitive client data was protected. 4. User Adoption Focus By mirroring the real workflow of Territory Managers, adoption rates significantly increased. Key Learnings – Custom visuals drive clarity: Unique formatting makes reports intuitive. – Security builds trust: Clients are reassured when their data is properly protected with RLS. – Role-based design improves efficiency: Reports that align with how teams work reduce training needs and accelerate insights. – Better adoption leads to ROI: Customized reports quickly become part of daily decision-making, maximizing the value of Power BI investments. To conclude, for clients, Power BI customizations are not just a “nice-to-have”—they are a business necessity. By aligning reports with organizational structures, ensuring secure access, and simplifying navigation, businesses gain faster insights, stronger adoption, and higher ROI from their BI investments. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

What Is a Scorecard in Power BI? A Scorecard is a visual performance monitoring tool that allows you to track key metrics (goals) against predefined targets. Power BI’s Metrics (formerly Goals) feature helps you: Why Use Scorecards? Here’s why Scorecards are powerful for any team: Benefit Description Goal Alignment Track KPIs aligned to strategic objectives. Accountability Assign owners and collaborators for each goal. Real-time Tracking Monitor progress with live metrics. Visual Reporting Easy-to-read dashboards and history tracking. Step-by-Step: How to Build a Scorecard in Power BI Step 1: Navigate to Power BI Service Go to Power BI Service and choose the workspace where you want to create your Scorecard (Premium or Pro workspaces only). Step 2: Create a New Scorecard  You’ll now land on a blank Scorecard canvas. Step 3: Add Metrics to the Scorecard You can connect it to an existing Power BI dataset or manually input values. Step 4: Link Metrics to Data (Optional but Recommended) To automate tracking: This ensures your Scorecard updates automatically with data refreshes. Step 5: Customize the Scorecard You can also create hierarchies — group related goals under broader objectives. Step 6: Share & Collaborate Once your Scorecard is built: To conclude, Power BI Scorecards turn your data into action. They help track goals in real time, assign ownership, and keep teams focused on what matters most. Whether you’re managing a sales team, a project, or company-wide objectives — Power BI Scorecards are a game-changer for performance tracking. Want to bring visibility and accountability to your team goals? Head to Power BI Service and start building your first Scorecard today! Need help connecting metrics to your datasets? Reach out, and we’ll guide you step by step. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

Refreshing large datasets in Power BI can become time-consuming and resource-intensive as data volume grows. If your reports are based on millions of rows of historical data, refreshing everything daily is neither efficient nor necessary. This is where Incremental Refresh comes in. It allows Power BI to only refresh new or changed data, drastically improving performance and reducing load on your data source. In this blog, you’ll learn how to set up incremental refresh step-by-step—so your Power BI reports stay fast and efficient even with big data. What Is Incremental Refresh in Power BI? Incremental Refresh enables Power BI to load data in partitions, refreshing only the latest ones (e.g., the past 7 days) while keeping the older data static. Why use it? Step 1: Define Parameters in Power Query ·  Open your report in Power BI Desktop (Pro or Premium workspace) ·  Go to Transform Data (Power Query Editor) ·  Create two parameters: ·  Set default values (e.g., RangeStart = 01/01/2020, RangeEnd = 01/01/2021) Step 2: Filter Your Data with These Parameters This tells Power BI what time range to load and eventually refresh incrementally. Step 3: Enable Incremental Refresh in Data Model 📝 Example: This configuration refreshes only the recent week of data each time, while keeping the rest intact. Step 4: Publish to Power BI Service ✅ Done! You’ve now implemented incremental refresh. Best Practices To conclude, Incremental Refresh is a game-changer when it comes to handling large datasets in Power BI. It not only saves refresh time but also optimizes resource usage. By learning how to configure it properly, you can scale your reports with confidence and efficiency Got a large dataset slowing down your Power BI refresh? Implement Incremental Refresh today and see the difference. Explore more Power BI performance tips in our blog series—or reach out for help setting up enterprise-grade models. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com