Quick Preview Importing customer data into Dynamics 365 can be simple and efficient. Whether you’re transitioning from another system or adding a large batch of new customers, Microsoft Excel Online offers a practical way to create multiple records at once—without any technical configuration. In this blog, I’ll walk you through a clear, step-by-step approach to importing customer (or any entity) records directly into your Dynamics 365 environment using Excel Online. By the end, you’ll be able to upload bulk data quickly while maintaining accuracy and data consistency. Let’s get started and see how you can seamlessly import multiple customer records into Dynamics 365 using Excel Online. Step 1: Go to the entity’s home page who’s records you want to create (In my case it is customer entity).   Step 2: On the active accounts view (or any view) click on edit columns and add the columns as per the data you want to be fill in. (Don’t forget to hit apply button at the bottom)  Step 2 : Once your view is ready click on Export to Excel Button on the top left and select Open in excel online.  Step 3: If you are using a system view like in this example you will see existing records on the online excel, you can clear those records or keep them as is. If you change any existing record, it will update the data of that record so you can also use this to update existing records at once (I will write a separate blog post for updating records for now let’s focus on creating records)  Step 4: You can then add the data which you want to create to the online excel sheet, in this example I am transferring data from a local excel sheet to the online excel.  Step 5: Once you have added your data on the online excel, hit apply button.  Step 6: You will get a Popup about your data being submitted for import, hit Track Progress.  Step 7: You will see your data has been submitted and is parsing. (It will take couple of minutes to hours depending upon the amount of data you have submitted keep refreshing to see the progress of the records).  Step 8: Once the import job is completed you will see how many records were created successfully and how many failed or partially failed. You can open the import job and check failed entries, correct the entries and re-import   Failed records  All the successfully parsed records will be created in your system.  Importing customer records in Dynamics 365 becomes incredibly seamless with Excel Online. With just a few steps-preparing your view, exporting to Excel, adding your data, and submitting the import-you can create hundreds or even thousands of records in a fraction of the time. This approach not only speeds up data entry but also ensures consistency and reduces manual errors. Hope this helps! 😊  I Hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudFronts.com.

Email remains one of the most critical communication tools in Business Central. Whether you’re sending invoices, notifications, or workflow approvals, the reliability and security of your email integration matter. With Microsoft officially retiring Basic Authentication in Exchange Online, Business Central users must now embrace OAuth 2.0 for SMTP connections. Let’s explore what this means and how to configure it. Why the Shift to OAuth 2.0? Setting Up SMTP with OAuth 2.0 in Business Central The process is simpler than many expect. Here’s the streamlined approach: To conclude, switching to SMTP with OAuth 2.0 in Business Central is not just a technical requirement it’s a strategic move toward secure, modern communication. The setup is straightforward, but the payoff is significant: stronger security, smoother compliance, and reliable email delivery.

Email remains a vital communication tool in Dynamics 365 Finance & Operations, powering workflows like invoice delivery, notifications, and approvals. To ensure secure and reliable email transmission, organizations configure SMTP directly within F&O. This guide walks through the streamlined steps to configure SMTP in F&O so your system can send emails seamlessly. Steps to Achieve goal 2. Go to SMTP settings and enter below valuesEnter SMTP Server Details Enable SSL/TLS if required. Server: e.g., smtp.office365.com Port: usually 587 (TLS) 3. Define Sender Address Ensure each user has a valid email address in User options → Email. To conclude, configuring SMTP in Dynamics 365 F&O is a straightforward process that unlocks secure and efficient email communication across your business processes. By entering the correct server details, authentication method, and sender information, you enable F&O to deliver messages reliably without manual intervention. With SMTP in place, Finance & Operations becomes not just a system of record, but a system of communication. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In Microsoft Dynamics 365 CRM, every Case (Incident) record comes with a default Ticket Number. Microsoft generates it automatically, and while that’s fine for basic tracking, it usually doesn’t survive first contact with real business requirements. Users want meaningful Case IDs—something that actually tells them what kind of case this is, what service it belongs to, and where it came from. Unfortunately, since Ticket Number (ticketnumber) is a Microsoft-managed field, you can’t just slap a custom format on it using configuration alone. That’s exactly where a Pre-Operation plugin comes in. This blog walks through a real production use case where we customize the default Case ID format without breaking Microsoft’s auto-numbering, and without creating race conditions or duplicate numbers. Use Case Table: Case (Incident) Field: Ticket Number (ticketnumber) Requirement: Execution: Why Pre-Operation Microsoft generates the Ticket Number before the Create operation completes. In Pre-Operation, we can: This gives us: The Custom Ticket Number Format The final Case ID looks like this: Example: Plugin Logic Overview Here’s what the plugin does, step by step: The Plugin Code Plugin Registration Details Message: Create Primary Entity: Case (incident) Stage: Pre-Operation Mode: Synchronous Filtering Attributes: Not required. To conclude, customizing a Microsoft-managed field like Ticket Number often sounds risky, but as you’ve seen, it doesn’t have to be. By letting Dynamics 365 generate the number first and then reshaping it in a pre-Operation plugin, you get the best of both worlds. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Summary For growing businesses, service request management becomes crucial as volume and complexity increase. Email-driven support and Excel trackers often fail to scale effectively. A structured Service Request Management System (SRMS) centralizes tracking, automates processes, and enforces SLAs. Microsoft Dynamics 365 Customer Service enables operational, accountable support management. Implementing the right system ensures efficiency, transparency, and customer satisfaction as businesses grow. Table of Contents 1. Key Components of an SRMS 2. Setting Up Service Request Management 3. Operationalizing with Dynamics 365 4. Customer Success Story Key Components of a Service Request Management System For growing businesses, as much as their processes, reports, and efficient systems are important, service request management becomes equally crucial. As companies scale, the volume and complexity of service requests increase, making efficient management essential to maintaining operational flow and customer satisfaction. A well-designed Service Request Management System (SRMS) helps align workflows, reduce response times, and enhance service delivery. Centralized Request Tracking: A centralized service request management system (SRMS) allows businesses to log, track, and manage all service requests in one place. Unified Dashboard: A centralized dashboard provides a comprehensive view of all service requests, their statuses, and assigned personnel. Prioritization and Categorization: Service requests can be categorized and prioritized based on urgency, impact, and type. Automatic Case Creation and Update Rule: Automation features such as automatic ticket creation, escalation rules, and status updates help reduce manual effort. Service Level Agreements (SLAs): SLAs define expected response and resolution times and ensure deadlines are met. Automated Assignment: Service requests are automatically assigned based on expertise, workload, and availability. Real-Time Updates: Service agents update request statuses in real time, providing accurate information to stakeholders. Customer Self-Service Portal: Customers can submit and track service requests independently. Setting Up Service Request Management for a Growing Business Support Email Address: Customers send queries to support@companydomain.com. Automatic Case Creation: Requests sent to the support email are automatically converted into cases. Case Assignment: Once a case is created, it is assigned to a support team member. Acknowledgment Emails: A confirmation email is sent to the customer. Team Notification: The assigned team member receives a notification. Progress Updates: Team members add notes and updates to the ticket. Real-Time Updates: Updates are sent to the customer via email in real time. Defaulter Report: A defaulter report is generated internally to manage SLA breaches. Case Closure Notifications: Notifications are sent to customers upon cancellation or resolution. Email Tracking: All communication via email is automatically tracked by the system. Service Request Management Portal: A portal can be provided to selected customers for managing service requests. Operationalizing Customer Service with Dynamics 365 If your customer support still lives in shared inboxes and Excel trackers, you’re not alone. As volumes increase, this setup quickly turns into missed SLAs, inconsistent updates, and frustrated customers. Automatic case creation from support emails, portals, or web forms Queue-based assignment End-to-end tracking of customer interactions Business Process Flows (Identify → Research → Resolve) SLA-driven reminders and alerts One-click email responses from the case record Self-service portal support Watch the Full Webinar Demo To see how Dynamics 365 Customer Service operationalizes service management in real time, watch the complete webinar session below: Frequently Asked Questions Why does email-only support fail at scale? It lacks centralized tracking, SLA enforcement, ownership clarity, and structured workflows. What is the main benefit of an SRMS? Centralized visibility, automation, and accountability. Can customers continue using email? Yes. Emails are automatically converted into tracked cases internally. Customer Success Story Having a solid service request management system (SRMS) is a game-changer for any growing business. By centralizing service requests, automating processes, and setting clear expectations with SLAs, businesses can maintain efficiency and customer satisfaction as they grow. Here is our featured Customer Success Story: Revolution Cooking partnered with CloudFronts for Dynamics 365 enhancements and data integration with third-party applications.

An Australia-based linen manufacturing and distribution company was using Microsoft Dynamics 365 to manage their sales lifecycle. Their sales process included: The issue arose when sales representatives needed to add multiple existing products to an Opportunity. The Real Problem Out-of-the-box behavior in Dynamics 365 allows users to: While this works functionally, it becomes inefficient for organizations managing: This resulted in: The business requirement was clear: Users should be able to select multiple existing products and create Opportunity Product records in bulk, from a single interface. Architectural Decision Instead of: To address this, we introduced a custom button on the Opportunity Products subgrid. When clicked, it opens an HTML web resource that allows users to select multiple existing products in a single interface. The selected products are then processed through a Custom Action, which handles the bulk creation of Opportunity Product records server-side. Why Use an HTML Web Resource? In Microsoft Dataverse, not every customization belongs directly inside the main form. Sometimes we need: HTML Web Resources allow us to build: Without disturbing the standard CRM experience. The Web Resource We created an HTML web resource named: The HTML web resource renders a searchable grid of existing Product records, allowing users to perform multi-selection. The selected product IDs are then passed to a Custom Action, which handles the creation of related Opportunity Product records against the active Opportunity. Opening the HTML Web Resource from the Subgrid Button The key technical step was opening the HTML page when the custom ribbon button is clicked. We used modern navigation APIs. JavaScript Used on the Ribbon Button How This Works When the custom button is clicked, the script first retrieves the current Opportunity record ID. This ID is then passed as a parameter to the HTML web resource so that the selected products can be associated with the correct Opportunity. The web resource is opened as a modal dialog using the target: 2 navigation option, ensuring that users can complete the bulk selection process without leaving the form. Inside the HTML Web Resource Within the HTML web resource: This design ensures: All without navigating away from the form. How This Approach Saved Time Faster User Workflow Users select multiple products in one screen. Clean Architecture Concern Where It Lives Business Data Dataverse UI Interaction HTML Web Resource Batch Logic Custom Action (C# Plugin) To encapsulate, with this design the Client was able to: Opening an HTML Web Resource from a button in Microsoft Dynamics 365 is a powerful extension technique. It allows organizations to: We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Dynamics 365 CRM plugins are a powerful way to enforce business logic on the server but choosing when and how to use them is just as important as writing the code itself. In one implementation for a Netherlands-based sustainability certification organization, the client needed their certification journey to begin with a custom application entity while still ensuring that applicant and company details were captured as leads for downstream sales and engagement processes. This blog explores how a server-side plugin was used to bridge that gap, reliably creating and associating lead records at runtime while keeping the solution independent of UI behavior and future integrations. In this scenario, the certification application was the starting point of the business process, but sales and engagement still needed to operate on leads. Simply storing the same information in one place wasn’t enough, the system needed a reliable way to translate an application into a lead at the right moment, every time. That transformation logic is neither data storage nor UI behavior; its core business process logic, which is why it was implemented using a Dynamics 365 plugin. Scenario: Certification Application Not Flowing into Sales Users reported the following challenge: a. A user submits or creates a Certification Applicationb. Applicant and company details are captured on a custom entityc. Sales teams expect a Lead to be created for follow-upd. No Lead exists unless created manually or through inconsistent automatione. Application and sales data become disconnected This breaks the intended business flow, as certification teams and sales teams end up working in parallel systems without a reliable link between applications and leads. Possible Solution: Handling Lead Creation Through Manual Processes (Original Approach) Before implementing the plugin, the organization attempted to manage lead creation manually or through disconnected automation. How It Worked (Initially) a. A Certification Application was submittedb. Users reviewed the applicationc. Sales team manually created a Lead with applicant/company detailsd. They tried to match accounts/contacts manuallye. Both records remained loosely connected. Why This Might Look Reasonable a. Simple to explain operationallyb. No development effortc. Works as long as users follow the steps perfectly The Hidden Problems 1] Inconsistent Data Entry a. Users forgot to create leadsb. Leads were created with missing fieldsc. Duplicate accounts/contacts were createdd. Sales lost visibility into new certification inquiries 2] Broken Cross-Department Workflow a. Certification team worked in the custom entityb. Sales team worked in Leadsc. No structural linkage existed between the twod. Downstream reporting (pipeline, conversion, source tracking) became unreliable. Workaround to This Approach: Use Server-Side Logic Instead of Manual Steps Practically, the transformation of an application into a lead is business logic, not user behavior. Once that boundary is respected, the solution becomes stable, predictable, and automation-friendly. Practical Solution: A Server-Side Plugin (Improved Approach) Instead of depending on people or scattered automation, the lead is created centrally and automatically through a plugin registered on the Certification Application entity. Why a Plugin? a. Executes consistently regardless of data sourceb. Not tied to form events or UI interactionsc. Can safely check for existing accounts/contactsd. Ensures one source of truth for lead and application linkagee. Works for portal submissions, integrations, and bulk imports This is essential for a client, where applications may originate from multiple channels and must feed accurately into the sales funnel. How the Plugin-Based Solution Works The solution was implemented using a server-side plugin registered on the Certification Application entity. The plugin executes when a new application is created, retrieves the necessary applicant and organization details, performs basic checks for existing accounts and contacts, creates a Lead using the extracted data, and finally links the Lead back to the originating application record. This ensures that every certification application automatically enters the sales pipeline in a consistent and reliable manner. Implementation Steps (For Developers New to Plugins) If you’re new to Dynamics 365 plugins, the implementation followed these core steps: Build and Register the Plugin. Once the plugin logic is implemented, build the project to generate the signed assembly. After a successful build: After registration, every new Certification Application will automatically trigger the plugin, ensuring that a Lead is created and linked without any manual intervention. a. Open the Plugin Registration Toolb. Connect to the target Dynamics 365 environmentc. Register the compiled assemblyd. Register the plugin step on the Create message of the Certification Application entitye. Configure the execution stage (typically post-operation) and execution mode (Synchronous or Asynchronous, depending on business needs) To encapsulate, this solution shows why server-side plugins are the right place for core business logic in Dynamics 365. By automatically creating and linking a Lead when a Certification Application is created, the organization removed manual steps, prevented data inconsistencies, and ensured that every application reliably flowed into the sales pipeline. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In production Databricks environments, data issues such as accidental overwrites, faulty MERGE conditions, or incorrect backfills are common. Delta Lake’s Time Travel is not just a feature – it is a critical recovery and governance mechanism. This blog focuses only on practical recovery strategies that are actually used in real-world production systems. Why Time Travel Is Critical in Production Common failure scenarios include: •a. INSERT OVERWRITE wiping historical data • b. Incorrect MERGE conditions deleting valid records • c. Wrong filters during backfill corrupting data Reprocessing data is expensive and risky. Time Travel enables instant rollback with minimal impact. Version vs Timestamp (What You Should Use) Always prefer version-based time travel for recovery operations. Why version-based recovery is preferred: • a. Precise and deterministic • b. No time zone dependency • c. Safest option for production recovery Use timestamp-based queries only for auditing, not recovery. Identify the Last Safe State Before performing any recovery, always inspect the table history. DESCRIBE HISTORY crm_opportunities; Key fields to review: • a. version • b. timestamp • c. operation • d. userName This history acts as the single source of truth during incidents. Recovery Patterns That Actually Work 1. Partial Data Recovery (Recommended) Recover only the affected records instead of rolling back the entire table. Advantages: • a. No downtime • b. Safe for downstream reports • c. Most production-friendly approach 2. Full Table Restore (Use Carefully) Advantages: •a. Fast and atomic Risks: •a. Impacts all downstream consumers Use this approach only when the entire table is corrupted. Safe Validation Using CLONE Before restoring data in production, validate changes using a clone. Typical use cases: • a. Validate recovered data • b. Compare versions •c. Run business checks Retention & VACUUM (Most Common Mistake) The following command causes permanent data loss: Once vacuumed aggressively, time travel breaks and rollback becomes impossible. Production-Safe Retention Recommended retention: • a. Critical tables: 30 days • b. Reporting tables: 7–14 days Auditing & Root Cause Analysis (RCA) Track who changed data and when: Compare changes between versions: Key Best Practices • a. Capture table version before running risky jobs • b. Always use version-based time travel for recovery • c. Prefer partial recovery over full restores • d. Avoid aggressive VACUUM operations • e. Extend retention for critical tables • f. Validate using CLONE before restoring To conclude, Delta Lake Time Travel is not a backup mechanism, but it is the fastest and safest recovery tool in Databricks. When used correctly, it prevents downtime, reduces reprocessing cost, and improves production reliability. For enterprise Databricks pipelines, mastering this capability is mandatory, not optional. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Traditional business intelligence platforms have historically focused on visualization-charts, KPIs, and trend lines that describe what has already happened. Power BI excels at this, enabling users to explore data interactively and monitor performance at scale. However, modern business users expect more than visuals. They need clarity, reasoning, and guidance on what actions to take next. This marks the shift from dashboards toward true decision intelligence. Business Challenges Most organizations face a similar challenge. Dashboards answer what happened but rarely explain why it happened. Business users depend on analysts to interpret insights, which slows down decision-making and creates bottlenecks. At the same time, data is fragmented across CRM systems, ERP platforms, project tools, and external APIs. Bringing this data together is difficult, and forming a single, trusted view becomes increasingly complex as data volumes grow. Why Visualization Alone Is Not Enough Even with powerful visualization tools, interpretation remains manual. KPIs lack business context, anomalies are not automatically explained, and insights rely heavily on tribal knowledge. This creates a gap between data availability and decision confidence. Introducing Agent Bricks Agent Bricks is introduced to close this gap. It acts as an AI orchestration and reasoning layer that consumes curated analytical data and applies large language model-based reasoning. Instead of presenting raw numbers, Agent Bricks generates contextual insights, explanations, and recommendations aligned to business scenarios. Importantly, it enhances Power BI rather than replacing it. High-Level Architecture From an architecture standpoint, data flows from enterprise systems such as CRM, ERP, project management tools, and APIs. Azure Logic Apps manage ingestion, Azure Databricks handles analytics and modeling, Agent Bricks performs AI reasoning, and Power BI remains the consumption layer. To conclude, dashboards remain a critical foundation for analytics, but they are no longer enough to support modern decision-making. As data complexity and business expectations grow, organizations need systems that can interpret data, explain outcomes, and guide actions. Agent Bricks enables this shift by introducing AI-driven reasoning on top of existing Power BI investments. By bridging the gap between analytics and decision-making, it helps organizations move from passive reporting to proactive, insight-led execution. This marks the first step in the evolution from dashboards to true decision intelligence. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In an ideal Dynamics 365 (Dataverse) project, plugin source code lives safely in a version-controlled repository, flows cleanly through Azure DevOps pipelines, and is always recoverable. In reality, many of us inherit environments where that discipline didn’t exist. I recently worked with a customer where: This created a common but uncomfortable challenge in the Dynamics 365 world:How do you maintain, debug, or enhance plugins when the source code is lost? Rewriting everything from scratch was risky and time-consuming. Guessing behavior based on runtime results wasn’t reliable. Fortunately, Dynamics 365 and the .NET ecosystem give us a practical and effective alternative. Using XrmToolBox and JetBrains dotPeek, it is possible to recover readable C# plugin code directly from the deployed assembly. (Though the C# Class code recovered won’t be 100% exact, as the variable names would be different and generic; it is only suitable for close logic, structure & functional recovery) The Practical Solution The approach consists of two main steps: This does not magically restore comments or original formatting, but it does give a working, understandable code that closely reflects the original plugin logic. Tools Used Step 1: Extract the Plugin Assembly from Dataverse 1. Connect to the Environment 2. Load the Assembly Recovery Tool 3. Download the DLL At this point, you have successfully recovered the compiled plugin assembly exactly as it exists in the environment. Step 2: Decompile the DLL Using JetBrains dotPeek 1. Open dotPeek 2. Explore the Decompiled Code dotPeek will: One can now browse through: This is usually more than enough to understand how the plugin works. 3. Export to a Visual Studio Project (Optional but Recommended) One of dotPeek’s most powerful features is Export to Project: This gives you a proper .csproj with class files that you can open, build, and extend. Possibilities with the Recovered Code Once you have the decompiled C# code, several options open up: 1. Rebuild the Plugin Assembly 2. Re-register the Plugin 3. Maintain or Enhance Functionality Important Considerations Key Takeaway Losing plugin source code does not mean losing control of your Dynamics 365 solution. With XrmToolBox’s Assembly Recovery Tool and JetBrains dotPeek, you can: There are chances while working in Dynamics 365 technologies, that a developer might face this situation. Knowing this technique can save days-or weeks-of effort and give your customer confidence that their system remains fully supportable. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com