Organizations today generate massive volumes of raw data from multiple sources such as ERP systems, CRMs, APIs, logs, and IoT devices. However, raw data by itself holds little value unless it is properly processed, transformed, and optimized for analytics. In our data engineering journey, we faced challenges in building scalable and maintainable ETL pipelines that could handle growing data volumes while still delivering reliable insights. Azure Databricks helped us bridge the gap between raw data and business-ready insights. In this blog, we’ll walk through ETL best practices using Azure Databricks and how they helped us build efficient, production-grade data pipelines. Why ETL Best Practices Matter When working with large-scale data pipelines: – Raw data arrives in different formats and structures– Poorly designed ETL jobs lead to performance bottlenecks– Debugging and maintaining pipelines becomes difficult– Data quality issues propagate to downstream reports Key challenges we faced: – Tight coupling between ingestion and transformation– Reprocessing large datasets due to small logic changes– Lack of standardization across pipelines– Slow query performance on analytical layers Solution Architecture Overview Key Components: – Azure Data Lake Storage Gen2– Azure Databricks– Delta Lake– Power BI / Analytics Tools ETL Flow: – Ingest raw data from source systems into the Raw (Bronze) layer– Clean, validate, and standardize data in the Processed (Silver) layer– Apply business logic and aggregations in the Curated (Gold) layer– Expose curated datasets to reporting and analytics tools Step-by-Step ETL Best Practices with Azure Databricks Step 1: Separate Data into Layers (Bronze, Silver, Gold) – Bronze Layer: Store raw data exactly as received– Silver Layer: Apply cleansing, deduplication, and schema enforcement– Gold Layer: Create business-ready datasets and aggregations This separation ensures reusability and prevents unnecessary reprocessing. Step 2: Use Delta Lake for Reliability – Store tables in Delta format– Enable schema enforcement and schema evolution– Leverage time travel for data recovery and debugging Step 3: Build Incremental Pipelines – Process only new or changed data using watermarking– Avoid full reloads unless absolutely required– Design pipelines to safely re-run without duplications Step 4: Parameterize and Modularize Code – Use notebook parameters for environment-specific values– Create reusable functions for common transformations– Avoid hardcoding paths, table names, or business rules Step 5: Optimize Performance Early – Use partitioning based on query patterns– Apply Z-ORDER on frequently filtered columns– Cache datasets selectively for heavy transformations Step 6: Implement Data Quality Checks – Validate nulls, ranges, and duplicate records– Log rejected or invalid records separately– Fail pipelines early when critical checks fail Benefits of Following These ETL Best Practices – Scalability: Easily handle growing data volumes– Reliability: ACID-compliant pipelines with Delta Lake– Maintainability: Modular and reusable code structure– Performance: Faster queries and optimized storage– Cost Efficiency: Reduced compute usage through incremental processing Conclusion Transforming raw data into meaningful insights requires more than just moving data from one place to another. By following ETL best practices with Azure Databricks, we were able to build robust, scalable, and high-performing data pipelines that deliver reliable insights to the business. If your Databricks pipelines are becoming complex, slow, or difficult to maintain, it might be time to revisit your ETL design. Start applying these best practices today and turn your raw data into insights that truly drive decision-making. 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.

Quick Preview In today’s reporting landscape, users expect highly structured, print-ready, and pixel-perfect reports. While interactive sorting works well in dashboards, paginated reports require more advanced and controlled sorting techniques-especially when dealing with grouped data, financial statements, operational summaries, or multi-level hierarchies. In this blog, we’ll explore advanced sorting scenarios in paginated reports and how you can implement them effectively for professional reporting solutions. Core Content 1. Understanding Sorting in Paginated Reports Paginated reports (built using Power BI Report Builder or SSRS) allow you to control sorting at multiple levels: Unlike Power BI dashboards, sorting in paginated reports is more structured and typically defined during report design. 2. Sorting at Dataset Level Sorting at the dataset level ensures data is ordered before it is rendered in the report. When to Use: Step-by-Step Guide to Sorting in the Paginated Report Step 1: Open report builder and design the report as per the requirements This is my report design now based on this I will sort the Name, Order Date and status Step 2: Open Group Properties –go to sorting Add sorting based on the require column Step 3: Sorting is done based on the Name, Order Date and Status Note: If date column is there then expression need to be added for the proper format. To encapsulate, advanced sorting in paginated reports goes far beyond simple ascending or descending options. By leveraging dataset-level sorting, group sorting, dynamic parameters, and expression-based logic, you can create highly structured and professional reports tailored to business need Proper sorting enhances readability, improves usability, and ensures decision-makers see insights in the most meaningful order. Ready to master advanced report design? Start implementing dynamic and expression-based sorting in your next paginated report. If you need help designing enterprise-grade paginated reports, feel free to reach out or explore more Power BI and reporting tips in our blog series. We hope you found this article useful. If you would like to explore how AI-powered customer service can improve your support operations, please contact the CloudFronts team at transform@cloudfronts.com.

Summary Customer service teams today must handle increasing support volumes while maintaining fast response times and high customer satisfaction. Traditional service models relying on emails, spreadsheets, and manual processes often struggle to scale efficiently. In this article, we explore how organizations can transform customer service operations using Dynamics 365 Customer Service, Power Platform, and Azure OpenAI to automate workflows, generate intelligent responses, and improve service efficiency. Table of Contents 1. Watch the Webinar 2. The Challenge: Scaling Customer Support 3. Operationalizing Customer Service with Dynamics 365 4. How AI is Transforming Customer Service 5. Key Benefits for Organizations FAQs Watch the Webinar In a recent CloudFronts webinar, Vidit Golam, Solution Architect at CloudFronts, demonstrated how organizations can operationalize customer service workflows using Dynamics 365 and enhance them with AI-powered responses. The session covers real-world service automation scenarios, intelligent case management, and how AI can assist support teams with contextual response generation. Watch the full webinar here: 👉 The Challenge: Scaling Customer Support Many organizations begin managing customer service through email inboxes or simple ticket tracking systems. While this approach may work initially, it becomes difficult to manage as the number of customer interactions grows. Common challenges include: 1. Customer emails being missed or delayed 2. No centralized system to track service requests 3. Lack of visibility into response times and SLAs 4. Inconsistent responses across support teams As customer expectations increase, businesses require more structured and scalable service management systems. Operationalizing Customer Service with Dynamics 365 Dynamics 365 Customer Service helps organizations bring structure, automation, and visibility to service operations. The platform enables organizations to manage cases, track service performance, and automate routine service tasks. Key capabilities include: 1. Automatic case creation from customer emails 2. Queue-based case management 3. Service Level Agreement (SLA) tracking 4. Automated case assignment 5. Real-time service dashboards 6. Customer self-service portals Instead of manually tracking service requests, inquiries are automatically converted into cases, ensuring every issue is logged, assigned, and resolved systematically. How AI is Transforming Customer Service The integration of Azure OpenAI with Dynamics 365 enables organizations to move beyond basic service management and adopt intelligent automation. AI-powered capabilities can assist support teams by: 1. Generating contextual responses for customer queries 2. Summarizing case details for faster resolution 3. Suggesting knowledge base articles 4. Automating repetitive service tasks 5. Improving response quality and consistency These capabilities help support teams handle more requests efficiently while improving the overall customer experience. Key Benefits for Organizations 1. Faster response times for customer inquiries 2. Reduced manual effort for support teams 3. Improved consistency in customer communication 4. Better visibility into service performance 5. Scalable support operations without increasing headcount FAQs Q1: Can Dynamics 365 automatically create cases from emails? Yes. Dynamics 365 Customer Service can automatically convert incoming emails into cases and route them to appropriate service queues. Q2: How does AI help customer service agents? AI can generate response suggestions, summarize case details, and recommend knowledge base articles to help agents respond faster. Q3: Can this solution integrate with existing systems? Yes. Dynamics 365 integrates with Microsoft Power Platform, Azure services, and many third-party applications. We hope you found this article useful. If you would like to explore how AI-powered customer service can improve your support operations, please contact the CloudFronts team at transform@cloudfronts.com.

Summary Many project-based organizations evaluating Microsoft solutions often ask the same question: If Microsoft Dynamics 365 Business Central already includes a project module, why do companies also use Microsoft Dynamics 365 Project Operations? This article explains the difference between the two systems, why both exist in the Microsoft ecosystem, and how integrating Project Operations with Business Central helps organizations manage project delivery and financial performance more effectively. Table of Contents 1. Why This Question Comes Up 2. Business Central: Built for Project Accounting 3. Project Operations: Built for Project Delivery 4. Why Companies Use Both 5. The Value of Integration The Outcome Why This Question Comes Up Many organizations assume Microsoft Dynamics 365 Business Central can manage all aspects of project operations because it includes the Jobs module. The Jobs module supports project budgeting, costing, and invoicing, which works well for organizations focused mainly on financial tracking. However, as projects grow more complex, involving multiple resources, time tracking, delivery planning, and client reporting, companies begin to experience limitations. This is when the difference between project accounting and project delivery becomes important. One system manages project finances. The other manages how projects are executed. Business Central: Built for Project Accounting Microsoft Dynamics 365 Business Central is an ERP system designed primarily for financial management. Its Jobs module helps finance teams track the financial performance of projects. Using Business Central, organizations can: Track project budgets and costs Manage purchase orders and project expenses Generate project invoices Monitor project profitability Handle revenue recognition and financial reporting For finance teams, this provides strong control over costs, billing, and compliance. However, financial visibility alone does not guarantee successful project delivery. Project Operations: Built for Project Delivery Microsoft Dynamics 365 Project Operations focuses on how projects are planned and executed. It provides tools specifically designed for project managers and delivery teams. Project Operations enables organizations to: Plan projects and manage tasks Schedule resources and manage capacity Track time and expenses Monitor project progress Collaborate across teams These capabilities help project managers manage people, timelines, and delivery commitments. However, Project Operations is not designed to replace an ERP system for financial management. Why Companies Use Both In most project-based organizations, different teams depend on different systems. Team Focus System Project Managers Planning and project delivery Project Operations Finance Teams Cost control, billing, accounting Business Central Trying to manage everything in a single system often creates operational friction. Project teams struggle with financial processes, while finance teams lack visibility into project execution. The Value of Integration When Microsoft Dynamics 365 Project Operations integrates with Microsoft Dynamics 365 Business Central, organizations gain the best of both systems. A typical workflow looks like this: Opportunities and project quotes are created Projects are planned and executed in Project Operations Time, expenses, and resource usage are captured Billing data flows to Business Central Finance manages invoicing and accounting This integration connects project execution with financial performance. Project managers gain operational visibility, while finance teams maintain control over billing and reporting. The Outcome Projects are delivered more efficiently Financial reporting remains accurate and compliant Manual work and duplicate data entry are reduced Project managers and finance teams work from connected data This creates a unified platform where project delivery and financial performance remain aligned. Final Thought The question is not whether Business Central can manage projects — it can. The real question is whether one system should manage both delivery and financial operations. For many organizations, combining Microsoft Dynamics 365 Project Operations with Microsoft Dynamics 365 Business Central provides the ideal balance between operational execution and financial governance. At CloudFronts Technologies, we help organizations connect Project Operations with Business Central through our PO-BC integration solution. For more information: PO-BC Integration Solution on Microsoft AppSource If you would like to discuss how this integration can support your organization, feel free to reach out to us at transform@cloudfronts.com.

In enterprise environments, securing data is not optional – it is foundational. As organizations scale their analytics with Microsoft Power BI, controlling who sees what data becomes critical. Instead of assigning access manually to individual users, modern security architecture leverage’s identity groups from Microsoft Entra ID (formerly Azure AD). When combined with Row-Level Security (RLS), this approach enables scalable, governed, and maintainable data access control. In this blog, we’ll explore how to design secure Power BI reports using Microsoft Entra ID group-based RLS. 1. What is Row-Level Security (RLS)? Row-Level Security (RLS) restricts data access at the row level within a dataset. For example: RLS ensures sensitive data is protected while keeping a single shared dataset. 2. What is Microsoft Entra ID? Microsoft Entra ID (formerly Azure AD) is Microsoft’s identity and access management platform. It allows organizations to: Using Entra ID groups for RLS ensures that security is managed at the identity layer rather than manually inside Power BI. 3. Why Use Group-Based RLS Instead of User-Level Assignment?  Individual User Assignment Challenges  Group-Based RLS Benefits This approach aligns with least-privilege and zero-trust security principles. Step-by-Step Guide to Sorting in the Paginated Report Step 1: Create group in Azure portal and select the require member Step 2: Once group is created, Go to Power BI service Step 3: Go to manage permission Step 4: Add group name, now available group member can access the report To conclude, designing secure Power BI reports is not just about creating dashboards — it is about implementing a governed data access strategy. By leveraging Microsoft Entra ID group-based Row-Level Security This approach transforms Power BI from a reporting tool into a secure, enterprise-grade analytics platform. Start by defining clear security requirements, create Microsoft Entra ID groups aligned with business structure, and map them to Power BI roles. For more enterprise Power BI security and architecture insights, stay connected and explore our upcoming blogs. 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.

This blog explains how to build a lightweight Smart Document Viewer inside a Dynamics 365 any entity form using an HTML web resource. It demonstrates how to retrieve related document URLs using Web API, handle multiple files stored in comma-separated fields, render inline previews, and implement a modal popup viewer all without building a PCF control. Overview In many Dynamics 365 implementations, business processes require users to upload and reference supporting documents such as receipts, contracts, images, warranty proofs, inspection photos, or compliance attachments. These documents are often stored externally (Azure Blob, S3, SharePoint, or another storage service) and referenced inside Dynamics using URL fields. While technically functional, the default experience usually involves: To improve usability, we implemented a Smart Document Viewer using a lightweight HTML web resource that: Although demonstrated here in a Case management scenario, this pattern is fully reusable and can be applied to any entity such as: The entity name and field schema may vary, but the implementation pattern remains the same. Reusable Architecture Pattern This customization follows a generic design: Primary Entity → Lookup to Related Entity (optional) → Related Entity stores document URL fields → Web resource retrieves data via Web API → URLs parsed and rendered in viewer This pattern supports: The entity and field names are configurable. Functional Flow Technical Implementation 1. Retrieving Related Record via Web API Instead of reading Quick View controls, we use: parent.Xrm.WebApi.retrieveRecord(“account”, accountId, “$select=receipturl,issueurl,serialnumberimage” ) Why this approach? Best Practice: Always use $select to reduce payload size. 2. Handling Comma-Separated URL Fields Stored value example: url1.pdf, url2.jpg, url3.png Processing logic: function collectUrls(fieldValue) {     if (!fieldValue) return;       var urls = fieldValue.split(“,”);     urls.forEach(function(url) {         var clean = url.trim();         if (clean !== “”) {             documents.push(clean);         }     }); } Key considerations: Advanced Enhancement: You can add: 3. Inline Viewer Implementation Documents are rendered using a dynamically created iframe: var iframe = document.createElement(“iframe”); iframe.src = documents[currentIndex]; Supported formats: The viewer updates a counter: 1 / 5 This improves clarity for users. 4. Circular Navigation Logic Navigation buttons use modulo arithmetic: currentIndex =     (currentIndex + 1) % documents.length; Why modulo? 5. Popup Modal Using Parent DOM Instead of redirecting the page, we create an overlay in the parent document: var overlay = parent.document.createElement(“div”); overlay.style.position = “fixed”; overlay.style.background = “rgba(0,0,0,0.4)”; Popup includes: Important: Always remove overlay on close to prevent memory leaks. Security Considerations When rendering external URLs inside iframe: Check: If iframe does not render, inspect browser console for embedding restrictions. Why HTML Web Resource Instead of PCF? We chose HTML Web Resource because: When to use PCF instead: Popup Modal Viewer Triggered by ⛶ button (top-right). Behaviour: No full-page takeover Error Handling Scenarios Handled conditions: Meaningful messages are displayed inside viewer container instead of breaking the form. Outcome This customization: All while keeping client data secure and architecture generic. To encapsulate, this blog demonstrates how to implement a Smart Document Viewer inside Dynamics 365 Case forms using HTML web resources and Web API. It covers related record retrieval, multi-file parsing, inline rendering, modal overlay creation, navigation logic, and performance/security best practices without exposing any client-specific data. If you found this blog useful and would like to discuss how Microsoft Bookings can be implemented for your organization, feel free to reach out to us. 📩 transform@cloudFronts.com

As organizations scale, full data reload pipelines quickly become inefficient and risky. Reporting refresh windows grow longer, source systems experience increased load, and data duplication issues begin to surface. In our recent Unity Catalog-based Lakehouse implementation, we modernized incremental data processing using a structured Change Data Capture (CDC) strategy. Instead of reloading entire datasets daily, we captured only incremental changes across CRM, ERP, HR, and finance systems and governed them through Unity Catalog. This blog explains how we designed and implemented CDC in a production-ready Lakehouse architecture, the decisions behind our approach, and the technical patterns that made it scalable. One of the first challenges in CDC implementations is avoiding hardcoded logic for every entity. Centralized Incremental Control Using Metadata Configuration Instead of embedding incremental rules inside notebooks, we designed a centralized configuration table that drives CDC dynamically. Each record in this control table defines: This allowed us to manage incremental extraction logic centrally without modifying pipeline code for every new table. Fig – Azure Storage Table showing IncrementalField and Timestamp columns Why This Matters This configuration-driven design enabled: Most CDC blogs discuss theory. Few show how incremental control is actually governed in production. Bronze Layer: Append-Only Incremental Capture Once incremental records are identified, they land in the bronze layer in Delta format. Key design decisions: The Bronze layer acts as the immutable change log of the system. This ensures: Bronze is not for reporting. It is for reliability. Structuring CDC Layers with Unity Catalog To ensure proper governance and separation of concerns, we structured our Lakehouse using Unity Catalog with domain-based schemas. Each environment (dev, test, prod) had its own catalog. Within each catalog: (Unity Catalog Bronze schema view) Why Unity Catalog Was Critical Unity Catalog ensured: CDC without governance can become fragile. Unity Catalog added structure and security to the incremental architecture. Silver Layer: Applying CDC with Delta MERGE The Silver layer is where CDC logic is applied. We implemented Type 1 Change Data Capture using Delta Lake MERGE operations. The logic follows: If a job runs twice, the data remains consistent. We intentionally chose Type 1 because reporting required the latest operational state rather than historical tracking. Handling Late-Arriving Data One common CDC failure point is late-arriving records. If extraction logic strictly uses: modified_timestamp > last_run_timeSome records may be missed due to clock drift or processing delays. To mitigate this, we: This ensured no silent data loss. Governance and Power BI Integration A key architectural decision was limiting Power BI access strictly to Gold tables. Through Unity Catalog: This ensured reporting teams could not accidentally query raw incremental data. The result was a clean, governed reporting layer powered by curated Delta tables. Performance Optimization Considerations To maintain optimal performance: Compared to full data reloads, incremental CDC significantly reduced cluster runtime and improved refresh stability. Common CDC Mistakes We Avoided During implementation, we intentionally avoided: These mistakes often appear only after production failures. Designing CDC carefully from the start prevented costly refactoring later. Business Impact By implementing CDC within a Unity Catalog-governed Lakehouse: The architecture is now scalable and future ready. To encapsulates, change data capture is not just an incremental filter. It is a disciplined architectural pattern. When combined with: It becomes a powerful foundation for enterprise analytics. Organizations modernizing their reporting platforms must move beyond full reload pipelines and adopt structured CDC approaches that prioritize scalability, reliability, and governance. If you found this blog useful and would like to discuss, ,Get in touch with CloudFronts at transform@cloudfronts.com.

Why Incremental Loads Matter When integrating data from external systems, whether it’s a CRM, an ERP like Business Central, or an HR platform like Zoho People, pulling all data every time is expensive, slow, and unnecessary. The smarter approach is to track what has changed since the last successful run and fetch only that delta. This is the core idea behind an incremental data pipeline: identify a timestamp or sequence field in your source system, persist the last-known watermark, and use it as a filter on your next API call. Azure Logic Apps, paired with Azure Table Storage as a lightweight checkpoint store, gives you everything you need to implement this pattern without managing any infrastructure. Architecture Overview Instead of one large workflow doing everything, we separate responsibilities. One Logic App handles scheduling and orchestration. Another handles actual data extraction. Core components: 3. Metadata Design (Azure Table) Instead of hardcoding entity names and fields inside Logic Apps, we define them in Azure Table Storage. Example structure: PartitionKey RowKey IncrementalField displayName entity businesscentral 1 systemCreatedAt Vendor Ledger Entry vendorLedgerEntries zohopeople 1 modifiedtime Leave leave Briefly, this table answers three questions: – What entity should be extracted?– Which column defines incremental logic?– What was the last successful checkpoint? When you want to onboard a new entity, you add a row. No redesign needed. 4. Logic App 1 – Scheduler Trigger: Recurrence (for example, every 15 minutes) Steps: This Logic App should not call APIs directly. Its only job is orchestration. Keep it light. 5. Logic App 2 – Incremental Processor Trigger: HTTP (called from Logic App 1) Functional steps: Example: This is where the real work happens. 6. Checkpoint Strategy Each entity must maintain: – LastSuccessfulRunTime– Status– LastRecordTimestamp After successful extraction: Checkpoint = max(modifiedOn) from extracted data. This ensures: Checkpoint management is the backbone of incremental loading. If this fails, everything fails. This pattern gives you a production-grade incremental data pipeline entirely within Azure’s managed services. By centralizing entity configuration and watermarks in Azure Table Storage, you create a data-driven pipeline where adding a new integration is as simple as inserting a row — no code deployment required. The two-Logic-App architecture cleanly separates orchestration from execution, enables parallel processing, and ensures your pipeline is resilient to failures through checkpoint-based watermark management. Whether you’re pulling from Business Central, Zoho People, or any REST API that exposes a timestamp field, this architecture scales gracefully with your data needs. Explore the case study below to learn how Logic Apps were implemented to solve key business challenges: Ready to deploy AIS to seamlessly connect systems and improve operational cost and efficiency? Get in touch with CloudFronts at transform@cloudfronts.com.

Scheduling meetings manually through emails can be time-consuming and inefficient, especially for organizations that handle frequent customer inquiries and consultations. A Houston-based firm was facing similar challenges, where coordinating appointments required multiple email exchanges, leading to delays and administrative overhead. To address this, we proposed and implemented Microsoft Bookings as an integrated scheduling solution within Microsoft 365. By connecting the booking system directly to their website, customers can now schedule meetings based on real-time staff availability without back-and-forth communication. The solution automatically manages confirmations, calendar updates, and Microsoft Teams meeting creation, ensuring a seamless, professional, and fully automated booking experience for both customers and internal teams. In this blog, I’ll walk you through how we configured Microsoft Bookings and how it can be used to enable effortless appointment scheduling. By the end of this guide, you’ll understand: Let’s get started. What is Microsoft Bookings? Microsoft Bookings is a scheduling solution available within Microsoft 365 that allows users to book meetings based on real-time calendar availability. It automatically: This eliminates manual coordination and ensures a consistent booking experience. How Microsoft Bookings Works Microsoft Bookings connects a public or internal booking page with users’ Microsoft 365 calendars. Here’s the overall process: This ensures a fully automated scheduling experience. Configuration Steps Step 1: Access Microsoft Bookings Step 2: Create a Booking Page This creates the base structure of your booking system. Step 3: Add Staff Members This ensures meetings are assigned correctly and availability is synced with their calendars. Step 4: Configure Services Next, configure the service being offered. You can: Enabling Teams integration ensures every booking automatically includes a meeting link. Step 5: Define Booking Permissions Choose who can access your booking page: For our implementation, selecting Anyone made the booking page publicly accessible. Step 6: Create the Booking Page Step 7: Share and Use the Booking Page URL Once created, you can: This makes appointment booking simple and accessible. Benefits of Microsoft Bookings Implementation Implementing Microsoft Bookings provides a seamless and automated way to manage appointments. From configuration to sharing the booking page, the entire process is straightforward and efficient. With just a few setup steps, organizations can enable customers and internal users to schedule meetings based on real-time availability, without manual coordination. If you’re looking to simplify your scheduling process and improve efficiency, Microsoft Bookings is a powerful solution within Microsoft 365. If you found this blog useful and would like to discuss how Microsoft Bookings can be implemented for your organization, feel free to reach out to us. 📩 transform@cloudFronts.com

In modern customer portals, simply collecting data is not enough, ensuring that the data follows real business rules is what truly makes a solution reliable. While many implementations rely heavily on client-side scripts for validation, these checks can be bypassed and often don’t reflect the actual logic enforced in CRM systems. When working with Microsoft Power Pages integrated with Microsoft Dynamics 365, implementing server-side smart rules allows organizations to enforce business policies securely and consistently. This approach ensures that validations happen where the data truly lives inside Dataverse making the portal not just user-friendly, but also trustworthy. This article walks through a practical CRM scenario to demonstrate how server logic can be used to enforce real business rules while maintaining a seamless user experience. The Real-World Scenario Imagine a customer support portal where users can raise support cases. From a business perspective, customers should only be able to create cases if they have an active support contract. Without server validation, a user could potentially bypass client-side checks and still submit a request. This creates operational issues, invalid records, and manual cleanup for support teams. To solve this, we implement a smart rule that checks contract status directly from Dataverse before allowing case creation. If the contract is inactive → The form is disabled and a message is shown If the contract is active → The user can submit the case Why Server Logic matters? Server-side validation ensures that rules are enforced regardless of how the request is submitted. Even if someone manipulates the browser or disables JavaScript, the rule still applies. This makes server logic the most reliable way to enforce entitlement checks, approval conditions, and compliance requirements. Key advantages include: How the Smart Rule works in this case? The logic is straightforward but powerful. Because the validation happens through a server query, the decision is authoritative and secure. What the User experiences? From the user’s perspective, the experience feels simple and intuitive. If their contract is inactive, they immediately see a clear message explaining why they cannot create a case. The form fields are disabled to prevent confusion. If their contract is active, they can proceed normally and submit their request without any additional steps. This balance between transparency and control creates a smooth user journey while still enforcing business rules. Server Logic vs Client Validation One of the most common questions is why server logic is necessary when client validation already exists. Client-side validation is excellent for improving usability by providing instant feedback, but it should never be the only layer of control because it can be bypassed. Server logic, on the other hand, acts as the final authority. It ensures that no invalid data enters the system, regardless of user actions. The best practice is to use both -> client validation for user experience and server logic for security. Steps to add Server Logic Step 1 – Identify the Business Rule First, clearly define what you want to validate. Example: Only allow case creation if the customer has an active support contract. This ensures you know what data needs to be checked in Dataverse. Step 2 – Create Required Table Permissions Server logic needs permission to read data from Dataverse. Go to Power Pages Management app Navigate to Security → Table Permissions Create a new permission Fill details: Save and repeat if needed for Case table. Step 3 – Create or Open Web Template This is where server logic (Liquid + FetchXML) lives. Go to Content → Web TemplatesClick NewName it:CaseCreationEligibilityCheck Paste your Liquid + FetchXML logic This template will run on the server when the page loads. Step 4 – Add FetchXML Query Inside the template, create a query to check eligibility. You’ll fetch records like: This query runs on the server and determines the outcome. When you will open the Server Logic code, you will see the default boilerplate server-side script that Power Pages generates for you when you create a new Server Script. What the boilerplate does Right now, it’s just a template; it doesn’t do any validation yet. How to adapt it for CaseCreationEligibilityCheck We want to: Here’s the code in this case:async function get() {try {// Get the current userconst contactId = Server.User.id;Server.Logger.Log(“Checking case creation eligibility for contact: ” + contactId); // Query Dataverse for active contractconst contracts = await Server.Connector.Dataverse.RetrieveRecord(“new_supportcontract”, // table namecontactId, // record id (for contact lookup, you may need a fetch query instead)“$select=new_name,statuscode”); let eligible = false;if (contracts && contracts.statuscode == 1) { // 1 = Activeeligible = true;} return JSON.stringify({status: “success”,eligibleToCreateCase: eligible,message: eligible? “You can create a new case.”: “You cannot create a new case. Active contract required.”}); } catch (err) {Server.Logger.Error(“Eligibility check failed: ” + err.message);return JSON.stringify({status: “error”,message: err.message});}} Step 5 – Add Conditional Logic Use Liquid conditions to enforce rules. If contract exists → Allow formElse → Show restriction message This ensures the UI responds based on real data. Step 6 – Attach Template to a Web Page Now connect the logic to a page. Go to Content → Web PagesOpen your Case pageSelect the Web Template you createdSave Step 7 – Test with Different Users Testing is important to validate behavior. User with active contract → Can create caseUser without contract → Sees restriction message This confirms your server rule works correctly. Step 8 – Improve User Experience Add clear messages so users understand what’s happening. Examples: Good UX reduces confusion and support calls. CRM Perspective From a CRM standpoint, this approach closely mirrors how real support entitlement works in enterprise environments. Support teams rely on accurate contract validation to prioritize requests and maintain service agreements. By enforcing these rules at the portal level, organizations ensure that only valid cases reach the support queue, reducing noise and improving response times. This also keeps portal behavior aligned with internal processes, creating a consistent experience across channels. Business Impact and Conclusion Implementing smart server rules in Microsoft Power Pages is more than a technical exercise. It’s a way to streamline operations, maintain data integrity, and … Continue reading Implementing Smart Rules in Microsoft Power Pages Using Server Logic →