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.

Dynamics 365 Power Apps Portals (formerly Dynamics 365 Portals) allow organizations to securely expose CRM data to external users. However, fetching and displaying CRM records in a portal page requires more than just entity lists – it often needs custom data queries. That’s where FetchXML comes in. FetchXML is Dynamics 365’s native XML-based query language used to retrieve data and it’s fully supported in Liquid templates within portals. Step 1: Pre-Outline Brief Target Audience: How this blog helps: Step 2: Blog Outline Opening:Identify the need for FetchXML in Power Pages and its importance for developers and portal managers. Core Content: Step 3: Blog Post Introduction For businesses leveraging Microsoft Power Pages, the ability to pull dynamic data from Dataverse is critical. While out-of-the-box entity lists work for simple scenarios, complex needs — such as personalized dashboards and filtered data — require custom FetchXML queries embedded in Liquid templates. In this post, we’ll walk you through how FetchXML works in Power Pages, share examples, and provide best practices so you can deliver efficient, personalized portals. Why This Matters For growing businesses, service portals need more than just static lists. As the volume of data increases, the ability to dynamically query and display relevant information becomes essential to maintain performance, improve user experience, and reduce maintenance efforts. With FetchXML in Liquid, developers can: Prerequisites Before getting started, ensure: Understanding FetchXML FetchXML is an XML-based query language for Dataverse. It allows you to: Example: Retrieve all active contacts: Using FetchXML in Power Pages (Liquid Templates) Here’s a basic implementation: This will execute the query and display results dynamically in your portal. Making FetchXML Dynamic You can make FetchXML personalized by using Liquid variables. Example: Display cases only for the logged-in user: Real-World Example: Recent Cases Dashboard] Best Practices To conclude,FetchXML in Power Pages is a powerful tool for creating customized, dynamic, and efficient portals. Start small — add a dynamic list or dashboard to your portal today. If you need expert guidance, CloudFronts can help you implement FetchXML-driven solutions tailored to your business needs. 💡 Want to learn more? Reach out to CloudFronts Technologies at transform@cloudfronts.com to explore FetchXML use cases for your portals and improve your customer experience.

One limitation while working with MS forms is the 1 GB limit on file submission through the forms. Many of you guys are must be using Forms to get files from users or clients outside your organizations and those files can be over 1GB.  In this blog I will show you how you let users submit files over 1 GB through MS Forms and store this response into a SharePoint list. So let’s being..  Approach:   MS Form stores all the files onto your one drive, One drive also offers a feature called “Request Files” using which you can create a shareable link to a one drive folder in which anyone with the link can upload files and it has no limit over the size of the file.   So instead of using the forms upload file feature we will be using shareable link from the Request File feature on the form using which users will be able to submit documents of any size. Let’s see how to do this.  Create Shareable link to a one drive folder using Request File Feature.  Copy this link and save it we will be using this link in our MS form.  Create MS Form.  You can add the link as you want on the form you can also add it in your sections sub title (Both these are just examples or ideas of how you can show users this link.)  Stored attachments in one drive.  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.

At CloudFronts Technologies, we understand that growing organizations often operate across multiple geographies and business units. Whether you’re working with Dynamics 365 CRM or Finance & Operations (F&O), syncing data between systems can quickly become complex—especially when different legal entities follow different formats, rules, or structures. To solve this, our team developed a powerful yet simple approach: Dynamic Templates for Multi-Entity Integration. The Business Challenge When a global business operates in multiple regions (like India, the US, or Europe), each location may have different formats for project codes, financial categories, customer naming, or compliance requirements. Traditional integrations hardcode these rules—making them expensive to maintain and difficult to scale as your business grows. Our Solution: Dynamic Liquid Templates We built a flexible, reusable template system that automatically adjusts to each legal entity’s specific rules—without the need to rebuild integrations for each one. Here’s how it works: Why This Matters for Your Business Real-World Success Story One of our client’s needs to integrate project data from CRM to F&O across three different regions. Instead of building three separate integrations, we implemented a single solution with dynamic templates. The result? What Makes CloudFronts Different At CloudFronts, we build future-ready integration frameworks. Our approach ensures you don’t just solve today’s problems—but prepare your business for tomorrow’s growth. We specialize in Microsoft Dynamics 365, Azure, and enterprise-grade automation solutions. “Smart integrations are the key to global growth. Let’s build yours.” 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.

When working with Dynamics 365 CRM, one common request from users and admins is:“How do we get a Recycle Bin to recover accidentally deleted records?” Unlike SharePoint or Windows, Dynamics 365 doesn’t come with a native Recycle Bin. But that doesn’t mean you’re out of luck! There are a few smart ways to implement soft delete or restore capabilities depending on your organization’s needs. In this blog, we’ll explore all the available options — from built-in Power Platform features to custom approaches — to simulate or enable Recycle Bin-like functionality in Dynamics 365 CRM. Option 1: Use the Built-in Dataverse Recycle Bin (Preview/GA in Some Regions) Microsoft is gradually rolling out a Recycle Bin feature for Dataverse environments. How to Enable: Option 2: Implement a Custom Recycle Bin (Recommended for Full Control) You can also write a bulk delete after 15-30 days to actually clear these records from Dataverse. Option 3: Restore from Environment Backups If a record is permanently deleted, your last line of defence is a full environment restore. Not ideal for frequent recovery, but lifesaving in major accidents. Tips and Tools you can use. If you also want to track who deleted what and when, Auditing might be helpful. You cannot restore deleted records using this. It is useful only for traceability and compliance, not recovery. XrmToolBox Plugins like Recycle Bin Manager simulate soft delete and allow browsing deleted records. While Dynamics 365 CRM doesn’t provide a built-in Recycle Bin like other Microsoft products, there are several reliable ways to implement soft-delete or recovery mechanisms that fit your organization’s needs. Whether you leverage Dataverse’s native capabilities, create a custom status based Recycle Bin, or track deletions through auditing and backups, it’s essential to plan ahead for data protection and user experience. By proactively enabling recovery options, you not only safeguard critical business data but also empower users with confidence and control over their CRM operations. What’s Your Approach? Have you built your own Recycle Bin experience in Dynamics 365? Share your thoughts or tips in the comments below! 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.

In Dynamics 365 CRM implementations, subgrids are used extensively to show related records within the main form. But what if you want Subgrid B to automatically refresh whenever a new record is added to Subgrid A, especially when that record triggers some automation like a Power Automate flow or a plugin that creates or updates related data? In this blog, I’ll walk you through how to make one subgrid refresh when another subgrid is updated — a common real-world scenario that enhances user experience without needing a full form refresh. Let’s say you have two subgrids on your form: Whenever a new record is added in the Chargeable Categories subgrid, a Power Automate flow or backend logic creates corresponding records in Order Line Categories. However, these new records are not immediately visible in the second subgrid unless the user manually refreshes the entire form or clicks on the refresh icon. This can be confusing or frustrating for end-users. Solution Overview To solve this, we’ll use JavaScript to listen for changes in Subgrid A and automatically refresh Subgrid B once something is added. Here’s the high-level approach: Implementation Steps 1. Create the JavaScript Web Resource Create a new JS web resource and add the following code: How It Works To conclude, this simple yet effective approach ensures a smoother user experience by reflecting backend changes instantly without needing to manually refresh the entire form. It’s particularly helpful when automations or plugins create or update related records that must appear in real-time. By combining JavaScript with Dynamics’ form controls, you can add polish and usability to your applications without heavy customization. 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 ever needed to mark multiple quotes as lost in Dynamics 365, you know the default “Close Quote” dialog can be slow and repetitive.In my recent project, the sales team wanted a faster way, one click from the main Quotes view, to disqualify single or multiple quotes, without opening each one or clicking through extra prompts. Using the out-of-the-box CloseQuote action, a small JavaScript function, and a custom Ribbon Workbench button, I built exactly that. Here’s how. Why I Needed This Our sales team often manages multiple quotes at once. The standard process meant: It was time-consuming, especially for bulk operations. We needed a quick, grid-based action that would: Step 1 – Using the OOB CloseQuote Action Dynamics 365 provides a built-in CloseQuote bound action that changes the state and status of a quote to closed. Instead of creating a custom action, I decided to call this OOB action directly from JavaScript. Step 2 – JavaScript to Call the OOB Action Here’s the function I wrote to handle both single and multiple quotes: Step 3 – Adding the Ribbon Button in Ribbon Workbench Now, the button will be available directly on the Quotes view. Step 4 – Testing the Feature This reduced what was previously a multi-click, per-record task into a single action for any number of quotes. Why This Works Well To conclude, by combining the OOB Close Quote action with Ribbon Workbench, I could instantly disqualify quotes from the main grid, saving hours over the course of a month. If you’re looking to simplify repetitive processes in Dynamics 365, start by exploring what’s already available out of the box, then add just enough customization to make it your own. 🔗 Need help implementing a custom button or enhancing your Dynamics 365 sales process? At CloudFronts, we help businesses design and implement scalable, user-friendly solutions that streamline daily operations and improve adoption. Whether it’s customizing Ribbon Workbench, integrating OOB actions, or building tailored automation, our team can make it happen. 📩 Reach out to us at transform@cloudfronts.com and let’s discuss how we can optimize your Dynamics 365 environment.

Why This Matters Imagine you’ve just delivered an order, and now there’s a service issue or repair request from the customer. What’s the best way to track and resolve that? That’s where Cases come in. This blog walks you through how your company can use Cases in Dynamics 365 CRM to efficiently handle post-delivery service and repair requests—directly linked to the order fulfillment process for better visibility and control. Let’s break it down step by step. Step 1: Navigate to Cases from an Order Fulfillment Record Start by opening the Order Fulfillment record.Click on the “Related” dropdown and select “Cases” from the list. This takes you directly to all service cases related to that order. Step 2: Create a New Case Click on the “New Case” button in the Cases tab. A Quick Create: Case form appears. Here’s what you’ll see and fill in: Optional fields like Contact, Origin, Entitlement, and others can be filled in if needed.You can also include details such as First Response By, Resolve By, and Description, depending on your business requirements. Once done, hit Save and Close. Step 3: View All Related Cases After saving, you’ll see a list of all Cases associated with the order under the Case Associated View. Each entry includes key info like: This makes it easy to monitor all service activity related to an order at a glance. Step 4: Manage Case Details Click on any Case Title to open the full Case record. From here, you can: Step 5: Monitor Service Performance Navigate to Dashboards > Service and Repair to track ongoing Case performance. Here’s what you’ll see: This allows your company’s service team to monitor progress, manage workload, and identify recurring product or fulfillment issues. To conclude, by following this process, your company ensures that every post-delivery service or repair request is captured, tracked, and resolved—while keeping everything connected to the original order. It’s simple, efficient, and fully integrated into Dynamics 365 CRM. Hope this helps!!! 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.

Dynamics 365 CRM provides an Out-of-the-Box (OOB) Business Closures feature to define non-working days across your organization. However, in many real-world scenarios, we often face limitations with the default interface in terms of customization, UX/UI control, or extensibility. In this blog post, I’ll Walk you through how you can replace the OOB Business Closures using a custom HTML + CSS + JavaScript web page embedded in Dynamics 365. This custom page will interact with a custom Dataverse table that stores your closure dates and related details. Why Replace the OOB Business Closures? Some of the common limitations of OOB Business Closures: What We’ll Build A custom web resource embedded in a Dynamics 365 CRM dashboard or form tab that: Step-by-Step Implementation 1. Create a Custom Table in Dataverse 2. Create the HTML Web Resource 3. Upload as Web Resource in CRM Benefits of this Approach – Fully customizable UI -Supports additional metadata (reason, region, team) -Extensible for APIs, workflows, Power Automate, etc. -Better UX for users with real-time interactivity To conclude, by using a simple HTML, CSS, and JavaScript front end, we can extend Dynamics 365 CRM to manage business closures in a much more flexible and modern way. It not only overcomes the limitations of the OOB feature but also gives us complete control over the user experience and data model. 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.

Imagine this: you update a product’s purchase date in a registration record and—boom—a related case automatically gets refreshed with the accurate “Purchased From” lookup. Saves time, reduces errors, and keeps everything in sync without you lifting a finger. Let’s walk through how to make that happen using Power Automate. The goal: When a Product Registration’s cri_purchasedat field is changed, the system will retrieve the related “Purchased From” record and update any linked Case(s) with the appropriate lookup reference. Let’s break down the step-by-step process of how this is done in Power Automate. Step 1: Trigger the Flow When Purchase Date Changes Flow trigger: When a row is added, modified, or deleted (Dataverse) This setup ensures that our flow only fires when that specific date field is modified. Step 2: Pull in the “Purchased From” Record Next, use List rows on the “Purchased From” table with a FetchXML query. We’re searching for a record whose name matches the updated cri_purchasedat. Set Row Count to 1, since we expect only one match. 3. Identify Any Linked Case Records Add another List rows action, this time on the Cases table. We look for records where cri_productregistrationid equals the current product registration’s ID:We now use the List Rows action to fetch all related Case records tied to the updated Product Registration. This time we’re targeting the Cases table (which is internally incident in Dataverse) and using a FetchXML query to match records where cri_productregistrationid equals the current record being modified. This step is critical because it gives us the list of Case records we need to update, based on the link with the modified product registration. <fetch> <entity name=”incident”>     <attribute name=”incidentid” />     <attribute name=”title” />     <attribute name=”cf_actualpurchasedfrom” />     <filter>       <condition attribute=”cri_productregistrationid” operator=”eq” value=”@{triggerOutputs()?[‘body/cri_productregistrationid’]}” />     </filter>  </entity></fetch> 5. Before updating anything, we add a Condition control to ensure that our previously fetched Purchased From record exists and is unique. Why? Because if there’s no match (or multiple matches), we don’t want to update the Cases blindly. We check if this length equals 1. If true → move forward with updates.If false → stop or handle the exception accordingly. To conclude, this kind of validation builds guardrails into your automation, making it more robust and preventing incorrect data from being applied across multiple records. After confirming a valid match, the flow loops through each related Case and updates the “Actual Purchased From” field with the correct value from the matched record, ensuring accurate linkage based on the latest update. Once this step runs, your staging automation is complete—with Cases now intelligently updated in real-time based on Product Registration changes. 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.