Summary A Netherlands-based sustainability certification non-profit faced a key limitation in Dynamics CRM: the default subgrid had no way to filter related lookup values — meaning all versions and levels appeared for every certification standard, regardless of relevance. CloudFronts replaced the default subgrid with a custom HTML Web Resource that renders each certification standard as an interactive card, with its own pre-filtered version and level dropdowns. Users selecting C2C Certified® Full Scope now only see versions and levels that belong to Full Scope — not a cluttered list of every record in the related table. Beyond fixing the filtering gap, the solution transformed the CRM form experience from a flat, generic grid into a clean, modern card-based interface — significantly improving usability for both applicants and assessors. Table of Contents   1. Customer Scenario 2. The Real Problem — Unfiltered Lookups in Subgrids 3. Solution Overview 4. Key Features of the Custom Web Resource 5. How It Works — Technical Implementation 6. End-to-End Walkthrough 7. Architecture & Design Decisions 8. Business Impact 9. FAQs 10. Conclusion Customer Scenario A Netherlands-based non-profit organization uses Dynamics CRM to manage the full certification application lifecycle, from initial scoping through assessment and final issuance. As part of every certification application, users must define a Certification Scope, selecting which Cradle to Cradle standards they want assessed, choosing the correct version of that standard, and setting a target certification level. The available standards include: Full Scope Material Health Circularity Each standard has its own set of applicable versions and certification levels stored in related Dataverse tables. The challenge was making sure users could select and configure each standard correctly — without the CRM form showing them irrelevant data from other standards. The Real Problem, Unfiltered Lookups in Subgrids The original design used a default CRM subgrid to list the certification scope lines. Each row in the subgrid had lookup fields pointing to related Dataverse tables, one for Standard Version, one for Certification Level. The problem was straightforward but significant: CRM subgrid lookup fields have no native mechanism to filter their values based on another field in the same row. This meant that when a user opened the Version lookup on a Full Scope row, they saw every version across every standard — Full Scope versions, Material Health versions, Circularity versions, all mixed together in a single unfiltered list. The same issue applied to Certification Levels. There was no built-in way to say: “this row is for Full Scope — only show me Full Scope versions.” Key Pain Points Wrong version selected by mistake: With all versions in one unfiltered list, users had to manually identify and pick the correct one — easy to get wrong, especially for new staff unfamiliar with which version belongs to which standard. Cluttered, confusing lookup lists: A lookup showing 20+ mixed records when the user only needs to choose from 3–4 relevant options is a frustrating experience and a source of data quality issues. No visual structure or grouping: The default subgrid renders as a flat table. There is no way to visually distinguish one standard from another or understand the overall scope at a glance. A form that did not match the product’s quality: The client wanted their CRM environment to feel professional and polished — a plain, out-of-the-box grid did not meet that expectation. The subgrid was not broken — it was simply the wrong tool for this job. What was needed was a control that understood the relationship between a standard and its versions, and filtered accordingly. Solution Overview CloudFronts replaced the default subgrid entirely with a custom HTML Web Resource embedded directly on the CRM application form. The web resource reads a single JSON field on the record which carries each standard along with its own pre-scoped list of versions and levels. The core idea: Each certification standard gets its own card  →  Each card shows only the versions and levels that belong to that standard  →  No more mixed, unfiltered lookup lists   What This Achieves For Applicants and Assessors: Select one or more certification standards using clear, visual checkbox cards See only the versions relevant to the selected standard — nothing from other standards Choose a target level from a correctly filtered, correctly sorted dropdown Get instant visual feedback on which standards are active in the scope For the CRM Platform Team: No subgrid lookup filtering workarounds, form-level JavaScript hacks, or plugin-based filtering required All filtering is naturally handled by the JSON data structure, each standard row already carries only its own versions and levels A significantly better-looking form that reflects the quality of the certification program itself Scope configuration can be extended simply by updating the JSON, no schema changes needed Key Features of the Custom Web Resource The web resource was designed with two clear goals: solve the filtering problem correctly, and make the form experience noticeably better. Here is how each feature serves those goals.   1. Card-Per-Standard Layout with Checkbox Selection Each certification standard is rendered as its own self-contained card — with a title, a short description of what that standard covers, and a checkbox. This immediately solves the visual grouping problem that a flat subgrid cannot address. Clicking a card (or its checkbox) marks that standard as In Scope The selected card highlights with a blue left-border accent and a soft background tint — making it immediately clear which standards are active Deselected cards remain compact and unobtrusive, keeping the form clean For assessors reviewing multiple applications, being able to scan the full scope at a glance — without opening related records or reading through a grid — is a meaningful time saving.   2. Filtered Version Dropdown — Per Standard This is the feature that directly solves the original problem. When a card is selected and expands, the Standard Version dropdown is populated exclusively from the versions array within that standard’s JSON row. A user working on a Full Scope card sees only Full Scope versions A user working … Continue reading From Default to Dynamic: Transforming Dynamics CRM Subgrids with Custom HTML for a Netherlands-Based Sustainability Certification Non-Profit →

Summary A US-based oil & gas cybersecurity firm implemented a mobile-first Canvas App integrated with Dynamics 365 Project Operations to unify time, expense, and material submission, tracking, and approval. The solution enabled project-specific approval workflows where only assigned approvers could validate submitted records. CloudFronts introduced a dual-mode interface (Day Mode and Week Mode) to improve usability for both field engineers and managers. Submission and approval cycle time reduced from hours/days to near real-time visibility. Table of Contents 1. Customer Scenario 2. Solution Overview 3. Key UX Features 4. Functional Implementation 5. Solution Walkthrough 6. Architecture & Integration Approach 7. Business Impact 8. FAQs 9. Conclusion Customer Scenario A Texas-based cybersecurity firm specializing in operational technology (OT) security for oil rigs manages multiple concurrent field projects using Dynamics 365 Project Operations. Employees and resources were responsible for logging: Time entries Expense entries (travel, accommodation, airfare, etc.) Material usage logs (equipment, parts, consumables, etc.) However, the system was not designed for mobile-first usage, and processes were fragmented across multiple interfaces. Key Challenges Field engineers & other Resources could not efficiently submit entries from mobile devices Time, expense, and material tracking existed in separate workflows Approval processes had to be restricted to project-specific stakeholders Project managers lacked real-time visibility into resource usage • Delays in submission can cause downstream billing and reporting issues Project tracking accuracy can get compromised, and reporting delays directly affected client communication and billing cycles. Solution Overview CloudFronts designed and deployed a unified mobile application using Power Apps (Canvas Apps) integrated with Dynamics 365 Project Operations. Objective: One app → All submissions → Controlled approvals → Real-time visibility What the App Enables For Field Users: Submit time entries (daily or weekly) Create expense entries with receipt validation Log material consumption against projects Track submission status instantly For Project Approvers: View only entries related to assigned projects Approve or reject submissions directly from mobile Maintain audit-ready approval workflows Key UX Features The application is designed with a strong focus on usability for both resources and project approvers, ensuring a seamless mobile experience across submission and approval workflows. 1. Day Mode / Week Mode Toggle The app provides a flexible entry experience through a dual-mode interface: Day Mode: Enables detailed entry for a single day, ideal for precise logging and corrections. Week Mode: Allows bulk entry across multiple days, reducing effort for repetitive data entry. This flexibility significantly improves usability across different working styles and scenarios. 2. Calendar-Based Swipe Navigation The application introduces a Dynamics-style calendar navigation with swipe support, allowing users to: Traverse across multiple days or weeks effortlessly View and manage multiple submission records in sequence Navigate between historical and current entries with minimal effort This mobile-first interaction design reduces friction in high-frequency data entry scenarios. 3. Unified Submission & Approval Experience The UI/UX is intentionally designed to mirror the complete lifecycle of a record, ensuring consistency between submission and approval stages. Each record follows a structured lifecycle aligned with Dynamics 365 stages: Submitted Pending Approved Rejected Recall Requested Recall Request Approved Recall Request Rejected The interface dynamically adapts based on the current stage: Action buttons (Approve, Reject, Recall, etc.) are conditionally visible Status indicators are clearly displayed Users experience the same structured flow from creation to closure This ensures clarity, reduces errors, and improves user confidence in the system. 4. Dynamic Action-Based UI (Smart Button Behavior) The app intelligently modifies UI controls based on record state: Submit button appears only for draft entries Approve/Reject buttons are visible only to project approvers Recall option is available only after submission Post-approval states restrict further edits This enforces role-based and state-based control, preventing invalid actions and maintaining process integrity. 5. Conditional Receipt Upload for Expense Entries Expense submission logic is enhanced with category-driven validation: Mandatory: Airline tickets, OT hardware purchases Optional: Meals, local travel This balances compliance requirements with user convenience, avoiding unnecessary friction. 6. On-Demand Data Refresh Users can manually refresh data within the app to: Fetch the latest submission and approval statuses Sync newly created or updated records Ensure real-time visibility without relying solely on background refresh Especially useful in environments with intermittent connectivity. 7. Mobile-First Interaction Design Touch-friendly controls Swipe navigation Lightweight screens for faster performance Minimal navigation depth This ensures field engineers working in remote or on-site environments can operate efficiently. Functional Implementation This section outlines how the solution was implemented within Dynamics 365 Project Operations and the Power Platform to enable end-to-end submission and approval management. 1. Unified Data Model in Dataverse All three entry types — Time, Expense, and Material — are structured within Dataverse and linked to: Project Resource (User) Approval records Supporting documents (for expenses) Each submission creates a corresponding record with a defined lifecycle stage, ensuring consistency across all entry types. 2. Submission Logic from Canvas App Each submission type follows a structured flow: User selects project and entry type (Time / Expense / Material) Required fields are validated based on entry type Conditional logic enforces: Receipt requirement (for specific expense categories) Mandatory fields (based on business rules) Record is created in Dataverse Submission triggers backend approval workflow This ensures that all records entering the system are complete, validated, and ready for approval processing. 3. Approval Record Creation & Routing Upon submission: A corresponding approval record is automatically created The system identifies project-specific approvers Key behavior: Only assigned project approvers can view and act on records Approval actions update the main record status 4. Record Lifecycle Management (Status-Driven System) Lifecycle: Draft → Submitted → Pending → Approved / Rejected → Recall Flow Users submit records → moves to Submitted Approvers review → Approved or Rejected Users request recall → Recall Requested Approvers respond → Recall Approved or Rejected Controlled through: Power Apps UI logic MS Bound Actions for submission and approval handling Dataverse status fields 5. Expense Receipt Handling (Integrated from Previous Solution) Receipt upload enforced conditionally Files stored as Notes (Annotations) in Dataverse Linked to expense records This eliminates manual document handling and ensures compliance. Solution Walkthrough The following walkthrough … Continue reading How We Built & Deployed a Mobile-Based Canvas App for Unified Time, Expense (with Receipts) & Material Submission with Project-Based Approvals for a US Cybersecurity Firm →

Summary A window and door manufacturing company based in the United States, specializing in energy-efficient fenestration products, eliminated brittle hard-coded email recipients from their sales automation by adopting a Dataverse-driven approach in Power Automate. CloudFronts implemented a dynamic recipient resolution pattern using coalesce and createArray expressions, pulling the To and CC parties directly from opportunity record lookups in Microsoft Dynamics 365 CRM. The solution handles null lookups gracefully, scales as team structures change, and requires zero flow edits when personnel or roles shift. Business impact: Reduced flow maintenance overhead, eliminated misdirected emails caused by stale hard-coded addresses, and established a reusable pattern applicable across multiple automation scenarios. About the Customer The customer is a U.S.-based manufacturer of custom steel windows and doors, serving commercial, residential, and architectural projects. Established in the mid-1980s, the company specializes in high-performance, energy-efficient fenestration systems designed for both modern and heritage applications. They rely on Microsoft Dynamics 365 CRM to manage their sales pipeline, opportunity tracking, and customer communications across a distributed sales network. Their sales process involves multiple stakeholders per opportunity, including an opportunity owner, primary customer contact, forwarding representative, and regional sales representative, all of whom may need to be included in outbound communications at different stages of the deal lifecycle. The Challenge When the organization first automated opportunity-related emails through Power Automate, recipient addresses were defined statically inside the flow. A specific mailbox was hard-coded as the CC address, and To recipients were manually entered per scenario. This approach worked initially but quickly became a source of ongoing problems: Stale recipients: When team members changed roles or left the organization, flows continued sending emails to incorrect or inactive addresses, requiring a developer to open the flow and update it manually every time. No relationship to CRM data: The recipient list in the flow had no connection to who was actually assigned to the opportunity in Dynamics 365 CRM. The two could easily fall out of sync. Scalability and maintenance burden: As the number of automated flows grew, so did the number of places where email addresses were hard-coded. A single personnel change could require updates across multiple flows, increasing both effort and the risk of missing one. Inability to handle variable stakeholders: Not every opportunity has the same set of involved parties. Some have a forwarding representative, others do not. Some have a dedicated sales representative assigned, while others rely only on the owner. A static recipient list cannot handle this variability. The organization needed a recipient model that was driven entirely by what was recorded in CRM, not by what a developer had typed into a flow months earlier. The Solution CloudFronts redesigned the email automation to resolve all recipients dynamically at runtime, using lookup field values from the opportunity record in Dataverse. No email addresses are stored in the flow itself. Technologies Used Microsoft Dynamics 365 CRM, Source of opportunity data, ownership, and stakeholder relationships Power Automate, Orchestration layer for the email automation Dataverse connector, Real-time retrieval of opportunity record and related lookup fields Email activity (CRM), Target entity for structured email creation with party list support What CloudFronts Configured The flow fetches the opportunity record from Dataverse as its first action after the trigger. From that single record, four lookup fields are evaluated, the record owner (_ownerid_value), the opportunity contact (_cf_opportunitycontact_value), a forwarding sales representative (_ow_forwardingtosalesrep_value), and the primary sales representative (_ow_salesrep_value). Each lookup is conditionally included in the recipient array only if it is not null. If a lookup field has no value on a given opportunity, it is excluded entirely, the flow does not error, and no placeholder address fills the gap. The recipient array is constructed using a single coalesce + createArray expression, producing a clean party list that is passed directly into the email activity creation step. The participationtypemask value distinguishes the To recipient (mask 1, the owner via systemusers) from CC recipients (mask 2, contacts). Power Automate Flow Walkthrough The diagram above illustrates the end-to-end structure of the flow. Below is a breakdown of each stage. Step 1, Trigger The flow is triggered by a CRM event such as an opportunity stage change, a manual button, or a scheduled recurrence. Step 2, Get opportunity record A Dataverse action retrieves the full opportunity record including all lookup fields. Step 3, Build the recipients array This is the core of the solution: coalesce( createArray( if( not(equals(outputs(‘Get_Opportunity_Record’)?[‘body/_ownerid_value’], null)), json(concat( ‘{"participationtypemask": 1,"partyid@odata.bind": "systemusers(‘, outputs(‘Get_Opportunity_Record’)?[‘body/_ownerid_value’], ‘)"}’ )), null ), if( not(equals(outputs(‘Get_Opportunity_Record’)?[‘body/_cf_opportunitycontact_value’], null)), json(concat( ‘{"participationtypemask": 2,"partyid@odata.bind": "contacts(‘, outputs(‘Get_Opportunity_Record’)?[‘body/_cf_opportunitycontact_value’], ‘)"}’ )), null ), if( not(equals(outputs(‘Get_Opportunity_Record’)?[‘body/_cf_forwardingtosalesrep_value’], null)), json(concat( ‘{"participationtypemask": 2,"partyid@odata.bind": "contacts(‘, outputs(‘Get_Opportunity_Record’)?[‘body/_cf_forwardingtosalesrep_value’], ‘)"}’ )), null ), if( not(equals(outputs(‘Get_Opportunity_Record’)?[‘body/_cf_salesrep_value’], null)), json(concat( ‘{"participationtypemask": 2,"partyid@odata.bind": "contacts(‘, outputs(‘Get_Opportunity_Record’)?[‘body/_cf_salesrep_value’], ‘)"}’ )), null ) ) ) Each lookup is checked for null and included only when present, producing a clean, variable-length recipient list from CRM data. Step 4, Null checks per lookup Missing stakeholders are simply excluded without breaking the flow. Step 5, Create email activity The recipient list is passed into Dataverse email activity creation. Step 6, Email sent Recipients are resolved dynamically from CRM data at runtime. Business Impact Metric Before After Recipient source Hard-coded in flow Live from CRM opportunity record Personnel change handling Manual flow edit required Automatic, CRM update is sufficient Variable stakeholder support Not possible Supported natively Misdirected email risk High Eliminated Flow maintenance effort Per-change developer intervention None for recipient changes The organization now operates email automation where the flow itself never needs to be edited when team structures shift. Updating the opportunity record in CRM is the single source of truth, and the flow responds accordingly at runtime. Frequently Asked Questions What if all lookup fields are null on an opportunity? The createArray expression will produce an array of null values, and coalesce will return an empty or minimal array. It is recommended to add a condition step before the email creation to check that at least one valid recipient exists and to handle the empty case, such as logging a CRM note or notifying an administrator, rather than … Continue reading Stop Hard-Coding Recipients: Streamlining Email Automation with Dataverse and Power Automate for a U.S.-Based Window and Door Manufacturer →

Summary A non-profit sustainability certification organization reduced CRM complexity by replacing multiple custom entities with a JSON-based data structure in Microsoft Dynamics 365 CRM. CloudFronts implemented a custom HTML interface to dynamically render input fields and manage document uploads within a single, unified UI. The approach eliminated repeated schema changes, reduced admin overhead, and enabled faster adaptation to evolving certification requirements. Business impact: Reduced CRM customization overhead, accelerated onboarding of new certification types, and a more maintainable solution that scales without structural rework. About the Customer The customer is a non-profit organization focused on sustainability certification across industries. They operate across multiple certification programs, each with distinct documentation requirements, input fields, and approval workflows. Their team relies on Microsoft Dynamics 365 CRM as the central platform for managing certification applications, applicant data, and compliance records. The Challenge Microsoft Dynamics 365 CRM is built for structured data — but not all business processes follow fixed structures. The organization managed several certification programs, each requiring different sets of input fields, document uploads, and validation logic. Initially, each new certification type was handled by creating a new custom entity or modifying existing ones to accommodate the required fields. While this worked for a small number of programs, the approach quickly revealed significant limitations: Schema rigidity: Every time a new certification type was introduced, or an existing one updated, the CRM schema had to be modified. This meant new fields, new relationships, and repeated deployment cycles. Administrative overhead: Each schema change required coordination between developers and CRM administrators, creating delays and dependency bottlenecks. Inconsistent UI experience: With different entities handling different certification types, the user interface lacked consistency. Applicants and internal users faced a fragmented experience depending on which program they were working in. Scalability ceiling: The entity-per-program model was not designed to scale. Adding a tenth or fifteenth certification type would exponentially increase the complexity of the CRM data model. Document management friction: Handling document uploads across multiple entities was cumbersome, with no unified approach to tracking submission status or linking files to the correct certification record. The organization needed a solution that could accommodate evolving certification structures without requiring constant schema modifications or developer intervention. The Solution CloudFronts redesigned the data architecture by replacing the multi-entity model with a JSON-based structure stored within Dynamics 365 CRM, paired with a custom HTML interface to dynamically render the appropriate fields and manage document workflows. Technologies Used Microsoft Dynamics 365 CRM, Core platform for certification records, applicant data, and workflow management JSON, Flexible data structure for storing dynamic certification inputs within a single CRM field Custom HTML with JavaScript, Dynamic front-end interface rendered within the CRM form, replacing static entity-based layouts Power Automate, Supporting workflows for notifications, approvals, and document status updates What CloudFronts Configured Rather than creating a separate entity for each certification type, CloudFronts introduced a single Certification Application entity with a dedicated JSON field to store all variable inputs. A configuration-driven approach was used, each certification type is defined by a schema that specifies which fields to show, what validations to apply, and which documents are required. The custom HTML interface reads this configuration at runtime and dynamically renders the correct form, no code changes required when a new certification type is added or an existing one is modified. The same interface handles document uploads, linking each file to its corresponding certification record and tracking submission status in real time. CloudFronts also implemented role-based visibility within the HTML component, ensuring that internal reviewers, applicants, and administrators each see only the sections relevant to their function. Business Impact Metric Before After Adding a new certification type Requires schema changes and deployment Configuration update only UI consistency Fragmented across entities Unified interface for all programs Developer dependency High, every change needed development effort Low, administrators manage configurations Document tracking Manual, per entity Centralized and automated CRM data model complexity Growing with each program Stable and maintainable The organization can now onboard new certification programs in a fraction of the time, without touching the underlying CRM schema. Internal teams manage certification configurations independently, and the development team focuses on feature improvements rather than reactive schema maintenance. Frequently Asked Questions When should I use JSON instead of CRM entities? JSON is a strong fit when input structures vary frequently, differ across record types, or are driven by business rules that change regularly. If your data model is stable and relational, entities remain the better choice. Is it possible to query or filter on JSON data in CRM? Direct filtering on JSON fields in Dynamics 365 is limited. CloudFronts structured the solution so that key filterable attributes, such as certification type, status, and applicant ID, remain as standard CRM fields, while the variable payload lives in JSON. Does the custom HTML approach work on mobile? Yes. The HTML web resource is built to be responsive and functions within the Dynamics 365 mobile app, though optimal use is on desktop given the complexity of certification forms. Can this approach support approval workflows? Yes. Power Automate workflows trigger based on standard CRM field changes, such as status updates, and do not depend on the JSON structure, keeping workflow logic clean and maintainable. Conclusion Not every data problem in CRM needs a new entity. When business requirements are variable and evolving, as they often are in certification, compliance, and document-heavy workflows, a rigid entity model can become a liability rather than an asset. By combining JSON-based storage with a dynamic HTML interface, CloudFronts helped this organization build a CRM solution that adapts to change without requiring structural rework. The result is a leaner data model, a more consistent user experience, and a team that can move faster because they are no longer dependent on developer cycles for every process update. Sometimes the best CRM architecture is the one that knows when not to add more to the schema. We hope you found this article useful. If you would like to explore how AI-powered customer service can improve your support … Continue reading Stop Creating Entities: Simplifying CRM with JSON and Custom HTML for a Sustainability Certification Non-Profit in the Netherlands →

Summary A services firm based in Houston, Texas, specializing in enterprise security solutions, improved operational efficiency by transitioning from Excel-based reporting to Power BI Paginated Reports, implemented by CloudFronts. CloudFronts designed a structured, client-ready reporting solution integrated with Dynamics 365 CRM. The solution supports manual distribution today while being fully prepared for future automation such as scheduled PDF delivery. Business impact: Improved operational efficiency, standardized reporting, and scalability without rework. Client-ready account statement using Power BI Paginated Reports About the Customer As a 9x Microsoft Gold Partner and 6x Microsoft Advanced Specialization-endorsed organization based in Texas, U.S., the customer specializes in delivering solutions for critical business needs across systems management, security, data insights, and mobility. The Challenge Initially, the organization generated account statements manually using Excel for a small number of clients. While this approach worked at a smaller scale, it presented several limitations: Manual effort and inefficiency: Reports had to be created individually for each client. Lack of standardization: Formatting and structure varied across reports. Scalability concerns: While effective for a small client base, the process was not designed to scale as the business grows to 30–50+ clients. Technology decision gap: The team required guidance on choosing between SSRS and Power BI Paginated Reports, along with future automation capabilities. As a result, the organization needed a solution that addressed current inefficiencies while preparing for future scale. The Solution CloudFronts implemented Power BI Paginated Reports, integrated with Dynamics 365 CRM, to create structured, print-ready account statements. Technologies Used Dynamics 365 CRM — Source of funding, account, and transaction data Power BI Paginated Reports — Designed pixel-perfect, client-facing statements Power BI Service — Enabled hosting and future automation capabilities What CloudFronts Configured CloudFronts designed a paginated report tailored for client communication, including account summaries, transaction-level details, and allocation tracking. The solution includes parameterized filtering for month, account, and funding status, enabling efficient report generation across multiple clients. The report was built with a strong emphasis on consistency, print-ready formatting, and reusability—ensuring that reports can be generated without redesign as the business grows. CloudFronts also guided the customer in selecting Power BI Paginated Reports over SSRS to ensure better alignment with the Power BI ecosystem and support for future automation such as subscription-based PDF delivery. Key Implementation Decisions Replacing Excel with Paginated Reports: Improved standardization and reduced manual effort. Choosing Paginated Reports over SSRS: Enabled seamless integration with Power BI Service and future automation readiness. Designing for scalability: Built a solution that works manually today but supports automation in the future. Business Impact Metric Before After Report Creation Manual Excel-based System-generated reports Operational Efficiency Low Significantly improved Scalability Limited Ready for growth Consistency Variable Standardized The organization now operates with a structured reporting system that reduces manual effort while being fully prepared for future automation. Frequently Asked Questions Should I use SSRS or Power BI Paginated Reports? If you are using Power BI, Paginated Reports are a better choice due to seamless integration and future automation support. Can I automate PDF report delivery later? Yes. Paginated Reports support subscription-based delivery for automated PDF emails. Do I need automation from day one? No. It is more effective to design a scalable solution first and introduce automation as the business grows. Conclusion This implementation highlights that effective reporting is not just about automation—it is about designing for scalability from the beginning. By choosing Power BI Paginated Reports, the organization built a solution that meets current needs while avoiding future rework as they grow. Not every reporting requirement needs a dashboard or immediate automation. A well-designed structured report can often be the most scalable solution. Read the full case study here: Invoke 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 us at transform@cloudfronts.com. Deepak Chauhan | Consultant, CloudFronts

Summary This blog highlights the integration of Microsoft Dynamics 365 Customer Service Hub with FedEx Shipping Manager to handle automated email return shipments for a consumer electronic appliances company based in Massachusetts, USA. In the original process, customer service representatives were required to manually register each return shipment through the FedEx Shipping Manager portal. This process involved copying customer details, creating shipments, generating labels, and capturing tracking numbers — a workflow that typically required 20–30 minutes per request. The integration project automated the entire return shipment process directly within the Dynamics 365 Customer Service Hub. With a single click, the system now registers the shipment using FedEx Shipment APIs, generates a return label, captures the tracking number, and updates the case record automatically. This innovation eliminated the need for agents to switch between systems and reduced shipment registration time from 20–30 minutes to just a few seconds, significantly improving operational efficiency and the overall customer service experience. This blog explains: 1] The operational challenges caused by manual shipment registration. 2] How Dynamics 365 Customer Service Hub was integrated with FedEx Shipping Manager. 3] The functional workflow used to automate shipment creation. 4] How customer service representatives trigger shipments directly from CRM. 5] The business impact achieved through automation and system integration. Table of Contents 1. Customer Scenario 2. Solution Overview 3. Functional Implementation Approach 4. Email Return Label Experience 5. Handling Complex Data Automatically 6. Business Impact 7. Preview Video 8. Final Thoughts Customer Scenario A Massachusetts-based consumer appliance manufacturer known for building innovative kitchen technology was experiencing a growing operational challenge in its customer service operations. As demand for its products increased across major retail channels, the number of customer support cases related to product returns and replacements also grew significantly. The company’s customer support team handled all service requests through Microsoft Dynamics 365 Customer Service. However, when a product needed to be returned for inspection, replacement, or warranty evaluation, agents were required to manually create a shipment in FedEx Ship Manager. This manual process involved several steps: 1] Opening the customer case in the CRM system 2] Copying customer information and shipping details 3] Logging into the FedEx portal 4] Registering the shipment manually 5] Generating a return label 6] Capturing the tracking number 7] Returning to CRM to update the case Each shipment registration typically took 20–30 minutes. When hundreds of return requests were processed weekly, this created several operational challenges: 1] Agents constantly switched between multiple systems 2] Manual data entry increased the risk of errors 3] Customer response times increased, leading to customer resentment 4] Tracking information was not always immediately available in the case record The organization needed a more efficient way to handle returns while keeping the entire process inside their CRM platform. Solution Overview To streamline the returns process, I implemented an integration between Microsoft Dynamics 365 Customer Service and FedEx shipping manager services. The goal was simple: Allow customer service representatives to generate a return shipment directly from the case record with a single click. Instead of navigating to the separate external shipping portal, agents can now initiate a return shipment directly from the CRM case page. Once triggered, the system automatically handles the entire shipment (Email/Return/Label) registration process. With this solution in place, the workflow now looks like this: A customer contacts support regarding a product return via their website, which registers an associated Case record in D365 Case Management (via existing case automation). The support agent opens the case in Dynamics 365. A “Create Return Shipment” button becomes available when the case meets the required conditions, e.g., Case Stage, RMA availability, Region of Customer, etc., thus validating and restricting shipment privileges. With one click, the system registers the shipment with FedEx (via appropriate FedEx Shipment APIs, as per customer requirements). The shipment tracking number is automatically captured and stored in the case record. This tracking number is useful for the customer support team as well as the customer to check the progress of the shipment on the FedEx Shipping Manager portal. The customer receives an email return label that they can print and attach to their package. FedEx Email Return Shipment Process Flow This transformation reduced a 20–30 minute process to just a few seconds. Functional Implementation Approach The implementation focused on simplifying the experience for customer service agents while maintaining strict control over when and how shipments could be created. Intelligent Shipment Trigger Visibility Within the CRM case interface, the return shipment button appears only when specific conditions are met. This ensures that shipments are created only for valid return scenarios. Examples of conditions include: The case must have an approved return authorization The case must be in an appropriate service stage The customer address must be eligible for shipment Required customer information must be available Example: Return Shipment Trigger inside Dynamics 365 Customer Service Hub By embedding these conditions into the CRM interface, agents are guided through the correct service workflow without needing to remember complex procedures. Automated Shipment Creation Once the button is clicked, the system automatically gathers key information from the case record, such as: Customer details Shipping address Product description Return authorization number Contact phone number This information is then used to register the shipment through the FedEx shipping system. The system generates: A unique shipment tracking number A return shipment registration A digital return label The warehouse where the shipment would reach based on the product and end consumer requirement – e.g., return, replacement, or repair of the product Example: A Successful Return Shipment to a specific warehouse. Example: Tracking a Return Shipment using the Tracking No. updated on D365 Customer Service Hub. Example: The FedEx Shipping Manager for Tracking the Integrated Shipments. The tracking number is immediately written back to the case record in Microsoft Dynamics 365 Customer Service, ensuring that support agents can track the return shipment without leaving the case. Email Return Label Experience After the shipment is registered, the customer automatically receives an email containing their return label. … Continue reading Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service →

One of the small but frustrating limitations in Microsoft Dynamics 365 is how subgrids handle record creation. If you’ve worked with Opportunities, Quotes, Orders, or any parent–child setup, you’ve probably experienced this: You need to add multiple related records. The system allows you to add them one at a time. Click New. Save. Repeat. It works, but it’s slow, repetitive, and not how users naturally think. Over time, that friction adds up. The Real Problem In our case, an Australia-based linen and garments company, was using Dynamics 365 to manage sales opportunities for hospitality and healthcare clients. Their sales team regularly needed to add multiple products — such as linen packages, garment services, and rental items, to a single Opportunity. These products were organized by categories like: A typical deal didn’t include just one item. It often included five, ten, or more products across different categories. However, the out-of-the-box sub grid experience required them to: There was nothing technically broken. But from a usability perspective, it wasn’t efficient — especially for a fast-moving sales team handling multiple client proposals daily. What they really wanted was simple: Select products by category → Choose multiple items → Add them in one go → Move on. That capability simply wasn’t available within the standard sub grid behavior. Approach Instead of forcing users to follow the repetitive process, we extended the form with a custom solution. We built a lightweight HTML-based interface embedded inside the form. This interface: Once the user confirms their selection, the chosen records are sent to a custom server-side process. From the user’s perspective, the experience becomes: Open selector → Choose multiple items → Click once → All records created. Simple. Fast. Intuitive. What Happens Behind the Scenes While the interface feels straightforward, the actual processing is handled securely on the server. When users submit their selection: This ensures the solution is: The business logic remains centralized and controlled, not exposed on the client side.file. Why This Matters The improvement may seem small at first. But consider users who perform this task daily. Reducing repetitive actions saves time, lowers frustration, and improves overall efficiency. More importantly, it makes the system feel aligned with how users actually work. Instead of adapting their workflow to system limitations, the system adapts to their workflow. That’s where meaningful customization adds value. The Outcome By combining: We created a smooth bulk record creation experience within Dynamics 365. The platform remains intact. The business logic remains secure, and the user experience becomes significantly better. And sometimes, that’s exactly what good system design is about, not rebuilding everything but removing friction where it matters most. 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.

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

Summary In most CRM implementations, data exposure should be encapsulated for both inside & outside the organization. Sales, Finance, Operations, HR, everyone works in the same system. Collaboration increases. Visibility increases. But so does risk. This is based on real-world project experience, for a practical example I had implemented for a technology consulting and cybersecurity services firm based in Houston, Texas, USA, specializing in modern digital transformation and enterprise security solutions. This blog explains: 1] Why Security Roles alone are not enough. 2] How users can still access data through Advanced Find, etc. 3] What Field-Level Security offers beyond entity-level restriction. 4] Step-by-step implementation. 5] Business advantages you gain. Table of Contents The Real Problem: Intra-Organizational Data Exposure Implementation of Field-Level Security Results Why Was a Solution Required? Business Impact The Real Problem: Intra-Organizational Data Exposure Let’s take a practical cross-department scenario. Both X Department and Y Department work in the same CRM system built on Microsoft Dynamics 365. Entities Involved 1] Entity 1 2] Entity 2 Working Model X Department Fully owns and manages Entity 1 Occasionally needs to refer to specific information in Entity 2 Y Department Fully owns and manages Entity 2 Occasionally needs to refer to specific information in Entity 1 This is collaborative work. You cannot isolate departments completely. But here’s the challenge: Each entity contains sensitive fields that should not be editable — or sometimes not even visible — to the other department. Security Roles in Microsoft Dynamics 365 operate at the entity (table) level, not at the field (column) level. Approach Result Remove Write access to Entity 2 for X Dept X Dept cannot update anything in Entity 2 — even non-sensitive fields Remove Read access to sensitive fields in Entity 2 Not possible at field level using Security Roles Restrict Entity 2 entirely from X Dept X Dept loses visibility — collaboration breaks Hide fields from the form only Data still accessible via Advanced Find or exports This is the core limitation. Security Roles answer: “Can the user access this record?” They do NOT answer: “Which specific data inside this record can the user access?” Implementation of Field-Level Security Step 1: Go to your Solution & Identify Sensitive Fields, usually Personal info, facts & figures, etc. e.g. cf_proficiencyrating. Step 2: Select the field and “Enable” it for Field Level Security (This is not possible for MS Out of the Box fields) Step 3: Go to Settings and then select “Security” Step 4: Go to Settings and then select “Security” -> “Field Security Profiles” Step 5: Either create or use existing Field Security Profile, as required Step 6: Within this one can see all the fields across Dataverse which are enabled for Field Security, Here the user should select their field and set create/read/update privileges (Yes/No). Step 7: Then select the system users, or the Team (having the stakeholder users), and save it. Results: Assume you are a user from X dept. who wants to access Entity 2 Record, and you need to see only the Proficiency Rating & Characteristic Name, but not Effective Date & Expiration Date; now since all fields have Field Level Security they would have a Key Icon on them, but the fields which do not have read/write access for you/your team, would have the Key Icon as well as a “—“. The same thing would happen in Views, subgrids, as well as if the user uses Advanced Find. Why this Solution was Required? The organization needed: 1] Cross-functional collaboration 2] Protection of confidential internal data 3] Clear separation of duties 4] No disruption to operational workflows They required a solution that: 1] Did not block entity access 2] Did not require custom development 3] Enforced true data-level protection Business Impact 1. Confidential Data Protection Sensitive internal data was secured without restricting overall entity access, enabling controlled collaboration. 2. Reduced Internal Data Exposure Risk Unauthorized users could no longer retrieve protected fields via Advanced Find, significantly lowering governance risk. 3. Clear Separation of Duties Departmental ownership of sensitive fields was enforced without disrupting cross-functional visibility. 4. Improved Audit Readiness Every modification to protected fields became traceable, strengthening accountability and compliance posture. 5. Reduced Operational Friction System-enforced field restrictions eliminated the need for entity blocking, duplicate records, and manual approval workarounds. 6. Efficiency Gains The solution was delivered through configuration — no custom code, no complex business rules, and minimal maintenance overhead. 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 plugins run inside an event-driven execution pipeline where business rules and data validation must be enforced before database operations complete. As systems evolve, plugin code often degrades into heavy defensive programming filled with null checks, type casting, and nested exception handling. Over time, exception handling begins to overshadow the actual business logic. This article introduces a DTO + Validation Layer pattern that restructures plugin design into a clean, testable, and scalable architecture. What Is “Try-Catch Hell” in Plugins? Typical Causes Symptoms Issue Impact Deep nested try-catch blocks Hard-to-read code Repeated attribute checks Code duplication Business logic hidden in error handling Difficult debugging Validation spread across plugins Inconsistent rules Result:Plugins behave like procedural error-handling scripts instead of structured business components. Architectural Shift: Entity-Centric → DTO-Centric Traditional plugins manipulate the CRM Entity directly. Problem:The Entity object is: This makes failures more likely. Proposed Flow This separates: DTO: A Strongly-Typed Contract DTOs act as a safe bridge between CRM data and business logic. Without DTO With DTO Dynamic attributes Strong typing Runtime failures Compile-time safety SDK-dependent logic Business-layer independenc Mapping Layer: Controlled Data Extraction All CRM attribute handling is isolated in one place. Benefits Validation Layer: Centralized Rule Logic Traditional DTO Validation Model Validation inside plugin Dedicated validator class Hard to reuse Reusable Hard to test Unit-test friendly The Clean Plugin Pattern Now the plugin: Reduction of Exception Noise Before: Exceptions for missing fields, null references, casting issues, and validation errors. After: Only meaningful business validation exceptions remain. The architecture shifts from reactive error handling to structured validation. Generative Design Advantages Capability Benefit New fields Update DTO + Mapper only New rules Extend validator Shared logic Reuse across plugins Automated testing No CRM dependency Testability Improvement No CRM context required. Performance Considerations To conclude, the DTO + Validation pattern is not just a coding improvement- it changes the way plugins are built. In many Dynamics 365 projects, plugins slowly become difficult to read because developers keep adding null checks, type conversions, and try-catch blocks. Over time, the actual business logic gets lost inside error handling. Using DTOs and a Validation layer fixes this problem in a structured way. Instead of working directly with the CRM Entity object everywhere, we first convert data into a clean, strongly typed DTO. This removes repeated attribute checks and reduces runtime errors. The code becomes clearer because we work with proper properties instead of dictionary-style field access. Then, all business rules are moved into a Validator class. This means: Now the plugin only performs four simple steps: Get data → Convert to DTO → Validate → Run business logic Because of this: Developers can understand the purpose of the plugin faster, instead of trying to follow complex nested try-catch blocks. If your Dynamics 365 environment is evolving in complexity, reach out to CloudFronts, transform@cloudfronts.com, specialists regularly design and implement structured plugin architectures that improve performance, maintainability, and long-term scalability.