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 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.

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 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

Dynamics 365 model-driven apps are excellent at storing business data, but not every piece of information belongs in Dataverse. A common design folly is using Dataverse fields to store temporary UI state-things like selected views, filters, or user navigation preferences. While this works technically, it introduces unnecessary performance overhead and can create incorrect behavior in multi-user environments. In this blog, I’ll focus on browser-level retention of CRM UI data using “sessionStorage“, using subgrid view retention as a practical example for a technology consulting and cybersecurity services firm based in Houston, Texas, USA, specializing in modern digital transformation and enterprise security solutions. The Real Problem: UI State vs Business Data Let’s separate concerns clearly: Type Example Where it should live Business data Status, owner, amounts Dataverse UI state Selected view, filter, scroll position Browser Subgrid views fall squarely into the UI state category. Scenario: Subgrid View Resetting on Navigation Users reported the following behavior: This breaks user workflow, especially for records that users revisit frequently. Possible Solution: Persisting UI State in Dataverse (Original Approach) This would attempt to fix it by storing the selected subgrid view GUID in a Dataverse field on the parent record. How It Works Why this might look reasonable The Hidden Problems 1] Slower Form Execution 2] Data Model Pollution 3] Incorrect Multi-User Behavior 4] Scalability Issues In short, Dataverse was doing work it should never have been asked to do. Workaround to this Approach: Keep UI State in the Browser for that session, But practically: The selected subgrid view belongs to the user’s session, not the record. Once that boundary is respected, the solution becomes much cleaner. Practical Solution: Browser Session Storage (Improved Approach) Instead of persisting view selection in Dataverse, we store it locally in the browser using sessionStorage. sessionStorage is part of the Web Storage API, which provides a way to store key-value pairs in a web browser. Unlike localStorage, which persists data even after the browser is closed, sessionStorage is designed to store data only for the duration of a single session. This means that the data is available as long as the tab or window is open, and it is cleared when the tab or window is closed. Why Session Storage? How the Improved Solution Works 1. Store the View Locally on Subgrid Change 2. Restore the View on Form/Grid Load This ensures that when the user revisits the form, the subgrid opens exactly where they left off. Why This Approach Is Superior 1] Faster Execution 2] Correct User Experience 3] Clean Architecture 4] Zero Backend Impact When to Use Browser-Level Retention Use this pattern when: Examples: To conclude, not all data deserves to live in Dataverse. When you store UI state in the browser instead of the database, you gain: Subgrid view retention is just one example-but the principle applies broadly across Dynamics 365 customizations. 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 complex business processes, like calculating commissions or validating data across multiple records, applying the same logic repeatedly in a Power Automate flow can quickly become inefficient and difficult to maintain. A more scalable approach is to encapsulate the logic in a Dataverse plugin, expose it as a bound action, and then call this action from a flow. This method centralizes business rules, reduces redundancy, and improves maintainability. In this post, we’ll walk through the steps to implement this approach and examine its advantages over applying the same logic directly within a flow for each individual record. We’ll illustrate this with a practical example from a Houston-based technology consulting and cybersecurity services firm that specializes in modern digital transformation and enterprise security solutions. Flow Diagram Step 1: Create the PluginThe first step is to write a plugin that contains the logic you want to apply to each record. Example: DuplicateCommissionsCounter Step 2: Expose the Plugin as a Bound ActionInstead of running plugin logic manually for each record, you can register it as a bound action in Dataverse. Procedure: E.g. 2. Attach your plugin to this action. Outcome: This exposes your plugin logic as a reusable, callable bound action. Any process or flow can now invoke it for a specific invoice record. Step 3: Use Power Automate to Call the Bound ActionOnce the plugin is exposed, you can loop through multiple records in a flow and call the action. Procedure in Power Automate: This approach ensures that all complex logic resides in the plugin, while the flow orchestrates which records need processing. Advantages Over Logic Directly in the Flow To conclude, exposing plugins as bound actions is a robust, maintainable way to apply complex logic across multiple records in Dataverse. It allows Power Automate flows to focus on orchestration rather than logic execution, leading to cleaner, faster, and easier-to-manage solutions. 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

Managing secure operations in Microsoft Dynamics 365 Finance and Operations (D365FO) is crucial for enterprise-level environments. While working in a Dev environment, I recently encountered an issue while posting the packing slip for a Sales Order. After troubleshooting, I identified the problem was related to expired SSL certificates in a cloud-hosted environment. SSL certificates in D365FO environments remain valid for one year. To maintain security and avoid disruptions, it’s necessary to renew these certificates regularly-a process called credential rotation, managed via the Lifecycle Services (LCS) portal. In this blog, I’ll guide you step-by-step on how to resolve this issue through SSL certificate rotation. Why SSL Certificate Rotation is Important When deploying Dynamics 365 Finance Operations as a cloud-hosted environment, SSL certificates are used to encrypt data and ensure secure communication between servers. Expired certificates can disrupt functionality. Regular rotation of credentials is a best practice to maintain smooth operations and robust cybersecurity. Step-by-Step Process to Rotate SSL Certificates in Dynamics 365 Finance & Operations Here’s how you can resolve the issue and renew SSL certificates in your environment: Step 1: Log into the LCS Environment Step 2: Navigate to the Implementation Project Step 3: Initiate Credential Rotation Step 4: Rotate SSL Secrets Certificates Step 5: Wait for the Process to Complete Step 6: Verify the Deployment Status To conclude, regularly rotating SSL certificates not only resolves operational issues but also ensures compliance with enterprise-level cybersecurity practices. By following the above steps, you can maintain the security and functionality of your Dynamics 365 Finance Operations cloud-hosted environments. 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

Most organizations think of Dynamics 365 Finance & Operations (D365 F&O) only as a system that receives data from other applications. In reality, the most powerful and scalable architecture is when F&O itself becomes the source of truth and an event producer. Every financial transaction, inventory update, order confirmation, or invoice posting is a critical business event – and when these events are not shared with other systems in real time, businesses face: So, the real question is: What if every critical event in D365 F&O could instantly trigger actions in other systems? The answer lies in an event-driven architecture using Azure Event Hub and Azure Logic Apps, where F&O becomes the producer of events and the rest of the enterprise becomes real-time listeners. Core Content Event-Driven Model with F&O as Source In this model, whenever a business event occurs inside Dynamics 365 F&O, an event is immediately published to Azure Event Hub. That event is then picked up by Azure Logic Apps and forwarded to downstream systems such as: In simple terms: Event occurs in F&O → Event is pushed to Event Hub → Logic App processes → External system is updated This enables true real-time integration across your entire IT ecosystem. Why Use Azure Event Hub Between F&O and Other Systems? Azure Event Hub is designed for high-throughput, real-time event ingestion. This makes it the perfect choice for capturing business transactions from F&O. Azure Event Hub provides: This ensures that every change in F&O is captured and made available in real time to any subscribed system. Technical Architecture Here is the architecture with F&O as the source: Role of each layer: Component Responsibility D365 F&O Generates business events Event Hub Ingests & streams events Logic App Consumes + transforms events External Systems Act on the event This architecture is:✔ Decoupled✔ Scalable✔ Secure✔ Real-time✔ Fault tolerant How Does D365 F&O Send Events to Event Hub? Using Business Events F&O has built-in Business Events Framework which can be configured to trigger events such as: These business events can be configured to push data to an Azure Event Hub endpoint. This is the cleanest, lowest-code, and recommended approach. Logic App as Event Consumer (Real-Time Processing) Azure Logic App is connected to Event Hub via Event Hub Trigger: Once triggered, the Logic App performs: Example downstream actions: F&O Event Logic App Action Invoice Posted Push to Power BI + Send email Sales Order Create record in CRM Inventory Change Update eCommerce stock Vendor Created Sync with procurement system This allows one F&O event to trigger multiple automated actions across platforms in real time. Real-Time Example: Invoice Posted in F&O Step-by-step flow: All of this happens automatically, within seconds. This is true enterprise-wide automation. Key Technical Benefits Why this Architecture is important for Technical Leaders If you are a CTO, architect, or technical lead, this approach helps you: Instead of systems “asking” for data, they react to real-time business events. To conclude, by making Dynamics 365 Finance & Operations the event source and combining it with Azure Event Hub and Azure Logic Apps, organizations can create a fully automated, real-time, intelligence-driven ecosystem. Your first step: ➡ Identify a critical business event in F&O➡ Publish it to Azure Event Hub➡ Use Logic App to trigger automatic actions This single change can transform your integration strategy from reactive to proactive. 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