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.

Power Pages, the modern evolution of Power Apps Portals, has redefined how organizations build secure, data-driven web experiences connected to Dynamics 365. But let’s be honest, for anyone who’s wrestled with the old portal setup, the journey from chaos to clarity isn’t always smooth. In this blog, I’ll share how I transformed a tangled web of client forms and scripts into a streamlined Power Pages experience using Dynamics 365 forms, Liquid templates, and JavaScript automation — and what I learned along the way. The Beginning of PortalsMy story began with what I thought was a simple request, automate a few client onboarding forms in Power Apps Portals.What followed? I realized I wasn’t managing a portal — I was managing chaos. That’s when I decided to rebuild everything in Power Pages, the modernized, secure, and design-friendly version of Power Apps Portals. Why Power Pages Changed Everything Power Pages offers a low-code, high-control environment that connects directly to Dataverse and Dynamics 365.Here’s what made it a game-changer for me: 1. Built-In Dataverse Power No more juggling SQL tables or external APIs.Dataverse made it simple to store, validate, and update client data directly within Dynamics 365 — cutting down my custom integration scripts by almost 60%. 2. Cleaner Authentication With Azure AD B2C integration, user sign-ins became seamless and secure.I could finally define granular access roles without needing custom web roles or Liquid conditionals scattered across pages. 3. Design That Doesn’t Break Your Brain The Power Pages Design Studio felt like moving from notepad to Figma — I could visually build layouts, insert lists, and add forms connected to Dynamics data without touching complex HTML. Automating Client Forms: My Aha Moment The real “Zen” moment came when I realized that automation in Power Pages didn’t need to be messy.Here’s how I approached it step-by-step: Used Dynamics 365 Forms in Power PagesEmbedded native forms from Dynamics instead of building them from scratch — they respected business rules and validation logic automatically. Applied Liquid Templates for Smart RenderingI used Liquid to conditionally show fields and sections, keeping client forms dynamic and user-friendly.Example: Added JavaScript AutomationFor client-side logic like field dependencies, autofill, and dynamic visibility, JavaScript did the trick. Because Power Pages supports modern script handling, I could isolate my logic cleanly instead of cluttering the HTML.Example: Leveraged Power AutomateIntegrated flows triggered on form submission to send confirmation emails, update records, and even notify the sales team instantly. I integrated Power Automate flows for backend actions: This separation of concerns (frontend in JS/Liquid, backend in Flows) made everything more maintainable. Design Meets Logic: Keeping It Clean One of my key lessons – separate design from logic.Power Pages Studio handled the look and feel, while all the conditional logic stayed in: This modular approach made my site easier to maintain and upgrade later. Security & Permissions Simplified Earlier, managing web roles in Portals was like untangling a spider web.Now with Power Pages: The result? A cleaner, safer, and more scalable structure. The End Result: From Chaos to Zen After weeks of trial, testing, and caffeine, my new Power Pages site was: What once required hours of manual fixes now runs seamlessly, freeing me to focus on building rather than babysitting. Happy Developing!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

Step 1: Pre-Outline Brief Target Audience: Purpose:To clarify when to use session storage vs local storage in Power Apps Portals, using a real-world use case: syncing customer dropdown selection across pages in a portal. Pain Points Solved: Step 2: Core Content Scenario Overview I was working on a customer dropdown inside a Power Apps Portal (Dashboard). When a customer was selected, I wanted: This brought up the key question: “Should I use session storage or local storage?“ Understanding Session Storage vs Local Storage Before diving into the solution, let’s break down the difference: 🔹 Session Storage 🔹 Local Storage Key difference: Problem Statement When building multi-page Power Apps Portals, we often need to carry user selections (like Account/Customer IDs) across pages. But which one should we use? Initial Approach and Issue I first used localStorage for the customer selection. While it worked across pages, it had one drawback: This confused users because they expected a “fresh start” after logging back in. Working Solution: Using Session Storage The best solution was to use sessionStorage: Power Apps Portal Code Example 1. Store customer selection in sessionStorage (Dashboard page): 2. Apply selection on another page (e.g., Contracts page): 3. Clear selection on Sign Out (SignIn page): Benefits of This Approach In Power Apps Portals, deciding between sessionStorage and localStorage depends on user expectations: In my customer dropdown scenario, sessionStorage was the clear winner, as it ensured selections synced across pages but reset cleanly at logout. Sometimes, it’s not about picking one — but knowing when to use both to balance persistence with user experience. Need help implementing storage logic in your Power Pages? Reach out to CloudFronts Technologies as I’ve already implemented this use case for syncing dropdowns between Dashboard and childpages in a Portal website. You can contact us directly 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.

Generating SSRS (SQL Server Reporting Services) reports from within Power Pages becomes more complex in environments secured by Multi-Factor Authentication (MFA). Traditional approaches that work in basic environments tend to fail silently or inconsistently when MFA, session tokens, or cookie-based auth are involved. In this blog, I’ll share a real-world solution where a Project-based SSRS report was generated securely, sent via email, and optionally downloaded — all within the constraints of a Power Pages + Power Automate architecture in a Dynamics 365 MFA-protected environment. Step 1: Pre-Outline Brief Pain Points Solved: Step 2: Core Content Scenario Overview Problem Statement Standard HTTP-based retrieval of SSRS reports using the Reserved.ReportViewerWebControl.axd endpoint fails in MFA-protected environments due to missing browser session cookies. This often results in 302 redirects or HTML-based error messages that cannot be processed by Power Automate. Initial Approach and Issue A flow was constructed to: The Project ID is captured from Power Pages and passed to a Power Automate flow using an HTTP trigger, which is initiated when a user clicks a button on the portal—triggered via embedded JavaScript. Build the SSRS report URL dynamically. Compose -> PDF Download Start – Index -> Compose -> PDF Download String Length -> Compose -> PDF Download URL -> (Replaced the PrintOnOpen=true parameter with PrintOnOpen=false in the report export URL to prevent the print dialog from automatically appearing when the PDF is opened) Perform an HTTP GET request to download the report. This failed consistently on the first try due to the report session page not being fully ready or authenticated, especially in an MFA environment. Working Solution: Retry with Delay in Power Automate To overcome the session-based delay, we implemented a retry pattern inside Power Automate: Outcome: The flow fails the first time (as expected), but succeeds on the second or third retry as the session becomes valid and the SSRS report is available. Power Automate Configuration Highlights: Added a Scope block after the first HTTP request and set the Configure run after to Skipped and Failed If needed, you can add the third delay if the second one fails. Benefits of This Approach: To conclude, sometimes, achieving reliability in secure environments isn’t about complex code—it’s about using the right orchestration patterns. By strategically delaying and retrying the HTTP request to SSRS within Power Automate, we achieved consistent, secure report generation that works even under MFA constraints. 🔗 Need help implementing this retry-based flow in your environment?Reach out to CloudFronts—we help businesses implement scalable, reliable solutions every day. You can contact us directly at transform@cloudfronts.com.

When building a Power Pages site to fetch SharePoint files, I initially relied on the official Power Pages flow trigger—“When Power Pages calls a flow.” However, the flow didn’t trigger reliably when initiated from the site. Despite proper configurations, the trigger wouldn’t execute consistently, leading to broken file fetch operations. To overcome this, I replaced the unreliable trigger with a Power Automate flow using an HTTP request trigger. This method allowed me to invoke the flow through a JavaScript function executed on page load, passing the required record ID dynamically. The HTTP approach not only worked reliably but also gave me more control over the request and response. This blog post outlines that workaround, from setting up the HTTP-triggered flow to integrating it seamlessly with Power Pages. Background and the Problem Power Pages provides a native trigger to call Power Automate flows. While ideal in theory, this approach often fails in practice due to: After spending time investigating these issues without consistent results, I decided to switch to a more controlled and universally reliable method using a HTTP trigger. My Workaround – HTTP Trigger Flow Power Automate Flow Setup: Trigger:Start with the “When an HTTP request is received” trigger. Define the request schema to accept a recordId— in this case, an orderId. Compose (Request Variables):Add a Compose action to extract the incoming ID. List Rows – Document Locations:Use Dataverse → List rows to retrieve the SharePoint Document Location related to the Order (based on the passed orderId). This assumes your files are stored in folders linked to Dataverse records. Condition – Check If Folder Exists:Use a Condition to check if any document location was found: If record exists → proceed, If no records found → terminate the flow (folder doesn’t exist). Compose – Relative URL: Compose – Folder Path:Combine the folder path: Get Files (SharePoint):Use the SharePoint Get files (properties only) action with the dynamic path set to the DocumentPath variable. Return Response:Format the SharePoint file metadata (Name, Link, Type) and send it back using the Response action. JavaScript (Executed on Page Load) Why This Works: Pros: Cons: To conclude, if you’ve faced reliability issues with native Power Pages flow triggers, the HTTP request method can be a game-changer. It enabled me to deliver a seamless experience for retrieving SharePoint files, and it can do the same for your project. In future iterations, I plan to enhance this by adding bearer token authentication and caching metadata for even faster performance. Want to integrate Power Automate flows reliably with Power Pages? Reach out to CloudFronts—we help businesses implement scalable, reliable Power Platform solutions every day. You can contact us directly at transform@cloudfronts.com.

Debugging Power Pages (formerly Power Apps Portals) can be tricky, especially when errors don’t show up clearly. One underrated but powerful method is using the browser’s “View Page Source” feature to uncover hidden issues. In this blog, we’ll explore how to use HTML source code inspection to diagnose problems in Power Pages, including: Use Case Imagine you’ve built a customer portal with dynamic content using Liquid templates, but: Manually checking each element is time-consuming. Instead, use these two pro techniques to pinpoint issues fast. Method 1: Debugging Using “View Page Source” Step 1: Access the Page Source Step 2: Check for Liquid Rendering Errors Power Pages uses Liquid templates to render dynamic content. If a Liquid snippet fails, it may appear as: Example: Debugging a Broken FetchXML Query Consider this Liquid Code in your Portal page but the data does not render In the page source, look for: This tells you the issue is table permissions, not the query itself. Method 2: Debugging Using Hidden <div> Tags If you need real-time frontend debugging, inject hidden <div> tags to display variables. Add a Hidden Debug <div> Place this in your Liquid template: Inspect with Browser DevTools <div> Example: Debugging a Missing Username If {{ user.fullname }} appears blank: Results Let’s test it – In this case, my fetchXML result is not rendering, so I wanted to verify if I have the necessary roles as well as the user information. By using your browser’s “View Page Source” feature and strategically placed hidden debug <div> tags, you can quickly uncover hidden Liquid errors, verify data rendering, and troubleshoot Power Pages issues more efficiently. These simple yet powerful techniques eliminate guesswork, help identify permission problems, and let you validate variables without disrupting the user experience – ultimately saving you valuable development time while maintaining cleaner, more reliable portals. (Pro Tip: Combine these methods with browser DevTools for even deeper debugging capabilities!) 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.

Azure Functions are a vital component of serverless computing, offering the flexibility to run event-driven code without the need to manage infrastructure. When integrated with Dynamics 365, they provide a robust mechanism for automating processes and extending the platform’s functionality. This blog explores Azure Function trigger methods and recurrence syntax, highlighting their relevance in Dynamics 365 scenarios. Azure Function Trigger Methods Azure Functions can be triggered by various events. These triggers determine how and when the function executes. Here are some commonly used trigger methods in Dynamics 365 integrations: 1. HTTP Trigger Example: 2. Queue Storage Trigger Example: 3. Timer Trigger Example: 4. Service Bus Trigger Example: Recurrence Syntax for Timer Triggers Timer Triggers in Azure Functions rely on CRON expressions to define their schedule. Understanding this syntax is crucial for scheduling Dynamics 365-related tasks. CRON Expression Format: Examples: 2. Run daily at 2:30 AM: 3. Run every Monday at 9:00 AM: Key Points: Integrating Azure Functions with Dynamics 365 To integrate Azure Functions with Dynamics 365: 4. For asynchronous processes, leverage Azure Storage Queues or Service Bus to manage workload distribution To conclude that, Azure Functions, with their diverse trigger options, provide unmatched flexibility for extending Dynamics 365 capabilities. The recurrence syntax in Timer Triggers ensures that tasks are executed precisely when needed, enabling efficient process automation. By combining these tools, organizations can unlock the full potential of Dynamics 365 in their digital transformation journey. 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.

Power Pages, which was earlier known as Power Apps Portals, a powerful low-code platform from Microsoft, allows you to create websites seamlessly integrated with Dynamics 365. Whether you’re building a customer portal, a partner collaboration site, or an internal application, Power Pages makes it easy to deliver rich web experiences. Here’s a beginner-friendly guide to help you create your first Power Pages site. What is the difference between Normal Websites and Websites Created by Power Pages? Getting Started with Power Pages: Sign in to Power Pages:To get started, sign in to the Power Pages platform using your Microsoft account. If you don’t have one, create a new account. Once signed in, you’ll be taken to the Power Pages home screen where you can begin creating your site. Create a New Site:You can start by creating a site from scratch. Choose the “Start from blank” option or use one of the available templates to speed up your development process. Templates are pre-built designs that you can customize to fit your needs. Choose a Site Name and Web Address:Select a site name that reflects the purpose of the site (e.g., “Customer Portal” or “Partner Collaboration Site”). Choose an appropriate web address (URL) that aligns with your business branding. Power Pages will guide you through the process of selecting a domain name and integrating it with your site. Configure Site Settings:Once your site is created, you’ll be able to configure various settings such as branding, theme, and layout. Power Pages provides an intuitive interface where you can adjust these settings with minimal effort. Click to edit the Power Pages using the Studio. Design and Edit Your Site:Click to open and edit your site using Power Pages Studio. This drag-and-drop interface makes it easy to add content such as text, images, forms, and data from your Dynamics 365 system. The Studio allows you to customize the site’s design, layout, and interactive elements to create a rich user experience. Let’s add a section and select the column as per your wish. Select ‘List’ Select the table and the list of records you want to see in your Webpage This appears after adding the List. There is a notification to set up permissions on the list. Click on + New permission. Let’s Add roles and click Save. Now click Sync followed by Preview. Sync feature is to make sure that the changes made in the Power Pages Studio are reflected across the platform whereas Preview feature allows you to see a live, interactive version of your website before publishing it. This gives you the opportunity to review and test how the site will look and function for end users. Also, there is another way of editing and designing Power Pages. Why do we need Power Pages Management? While Power Pages Studio is designed for creating and designing websites, focusing on content, layout, and interactivity, the Power Pages Management App provides a separate interface for managing the operational, security, and administrative aspects of the site. Key Functions of Power Pages Management: The separation of responsibilities between the design and management aspects ensures that both designers and administrators can focus on their respective tasks without compromising the site’s functionality, security, or scalability. This division enhances the overall efficiency and flexibility of managing a Power Pages website. Happy Developing! 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

In Dynamics 365, custom actions allow you to perform specific business logic, such as sending emails, making calculations, or calling external services. Often, these actions are triggered based on field updates or changes to records. However, there may be situations where you want to trigger a custom action through a button click, without modifying any record fields or triggering unnecessary updates. In this blog, we’ll explore how to use a button to trigger a custom action for a creating a specific task record in Dynamics 365 using JavaScript, that too, without modifying the record. Here’s the JS code used to trigger the action: Attach the JavaScript function to the button ‘Create Task’ event of the Case form, so that every time a case is created, the follow-up task is automatically generated. Click on the ‘Create Task’ button. And here, we have the follow up task created. Happy Developing! 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.