Sending Dynamics 365 Emails from JavaScript with the Dataverse Web API | CloudFronts Summary Most Dynamics 365 emails are generated by workflows, Power Automate flows, or plugins reacting to a record change. But some notifications are triggered by a user action inside a custom UI, where the browser already holds all the context and the user needs to know immediately whether the email went out. In this implementation, we generated and sent Dynamics 365 email activities directly from JavaScript running in an HTML web resource, using only the Dataverse Web API. The email is created with sender and recipient activity parties, linked to a related record through the Regarding lookup, and sent through the SendEmail bound action for delivery by server-side synchronization. This article covers the problem, the use case, how an email is structured in Dataverse, and a step-by-step walkthrough of the JavaScript implementation, including the pitfalls we hit along the way. Table of Contents Problem Statement The Use Case Why Send Emails from JavaScript? Anatomy of an Email in Dataverse Solution Overview Step 1 — A Reusable Web API Helper Step 2 — Identifying the Sender Step 3 — Resolving the Recipient Dynamically Step 4 — Creating the Record the Email Will Be Regarding Step 5 — Composing the Subject and HTML Body Step 6 — Building the Activity Parties Step 7 — Binding the Regarding Lookup Step 8 — Creating the Email Record Step 9 — Sending the Email with SendEmail Understanding the Email Lifecycle The Complete Email Function Error Handling Testing and Validation Security and Production Considerations Key Implementation Lessons Conclusion Frequently Asked Questions This Blog Explains When a user action, rather than a record change, should be the trigger for an email. How an email activity, its activity parties, and its Regarding lookup fit together in Dataverse. How to create an email with From and To recipients through the Web API. The Regarding navigation property naming that commonly causes silent failures. The difference between creating an email and sending it. Why sent emails show as Pending Send, and what has to be configured for delivery. Read more about our Journey with this Customer over here: View Case Study  |  Refer my previous blog on the associated topic for more context Problem Statement Dynamics 365 offers several ways to send email automatically, and nearly all of them are record-driven: something is created or updated, and a workflow, flow, or plugin reacts to it. That model breaks down when the event worth notifying about is not a simple record change but an action a user performs in a custom interface, such as an HTML web resource or a custom page. In those cases: The trigger is a button click, and the relevant context (who acted, what changed, what the previous value was) lives in the browser. The email must only be sent once a multi-step operation has fully succeeded, not when it starts. The user expects immediate confirmation that the notification went out, or a clear message if it did not. The email should be a proper Dynamics 365 activity, visible on a related record’s timeline, not an untracked message sent from outside CRM. An asynchronous flow cannot give the user that immediate feedback, and a plugin would need to reconstruct context the UI already has. The question became: Can we create, link, and send a fully tracked Dynamics 365 email directly from the JavaScript that handles the user’s action, using only the Dataverse Web API? The Use Case The scenario was a custom Dataverse Choice (Option Set) Manager, an HTML web resource that lets authorized users add or relabel picklist values (for example, Lead Source) from within Dynamics 365.Building Self-Service Dataverse Choice Picklist values feed reports, business rules, flows, and integrations, so the Operations Lead needed to be informed every time one changed. The notification rules were: Rule Implication for the email Notify only after the change is published The email is generated as the final step, after PublishXml succeeds Send from the user who made the change The sender activity party is the signed-in user Send to whoever currently holds the Operations Lead role The recipient is resolved at runtime, not hard-coded Keep the email traceable The email is set Regarding a Picklist Changes Audit Log record Include full change details The HTML body lists action, time, user, entity, field, option name, value, and old label The picklist change itself is the trigger. Everything that follows in this article is about the email. Why Send Emails from JavaScript? Approach Fit for a user-action trigger Power Automate Runs asynchronously, so the user cannot be told in the same interaction whether the email was sent Classic workflow Record-driven and deprecated in favour of Power Automate for new development Plugin Needs a compiled, registered assembly and must reconstruct context the UI already holds JavaScript + Web API Runs in the same interaction, has full context, and reports success or failure to the user immediately Because the web resource runs inside Dynamics 365, each Web API call executes as the signed-in user. Their security roles still decide whether they can create an email, set its recipients, and send it. Anatomy of an Email in Dataverse Before writing any code, it helps to understand that an email in Dynamics 365 is not a single record with To and From text fields. It is an activity made up of several related pieces. email (activity) ├── subject ├── description → HTML body ├── directioncode → true = outgoing ├── statecode / statuscode │ ├── email_activity_parties (collection) │ ├── participationtypemask = 1 → From │ ├── participationtypemask = 2 → To │ ├── participationtypemask = 3 → CC │ └── participationtypemask = 4 → BCC │ └── partyid → systemuser / contact / account / lead … │ └── regardingobjectid → any activity-enabled table Piece What it does Email record Holds the subject, body, direction, and status Activity parties Separate records linking the email to each sender and recipient Regarding Polymorphic lookup … Continue reading D365 CRM – Generating Emails using JavaScript via user actions for US based Azure & AI services company →

Please find this CloudFronts Product at – CloudFronts PO-BC Integration Module | Microsoft Marketplace Watch the webinar – CloudFronts PO-BC Integration Webinar | YouTube Summary Dynamics 365 Project Operations (PO) holds customers, projects and time. Business Central (BC) holds invoices and payments. When the two are not connected, people copy data by hand, which is slow and causes mistakes. The CloudFronts PO-BC Integration Module is a Dynamics 365 Project Operations and Business Central integration. You set up the link once, and every change in PO shows up in BC automatically. The result is no double typing, fewer mistakes and faster billing. This blog shows how it works, step by step. Table of Contents 1Introduction 2Business Challenge 3Why an Integration Hub? 4Implementation Procedure 5End-to-End Working 6Why This Approach Works 7Real-World Use Cases 8Frequently Asked Questions 9Conclusion Introduction: Why Connect Dynamics 365 Project Operations with Business Central Many project-based businesses use two systems. Project Operations (PO) is where the sales and project teams keep customers, projects and time. Business Central (BC) is where the finance team keeps invoices, payments and money records. Both systems need the same details. A customer made in PO must also exist in BC. A project made in PO must also be there when it is time to send an invoice. Without a link, someone has to copy all of this by hand. Here is the full picture of how work moves from a lead to a payment. The top row is PO and the bottom row is BC. The arrows show where the two systems share data. The full flow from lead to payment, and where PO and BC share data. The Solution: We built an Integration Hub. It is a simple web app where you connect PO and BC, set the rules once, and let the data move on its own. Business Challenge: Manual Data Entry Between PO and BC Think about a normal project business. The sales team makes a customer in PO. The project team makes a project and adds tasks. The finance team then needs the same customer and project in BC to send invoices. These details need to be shared between the two systems: Customers and contacts Projects and tasks Planned work and costs Approved time and expenses Vendor invoices and purchase orders Paid status of invoices When people copy these by hand, many problems come up: Extra effort: The same details are typed in two systems. Mistakes: A wrong phone number or address is easy to type. Details that do not match: The two systems slowly stop agreeing with each other. Late invoices: If data reaches finance late, money comes in late. Hard to grow: More customers and projects mean more copying and checking. The Objective: When something changes in PO, BC should get the change by itself. No one should have to copy anything by hand. Why Use an Integration Hub for PO and BC Integration? The Integration Hub is one place where you create and manage every link between PO and BC. You fill a form, choose what to send, and set simple rules. You do not need to write a lot of code. With the Integration Hub, you can: Set up each link once Choose what data moves, from where, and to where Write simple rules for which detail goes where Test the result before it goes live See all links in one list, with their status and last runs Add new links as your business grows In simple words: Think of the Integration Hub as a control room. From here you decide what data moves, from where, and to where. Implementation Procedure: How to Integrate Project Operations with Business Central Step 1 – Choose the Project On the first screen you pick a project. A project here is a group of links. We use the project named PO-BC, which is for Project Operations and Business Central. Choose the project. We are using PO-BC. Step 2 – See the List of Integrations Inside PO-BC you can see all the links. Each row shows its order number, its status, and its last few runs. You can run, edit or deploy each one from here. To add a new one, click New Integration. The list of integrations. Click New Integration to add one. Step 3 – Fill the New Integration Form A form opens on the right side. Here you tell the platform: Integration Name: A name for this link. For example, Accounts. Integration Type: Master means basic details that rarely change, like customers. Transactional means things that happen often, like invoices. Source System and Source Entity: Where the data starts, and what kind of record it is. Here the system is PO, and the record type is accounts. Target System and Target Entity: Where the data goes, and what kind of record it becomes. Here the system is BC, and the record type is customer. Sequence No.: The order in which links run. Customers must exist first, so this is 1. The new integration form. Use Sync CRM Fields to add any missing fields that BC needs on the PO side. Tip: There is a handy button called Sync CRM Fields. Sometimes BC needs a detail that PO does not have yet. This button creates the missing field in PO for you. Scroll down and add a short description. This helps everyone understand later what the link does. Then click Create Integration. Add a clear description, then click Create Integration. Step 4 – Open the Flow After you create the link, you can open its flow. It is a simple picture with boxes from left to right: Source: the PO data (accounts) Data Mapper: the rules that change the data into the shape BC needs Target: the BC data (customer) Return to Source: an optional step to send data back to PO The flow. The Data Mapper box is where we set the rules. Step 5 – Write the Mapping Rules PO and BC use different names for … Continue reading Dynamics 365 Project Operations and Business Central Integration: Automate Data Sync Without Manual Work →

Summary A Houston based cybersecurity company came to us with a familiar complaint. Their sales leaders had everything they needed sitting in Dynamics 365, yet every Monday review still started in Excel. They asked for two things: their reports laid out the way they actually think about the business, and an assistant they could simply ask questions. We delivered both in one app, built with Power Apps Code Apps on top of the CRM data they already had. In This Blog What was slowing the sales team down What we built for them, screen by screen The AI agent we added so leaders can just ask What changed for the business How to tell if this approach fits your team Table of Contents Summary→ Business Challenges→ What We Built→ The AI Agent→ How It Works→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges Nothing was broken. The data was good and the team was using the CRM. The trouble was getting answers out of it quickly. A standard view shows you a list of records, which is great when you are working a lead. It is far less helpful when the sales director wants to know how many leads turned into real opportunities this quarter, and who brought them in. So the weekly routine looked like this: Open one view, then another, then a third, to piece the funnel together. Export everything to Excel and rebuild the same pivot table as last week. Walk into the meeting with numbers that were already a few days old. What the team really wanted was simple: better looking reports they could read at a glance, and an AI agent alongside them to answer the questions the reports did not cover. Before Several views to see one picture Weekly exports and pivot tables Numbers out of date by meeting time After Key numbers on the first screen One set of filters for everything Answers by simply asking What We Built Power Apps Code Apps let us design the screens completely from scratch while still reading the same Dynamics 365 data, live. Think of it as a new front door to the CRM, arranged around the questions the leadership team asks every week. Nothing was copied or moved anywhere else. The app has four pages, and they all work the same way, so people only learn it once: LeadsWhere new interest comes from and how much of it qualifies. OpportunitiesThe live pipeline, in the order leadership reviews it. SalesWhat has closed and how the team is tracking. ProjectsWhat happens after the deal is won, from Project Operations. Each page opens with the headline numbers, such as total leads, open leads, qualified leads and the qualification rate. Below that sits a single filter bar for owner, status, account, dates and search. Change one filter and every number, chart and list on the page updates with it. The summary page: headline numbers, a trend over time, and breakdowns by customer, source and owner. Shown with demo data. When a chart raises a question, the detail page shows the actual records behind it, already filtered the same way. The detail page, using the same filters as the charts. Shown with demo data. The AI Agent The second half of the request was an assistant. Code Apps do not include one, so we built our own AI agent and placed it in a side panel inside the app. Leaders type a question the way they would ask a colleague, and the agent answers from the live CRM data. Questions like which lead came in most recently, which owner has the best qualification rate this quarter, or which accounts have open deals but no new leads. Things that used to need an export now take a few seconds. In practice this is the feature people mention first when they talk about the app. Want to see how the agent itself was built? We covered that in our earlier post on how we connected an Azure AI Foundry agent to Dynamics 365 for the same client. The AI agent answering a question about the most recent active lead. Shown with demo data. How It Works You do not need to be technical to follow this. There are really only four moving parts. Step oneSign in as usualSame Microsoft account, nothing new to remember Step twoPower Apps opens the appInside the platform you already use Step threeYour custom screensNumbers, charts and lists in your layout Step fourLive CRM dataAlways current, never copied How the pieces fit together, including the AI agent. A few things matter here for the business. People only see the records they were already allowed to see in Dynamics 365. There is no separate portal to pay for or look after. And because the app sits inside a normal Dynamics 365 solution, moving it from testing to live was as routine as any other release. Worth knowing before you start Users cannot save their own personal views in this kind of app, so the filters need to be planned with the team up front. Very heavy reporting may still be better in Power BI. And it is built by a developer rather than configured, so plan for someone to own small changes after go live. Impact One place for the whole story. Leads, pipeline, sales and delivery sit side by side instead of in four corners of the CRM. Questions get answered on the spot. The AI agent handles the ones nobody built a chart for. No new licences or logins. It runs on what the client already owned, under the security they already manage. Is This Right for You? Code Apps are not a replacement for everything in Dynamics 365. This is how we usually explain the choice to clients. This projectCode App Standard Dynamics 365 app Power Pages Who it is for Your own team, when they need a view built around their role Your own team, for everyday record work … Continue reading How a U.S. Industrial Cybersecurity Company Built a Custom Sales Portal with Power Apps Code Apps →

Watch first Your browser does not support embedded video. Download the video instead. Twenty seconds: what the agent does, and why per-user CRM security is the part that is actually hard. 01Summary A Houston-based cybersecurity firm wanted their sales team to ask plain-language questions about CRM data, “how many active leads do we have”, “summarise this account’s open opportunities”, without opening Dynamics 365 and building a view for every question. We built it as an Azure AI Foundry agent connected to Microsoft Dataverse over the Model Context Protocol (MCP). No custom data layer, no synchronised copy of CRM, no bespoke API surface. Dataverse itself is the MCP server, and Foundry’s Agent Service calls it as a tool. The agent runs on GPT-4.1 and took an afternoon to wire up. The two things that actually cost time were an OAuth redirect URL that Foundry generates after you click Connect, and an architecture decision we got wrong the first time: the tenant your agent lives in decides whether per-user CRM security is achievable at all. 02In This Blog A practitioner walkthrough of connecting Foundry to Dynamics 365 over MCP, written around the two failures that cost us the most time rather than the happy path alone. The Scenario: A sales team that wanted answers from CRM without building a view for every question. The Approach: Use Dataverse as a first-party MCP server rather than building an API layer and hand-written function schemas. The Action: Environment enablement, an Entra app registration, the MCP tool with OAuth identity passthrough, and the redirect URL nobody warns you about. The Outcome: Per-user security enforced by Dataverse itself, with no parallel permission model to maintain. The connection is an afternoon. The question of whose identity the agent is acting as decides whether any of it survives contact with production. Table of Contents 01Summary→ 02In This Blog→ 03Why MCP Changes the Shape of This Problem→ 04Enable the MCP Server and Allow Your Client→ 05Register the Entra App→ 06Add the MCP Tool to the Agent→ 07Close the Redirect URL Loop→ 08Consent, and the Consent Loop→ 09Calling the Agent From Your Own Application→ 10The Tenancy Trap→ 11Licensing→ 12Impact→ 13Conclusion→ 14FAQ→ 15Get in Touch→ 03Why MCP Changes the Shape of This Problem Before MCP, connecting an LLM to Dynamics 365 meant building glue: an API layer, a set of hand-written function definitions describing each operation, schema documentation maintained by hand, and a deployment to own forever. Every new table meant another function. The Model Context Protocol replaces that with a contract. The server advertises its tools, the model discovers them at runtime, and the plumbing is the same whichever client connects. Microsoft ships Dataverse as a first-party MCP server, so the glue layer is simply gone. Dataverse MCP endpointurl https://{organisation}.crm{n}.dynamics.com/api/mcp A preview endpoint exists at /api/mcp_preview with additional tools, gated behind a separate environment setting. Check your region number Environment URLs are not always .crm. Ours has been .crm4 on other engagements, and pointing at the wrong host produces an authentication failure that looks like a permissions problem. Confirm it in Power Apps under Settings, Session details. The tool surface Tool What it does search Searches table schemas and business skills by keyword search_data Searches structured and unstructured data describe Returns details for tables, records, schemas, skills and apps read_query Runs supported Dataverse SQL SELECT queries create_record Inserts a row, returns the Gcfb-mcp7fd update_record Updates an existing row delete_record Deletes a row, only after explicit user approval create_table, update_table, delete_table Schema operations upsert_skill, delete_skill Manages Dataverse skills and playbooks init_file_upload, commit_file_upload, file_download SAS-based file handling The tool names changed, and older tutorials are wrong describe_table, list_tables and fetch were removed and folded into describe. The tool previously called search, which searched data, is now search_data, and search now searches metadata. If you maintain an allow list or deny list by tool name in your client, this rename silently changes what your agent can do. Review it. 04Step 1: Enable the MCP Server and Allow Your Client This is admin work in the Power Platform admin center, not maker work, and it is where most failed attempts stall. Open the environment settingsPower Platform admin center, then Manage, then Environments. Open the target environment and select Settings on the command bar. Turn on the MCP serverExpand Product, select Features, find Dataverse Model Context Protocol, and enable Allow MCP clients to interact with Dataverse MCP server. Open the allowed client listSelect Advanced Settings. This is where non-Microsoft and custom clients are registered individually. Add your client and enable itCreate an Allowed MCP Client record carrying the Application Id of the app registration you create in Step 2, then set Is Enabled to Yes. Copilot Studio is enabled by default. Nothing else is. Your Foundry agent is not Copilot Studio, so it needs an explicit entry. This is the single most common cause of “the connection succeeded but the agent never calls the tool”. Field Value Name A readable label, for example Foundry Dataverse Agent Unique Name A unique identifier for the record Application Id The client (app) ID of the Entra app registration from Step 2 Is Enabled Yes Figure 1: The Allowed MCP Client record. Is Enabled defaults to No. Is Enabled defaults to No Saving the record is not the same as enabling it. A disabled record behaves identically to no record at all, and produces no error anywhere. Set it to Yes before you save. This is a chicken-and-egg with Step 2: you need the Application Id before you can fill this in. Create the app registration first, then come back. Two constraints worth knowing before you plan the rollout: Managing the MCP server through Advanced connector policies requires the environment to be a Managed Environment. The allow list applies only to the /api/mcp agent entrypoint. MCP-named custom APIs are ordinary Dataverse APIs and are not restricted by this setting. If you want the preview tools, enable Allow MCP clients to interact with Dataverse MCP server (Preview version) as a … Continue reading How We Connected an Azure AI Foundry Agent to Dynamics 365 Using the Dataverse MCP Server for a Texas Industrial Cybersecurity Company →

Summary For technology services companies selling AI, cybersecurity, and Azure solutions, the hardest part of selling is rarely finding a company — it’s finding the right decision-maker, the right relationship path, and the right moment to engage. We recently implemented LinkedIn Sales Navigator inside Microsoft Dynamics 365 Sales for a Texas-based technology services company specializing in AI, cybersecurity, Azure, and cloud services. The goal wasn’t to drop a LinkedIn widget into a form — it was to build a connected prospecting experience where LinkedIn relationship intelligence and Dynamics 365 sales execution work together without forcing sellers to switch between systems. The result: sellers can research prospects, understand account relationships, identify mutual connections, and capture sales activity — all from within the CRM they already use every day. LinkedIn became the intelligence layer; Dynamics 365 remained the operational system of record. This article covers the business requirement, the matching strategy, the CRM synchronization design, and the key lessons learned from turning a LinkedIn integration into an actual sales process change. Table of Contents Introduction The Business Requirement Why LinkedIn Sales Navigator and Dynamics 365? What We Set Out to Achieve Solution Overview Setting Up LinkedIn Sales Navigator Connecting Sales Navigator with Dynamics 365 Sales Embedding Sales Navigator into CRM Forms Designing the Matching Strategy Bringing LinkedIn Intelligence into the Sales Process Icebreakers and Relationship Intelligence Lead Introduction and Related Leads Account Intelligence and Organizational Relationships CRM Synchronization and Activity Writeback Data Validation: Keeping CRM Current Controlling What Gets Written Back to CRM Synchronizing Open Opportunity Information Testing and Validation Business Impact The Strategic Value Beyond Integration Key Implementation Lessons Conclusion Frequently Asked Questions Final Takeaway This Blog Explains Why fragmented prospecting between LinkedIn and Dynamics 365 was costing sellers time and context. What licensing and administrative foundation CRM integration with Sales Navigator requires. Why matching LinkedIn profiles to CRM records is a business problem, not just a technical one. How CRM synchronization and activity writeback were scoped to avoid a noisy, unrestricted sync. How Sales Navigator can surface signals that CRM contact data has gone stale. The measurable improvements to seller workflow, CRM data quality, and account planning. The lessons we’d apply again on the next CRM-to-LinkedIn implementation. Case Study Read more about our Journey with this Customer over here: View Case Study Introduction For technology services organizations, selling is rarely about finding a company and sending an email. The real challenge is identifying the right organization, the right decision-makers, the right relationship path, and the right moment to engage. This becomes particularly important for companies operating across Artificial Intelligence, Cybersecurity, Azure, Cloud, and digital transformation, where sales cycles involve multiple stakeholders, technical influencers, business leaders, and evolving buying committees. We recently implemented LinkedIn Sales Navigator with Microsoft Dynamics 365 Sales for a Texas-based technology services company specializing in AI, cybersecurity, Azure, and related cloud services. The objective was not simply to place a LinkedIn widget inside Dynamics 365 — it was much broader: Create a connected prospecting experience where LinkedIn relationship intelligence and Dynamics 365 sales execution could work together without forcing sellers to continuously switch between systems. The implementation brought LinkedIn Sales Navigator capabilities into the organization’s existing Dynamics 365 Sales environment, enabling sellers to research prospects, identify relevant connections, understand account relationships, create and update CRM records, and capture relevant sales activity within the CRM ecosystem. This Dynamics 365 Sales LinkedIn integration as a way to bring real-time intelligence about prospects and organizations into the sales process, including profile information, mutual connections, key decision-makers, and other sales insights. For this organization, the value came from turning that capability into a business process rather than simply a software integration. The Business Requirement The client already had Dynamics 365 Project Operations & Sales as its CRM platform and LinkedIn as an important channel for professional prospecting and relationship building. However, the sales process naturally crossed between the two platforms. A typical seller workflow could involve: Finding a target company. Searching LinkedIn for decision-makers. Researching their background. Looking for mutual connections. Checking whether the person already existed in Dynamics 365. Reviewing the account’s existing opportunities. Deciding how to approach the prospect. Creating or updating the CRM record. Recording the interaction. Returning to Dynamics 365 to continue managing the opportunity. Each individual step is manageable. The problem emerges when this happens repeatedly across dozens or hundreds of prospects. The organization needed to reduce this fragmentation. The business requirement centered around five objectives: 1. Improve prospect discovery Help sellers identify relevant people and organizations more efficiently. 2. Improve relationship intelligence Allow sellers to understand mutual connections, organizational relationships, and relevant prospect information. 3. Reduce application switching Bring useful LinkedIn intelligence directly into the Dynamics 365 sales experience. 4. Improve CRM data quality Create mechanisms for identifying outdated information and reducing duplicate or disconnected prospect records. 5. Preserve CRM as the operational system of record LinkedIn should enhance the sales process, not create a parallel sales database. That last point became one of the most important principles of the implementation. Why LinkedIn Sales Navigator and Dynamics 365? LinkedIn Sales Navigator is fundamentally a prospecting and relationship intelligence platform. Dynamics 365 Sales, on the other hand, provides the CRM and sales execution layer. The strategic opportunity was to combine the two. LinkedIn provides access to professional and organizational intelligence, while Dynamics 365 provides the business context around: Accounts Contacts Leads Opportunities Activities Sales pipeline Ownership Customer history When these systems are connected correctly, the seller does not need to think in terms of two disconnected applications. Instead, the experience becomes: Discover → Understand → Engage → Capture → Progress LinkedIn’s Sales Navigator highlights CRM Sync capabilities such as auto-save, activity writeback, CRM badges, ROI reporting, and search filtering. CRM integration is available with Sales Navigator Advanced Plus. D365 CRM allows to surface LinkedIn information directly within Dynamics 365 Sales through Sales Navigator controls and embedded experiences. What We Set Out to Achieve Our objective during the implementation was to go beyond the technical connection. … Continue reading From Prospecting to Pipeline Intelligence: How We Embedded LinkedIn Sales Navigator into Dynamics 365 Sales for a Texas-Based, Cybersecurity & Azure Services Company →

Summary In rapidly evolving sales organizations, business requirements rarely remain static. New products, services, sales categories, commercial models, and operational scenarios can continuously introduce the need for additional values in Dynamics 365. For one of our clients, this resulted in a recurring dependency on the technical team. Whenever the business needed to add or modify values in a Dynamics 365 Choice column, they had to approach the implementation team for a seemingly small configuration change. At first glance, replacing the Choice column with a Lookup table appeared to be a natural solution. However, that approach would introduce a much larger change: migrating existing records, replacing references throughout the application, modifying system processes, reviewing integrations, and potentially impacting logic that already depended on the existing Choice values. Instead of redesigning the data model to solve a configuration problem, I approached the requirement from a solution-architecture perspective. I built a self-service Dataverse Choice Manager that allows authorized users to select a Dataverse table and Choice column, add or update options, publish the metadata, and automatically create an audit record and notify system administrators. The solution uses supported Dataverse Web API and Metadata APIs to perform controlled schema-level operations while introducing governance, auditability, and guardrails around those changes. The result is a model where the business can adapt its Choice values without continuously depending on developers, while the technical team retains control over security, governance, auditing, and platform integrity. Case Study Read more about our Journey with this Customer over here: View Case Study Table of Contents Introduction Business Requirement The Architectural Decision How I Solved It Implementation Procedure End-to-End Working Custom Auditing and Governance Working Within Dataverse Platform Boundaries Benefits of the Solution Limitations and Guardrails Conclusion Introduction Dynamics 365 implementations often evolve alongside the businesses they support. A sales organization may initially define a finite set of values for a Choice column. Over time, however, new products are introduced, sales processes change, new commercial categories emerge, and terminology evolves. The technical change may appear trivial: “I just need to add one more option to this Choice field.” But when the same request occurs repeatedly, a different problem emerges. The business becomes dependent on the technical team for configuration changes that are fundamentally part of day-to-day business evolution. For one of our clients, this pattern was becoming increasingly common. The organization is highly sales-focused and operates in an environment where business requirements continue to evolve. The question therefore became: Can I give the business controlled self-service access to Choice values without redesigning the existing Dataverse data model? Rather than immediately changing the schema, I looked at the problem from a solution-design perspective. The answer was to build a controlled metadata management layer over Dataverse. Business Requirement The client’s requirement was straightforward: Select a Dynamics 365 table. Select a Choice column. Add a new option when the business needs one. Update an existing option label when terminology changes. The challenge was not simply performing these operations. The challenge was performing them safely. A typical Dynamics 365 user does not need unrestricted access to the Dataverse schema. Giving users broad customization privileges would create an entirely different governance problem. I therefore needed to balance two competing objectives: Business agility The sales team should not need to raise a development request every time a new Choice value is required. Technical governance The organization still needs to know: Who made the change? What was changed? When was it changed? Which table was affected? Which Choice column was affected? What was the previous value? What is the new value? Was the change successfully published? This led us to a more important architectural principle: Self-service does not have to mean unrestricted access. The solution should expose only the operations that the business needs while keeping the underlying metadata APIs behind a controlled interface. The Architectural Decision Option 1: Replace the Choice with a Lookup One possible solution was to replace the existing Choice column with a Lookup pointing to a new Dataverse table. Conceptually, this would provide an excellent long-term model for highly dynamic business values. For example: Sales Record | +– Category Lookup | +– Category A +– Category B +– Category C +– Category D The business could then create new category records without changing metadata. However, the problem was the existing implementation. The Choice column was already being used across the solution. Replacing it would potentially require: Identifying all existing records containing the Choice value. Creating corresponding records in the new Lookup table. Migrating existing data. Replacing the existing field references. Updating JavaScript. Reviewing plugins. Reviewing Power Automate flows. Reviewing business rules. Reviewing integrations. Updating reports and Power BI dependencies. Testing existing processes. Deploying the changes across environments. In other words, a small configuration problem could turn into a substantial data-model transformation. The Architectural Conclusion The problem was not necessarily that the Choice column was the wrong data type. The problem was that the organization needed a controlled way to manage its values. Therefore, rather than redesigning the data model, I preserved the existing architecture and built a self-service management capability around it. How I Solved It I designed a web-resource-based application inside Dynamics 365: Dataverse Choice Manager Dataverse Picklist Manager. The application provides a simple interface through which an authorized user can: Select a Dataverse table. Retrieve the available Choice columns. Select a Choice column. Retrieve its existing options. Add a new option. Update an existing option. Publish the affected table. Generate an audit record. Notify the system administrator. From the user’s perspective, this becomes a simple business operation. From the platform perspective, however, the application is interacting directly with Dataverse metadata. The high-level architecture is: Dynamics 365 User | v Dataverse Choice Manager | +——————–+ | | v v Dataverse Web API Metadata Actions | | | InsertOptionValue | UpdateOptionValue | DeleteOptionValue | PublishXml | v Dataverse Metadata | v Choice Column Updated | +———————-+ | | v v Custom Audit Log System Administrator Email This is where the solution becomes more … Continue reading How a Texas-Based AI and Cybersecurity Services Company Streamlined Dataverse Choice Management in Dynamics 365 →

☼ Light ☶ Sepia ☽ Dark 01Summary Account data in CRM is rarely in one place, with revenue, pipeline, quotes, and years of meeting notes spread across separate records. We built a one-click Account Intelligence Report that runs inside Dynamics 365 and assembles the complete account picture on screen in seconds. With a second click, an AI analyst reviews every appointment note to produce a plain-language engagement history, current status, open commitments on both sides, and talking points for the next meeting. The complete report, combining facts and AI insights, can then be exported as a branded, editable Microsoft Word document with a single click. Everything runs within the signed-in user’s existing Dynamics session, with no new servers or third-party libraries, while inheriting the user’s existing data permissions by design. Table of Contents 01Summary→ 02The 40-Minute Problem→ 03Solution Overview→ 04Technical Approach→ 05Impact→ 06Conclusion→ 07Let’s Talk→ 02The 40-Minute Problem Picture an account manager thirty minutes before a quarterly business review with a customer they have worked with for three years. The relationship is rich. The context, though, is buried. The revenue figure sits on the Account. The live pipeline is spread across a handful of opportunity records. There are a dozen quotes from the last two quarters, most of them not tracked and easy to forget. Then there are the meeting notes. Dozens of appointments, each with its own thread of what was said, promised, and agreed. None of that is missing. It is all in the CRM. The trouble is that it is everywhere at once. To reconstruct the story of an account, someone has to open twenty records, read between them, and hold the whole picture in their head. So they do not bother. They skim the last two meetings, walk in half prepared, and the deeper context stays invisible until it becomes a problem. This is not a data problem in the sense of not capturing enough. It is a synthesis problem. The organisation already holds the intelligence. It simply has no fast, trustworthy way to assemble it into something a human can act on before a meeting begins. ⓘThe real bottleneck The hardest work in account management is rarely finding the information. It is pulling it together. Connecting revenue, pipeline, and history into one coherent, current view, at the exact moment you need it, is where most of the effort actually goes. 03Solution Overview We set out to solve that synthesis problem with the smallest possible footprint, for a U.S.-based manufacturing facility running Dynamics 365 Sales. The result is a single command on the Account form called the Account Intelligence Report. From the account you are already looking at, one click opens a clean, paper-style report inside the application. It is not another tab to manage or another system to log into. It is part of the CRM you already use. The report does three things, in order: It gathers. In seconds it pulls the account’s revenue, its sales-revenue targets, the most relevant quotes, every open opportunity, and all related appointments together with their notes. It reads. A second click sends those meeting notes to an AI model that writes up the account’s engagement history and distils it into clear, decision-ready insights. It delivers. One more click produces a professional, branded Word document, a finished brief you can email, print, or bring into the meeting. The whole experience is built to feel instant. You stay in the flow of your work, and the report comes to you. What the Report Actually Contains The report is organised the way an account manager actually thinks about an account, not the way a database is organised. At the top is a compact dashboard. Revenue, quote totals, open opportunities, and appointment counts sit at a glance. Below that is the structured document itself. Revenue and pipeline at a glance The opening section brings together the numbers that frame the relationship: the customer’s revenue, the potential opportunity, budget and revenue year-to-date, and the estimated revenue outlook. This single block replaces what would otherwise mean cross-referencing the Account record with a separate sales-revenue table. Quotes and open opportunities Next is a focused view of quotes from the last six months, including those not tracked quotes that quietly accumulate and are easy to lose, alongside every open opportunity in the same window, with its stage, originating lead, product segment, and bid date. Totals calculate automatically, so pipeline value is always visible without a manual add-up. Every related appointment, with its notes This is where the report earns its keep. It lists all related appointments and, crucially, lets you expand any meeting to read exactly what was discussed. Attendees are pulled out, and the full substance of each meeting is available inline. For a customer with a long history, this becomes a navigable timeline of the entire relationship, every visit, call, and commitment, in one place. 💡Why appointments are the hard part Meeting history is usually collected through two different paths in CRM. Sometimes a customer is recorded as a participant, sometimes as the subject of the meeting. The report queries both, then merges and de-duplicates the results, so nothing is missed and nothing is doubled. 04Technical Approach The AI Analyst: Years of Notes in One Read Gathering the notes is only half the battle. Someone still has to read them. The "Get AI Insights" action does exactly that. It takes the full set of appointment notes for the account and asks an AI model, Azure OpenAI, to do what a thorough colleague would do before a meeting: read everything, then tell you what matters. The output is deliberately structured, so it slots straight into the report rather than producing a vague paragraph. It returns six things: Engagement history — a single flowing narrative of the relationship from the earliest meeting to the most recent, with dates, attendees, and the key decisions along the way. Current status — a direct read on where things stand and the overall momentum, in two to four points. … Continue reading Dynamics 365 Sales AI: Turn CRM Data into Dynamic Word Reports for Executive Insights →

Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders Summary MCP Servers are making their way into the mainstream, connecting AI applications together with the AI tool of your choice to utilize them. One such powerful MCP Server, amongst several built by Microsoft, is the Dataverse MCP server. This post walks through what Dataverse MCP brings to users across five capability areas, practical use cases by role, the operational efficiency gains we’ve seen internally at CloudFronts, and answers to the questions this naturally raises around data security and scope. Table of Contents 01 Summary 02 A Quick Recap on MCP Servers 03 Dataverse MCP Capabilities 04 Use Cases by Role 05 Business Impact 06 FAQs 07 Conclusion A Quick Recap on MCP Servers Like several business and personal applications have come up with their own MCP Server, one such powerful MCP Server amongst many by Microsoft is the Dataverse MCP server. Before talking about some use cases, here’s a quick recap of what MCP Servers in general are, to set some context for readers stumbling upon “MCP Servers” for the first time: 1They are an API connection between applications, but capable of understanding human language to connect and execute. 2Don’t need technical knowledge to connect different applications and interact with each other functionally, operating on natural language. 3Widely used by AI Agents to talk to each other and get things done. 4Continue to work after the initial setup. So, given that, here’s what Dataverse MCP brings to users. Dataverse MCP Capabilities Briefly, there are 5 main categories in which Dataverse MCP Servers help: 1Discovery — Use Dataverse MCP to explore the schema of your Dynamics 365 CE / Dataverse environment. Assuming you are a technical team member, you need to explore behind the scenes when customizing solutions, which is where Dataverse MCP can be useful. It’ll go under the hood and make sense of your query to bring you the technical details, instead of you having to remember how it is set up and collate that information. Useful for Solution Architects. 2Query — Query data in simple language by just describing, in human language, what you would otherwise design an Advanced Find for. And when it returns this data, it can go a step further and process or work on the info you asked it to fetch (maybe package it in an Excel file, ready to download from your AI application). 3Record CRUD — Although it’ll ask you for permissions, you can ask your AI tool, connected through Dataverse MCP, to create, update, and delete records. The other day, I just made my Time Entries for the week and asked it to collect Invoice information for a custom entity and bulk-update a custom status on some contacts. So, anything that would need you to go into the system and scrub through forms can be done using Dataverse MCP. 4Schema — I would advise using this carefully. Dataverse MCP is capable of also updating the schema, like creating new tables, fields, etc. If done correctly, with the correct publisher and established naming conventions, this is possible. But I did find myself stuck with incorrect schema creation and a bit of a mess. So, this one is to be used carefully. At times, the schema definition is misunderstood, and you’ve already altered what’s set. 5Skills/Playbooks — Upsert and Delete Skills. This topic on Dataverse Skills deserves a separate blog post in itself. Use Cases by Role To keep things simple, here are some common use cases by role on how Dataverse MCP can be useful: 1Solution Architect — you can use Dataverse MCP to query metadata/schema to help identify what the developers have done, if going through developer documentation is too much to go through. 2Manager — if you want to query some data, you can do this by simply establishing some common vocabulary as context first, and then letting Dataverse MCP query what you need, then process that info retrieved within the chat context to make better sense of what you need. 3Developer — if you want to create a series of tables and a templatized field-set in those, you can simply do so by uploading an Excel file and utilizing Dataverse MCP to create the right fields and schema based on the customizations described. Doing this at scale for multiple customers is painstaking and time-consuming, so utilize Dataverse MCP to get this turned around quickly. 4Even your own data — to identify pitfalls and take measures immediately. Every Monday I need to check where I should pay attention the most and get sticking issues out of the way, and this gives me a good understanding, or a high-level picture, of where I need to pay attention. A weekly check-in: asking Claude, connected via Dataverse MCP, to review time entry compliance over the last 90 days. Business Impact We have enabled Dataverse MCP for all team members to help with their operational efficiencies. Business Impact here is operational efficiency gains — if this saves me an hour a day, it saves me 20 hours a month, and about 240 hours a year, which is a significant gain on a broader time horizon. So, if I multiply this by 15 team members, then we are collectively saving 3,600 hours a year, which can be taken back to focus on growth and client projects more so. FAQs Now, this naturally brings some questions to mind, which I thought to anticipate and answer: 1Is the data being used by Claude? No data is copied over to Claude or its models — only MCP (Model Context Protocol) is used to have a conversation with your existing data, in this case Dataverse. No data is sent anywhere. 2Will users be able to query and modify data belonging to someone else? No — only data which belongs to self is available for any operation. It follows the security architecture of the hosting SaaS application itself, in this case Dynamics 365 CRM / Dataverse. … Continue reading Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders →

Summary Our previous article (Check out my previous blog here – Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service) covered how we integrated Dynamics 365 Customer Service with FedEx to automate the creation of return shipments for a USA-based manufacturer — solving the shipment-creation half of the requirement. But creating a shipment is only the start. Once a package leaves the customer, the business still needs to know what’s happening to it — has FedEx received it, is it still with the customer, or has it been delivered? Previously, agents answered this manually by checking the FedEx site case by case, which didn’t scale. The second phase closes that gap with a scheduled integration between Dynamics 365 Customer Service, Dataverse, Integration, and the FedEx Tracking API. It automatically identifies eligible Cases, pulls the latest FedEx tracking events, determines whether the shipment has entered FedEx possession, and updates the Case accordingly. The result is a closed-loop process: Create Shipment → Capture Tracking Number → Monitor Shipment → Detect FedEx Possession → Update CRM. This article covers how the integration was designed, how tracking events were interpreted, how Integration processes the API response, and the technical considerations involved in building against the FedEx Tracking API. Table of Contents From Shipment Creation to Shipment Visibility The Business Challenge Solution Overview Identifying Cases Requiring Tracking Calling the FedEx Tracking API Understanding FedEx Tracking Events Determining Whether a Shipment Has Been Tendered Updating Dynamics 365 Customer Service Handling Exceptions and Empty Tracking Responses Technical Architecture Designing the Integration Around Business Events Business Impact FedEx Tracking API Limitations and Guardrails Final Thoughts This Blog Explains Why shipment creation alone was not enough to complete the return logistics process. How Dynamics 365 Customer Service was connected to the FedEx Tracking API. How eligible Cases are identified automatically. How tracking events such as Dropped Off, Picked Up, and In FedEx Possession are interpreted. How the solution determines when a shipment should be considered tendered. How the latest tracking information is written back to Dynamics 365. How Integration handles API responses and exceptions. The limitations and throttling considerations of the FedEx Tracking API. From Shipment Creation to Shipment Visibility In the previous implementation article (Check out my previous blog here – Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service), the primary objective was to eliminate the manual process of creating FedEx return shipments. The customer service representative could initiate the shipment directly from the Dynamics 365 Case. The system handled the rest: Collect Case and customer information. Register the shipment with FedEx. Generate the return label. Capture the tracking number. Store the tracking number against the Case. Send the return label to the customer. That created a significant improvement in the shipment creation process. However, there was still a gap. The tracking number was now inside Dynamics 365, but the shipment status was still outside Dynamics 365. This highlighted an important principle in integration design: True integration goes beyond just creating data in an external system—its real power lies in closing the information loop. By including end-to-end shipment tracking, we ensure full visibility, proactive exception management, and a seamless experience from order creation to final delivery. The second phase therefore asked a different question: Once Dynamics 365 creates a shipment, can it also continuously understand what is happening to that shipment? The answer was yes. The Business Challenge The existing process (Before FedEx Intg. Was implemented) required customer service representatives to manually monitor return shipments. A typical workflow looked like this: Open Dynamics 365 Customer Service. Find the Case. Copy the FedEx tracking number. Open the FedEx tracking website. Enter the tracking number. Enter the tracking number. Review the latest shipment event. Review the latest shipment event. Determine whether the package had been handed over to FedEx. Return to Dynamics 365. Update the Case status. Repeat the process for other Cases. This created several operational challenges. 1. Repetitive Manual Work Tracking information had to be checked repeatedly for multiple shipments. 2. Context Switching Agents moved between Dynamics 365 and the FedEx tracking website to complete a single business process. 3. Delayed CRM Updates Even when FedEx had already received a shipment, the corresponding Case could remain unchanged until somebody manually checked it. 4. Human Interpretation FedEx returns multiple tracking events and statuses. Agents had to interpret those events and determine which ones represented meaningful milestones for the organization’s return process. 5. Poor Scalability As the number of return shipments increased, the amount of manual tracking increased with it. The business did not need another screen for agents to monitor. It needed the tracking information to come back to the system where the business process was already being managed: Dynamics 365. Solution Overview I extended the previous FedEx integration by introducing an automated shipment-tracking process. The solution uses: Dynamics 365 Customer Service Dataverse Integration FedEx Tracking API The high-level process is: Dynamics 365 Customer Service | v Active Cases with Tracking Numbers | v FedEx Tracking | v Tracking Response | v Interpret Scan Events | v Determine Shipment Status | v Update Dynamics 365 Case The process runs automatically on a scheduled basis. There is no requirement for a customer service representative to manually visit the FedEx website for every shipment. Functional Integration Approach The functional design was intentionally centered around the existing Case lifecycle. The Case already contained the information required to identify the shipment. The integration therefore did not introduce a separate tracking application or another user interface. Instead, it used the Case itself as the operational source of truth. The process can be summarized as: Scheduled Trigger ↓ Find eligible Cases ↓ Read Tracking Number ↓ Call FedEx Tracking API ↓ Read Tracking Events ↓ Interpret Latest Status ↓ Determine Tendered / Not Tendered ↓ Update Case This approach keeps the integration aligned with the business process rather than creating a separate operational process around the API. Identifying Cases Requiring Tracking … Continue reading Closing the Loop on Return Logistics: How a U.S.-Based Consumer Appliance Manufacturer Automated FedEx Shipment Tracking in Dynamics 365 Customer Service →

Turning Lead Chaos into Clarity: How a Massachusetts-Based Manufacturing Business Transformed Its Sales Reporting Summary Sales teams generate a steady stream of leads across sources like trade shows and referrals, yet most organizations can’t answer a simple question in real time: “How is our pipeline actually trending this month?” We built a single-page Sales Dashboard using Dynamics 365 Customer Service lead data and Power BI, giving revenue teams a live, filterable view of lead volume, process stage, qualification, and source mix, all driven by two global slicers: Account and Date Range. The result: manual weekly lead tracking was replaced with a live view that surfaces channel performance and process bottlenecks the moment they appear. Table of Contents 01 Summary 02 About the Customer 03 The Challenge 04 The Solution 05 Dashboard Overview 06 Lead & Stage Trends 07 Source & Geography 08 Business Impact 09 FAQs 10 Conclusion About the Customer Customer Spotlight A US-Based Manufacturing Business Rebuilding a Century-Old Category Headquartered in Massachusetts, our customer is a US-based manufacturer that set out to fix a problem no one had touched in over a century: cooking appliances still running on decades-old heating technology. After five years developing a proprietary heating alloy and real-time smart algorithms, the team launched the world’s first touchscreen toaster, which has since become a #1-selling smart toaster with national media recognition. As the company scaled, it needed a single, always-current view of sales pipeline health to match its fast-growing customer base. The Challenge Dynamics 365 Customer Service captures every lead reliably. The gap wasn’t data capture. It was turning that raw lead data into a view sales leadership could actually act on. Sales managers frequently found themselves asking: 1Is lead volume growing or flattening month over month? 2Where are leads getting stuck in the sales process? 3How many leads are actually converting to Qualified? 4Which lead source is driving the most volume? 5Can we filter all of this down to a single account instantly? Answering these meant exporting Dataverse views into spreadsheets and manually re-pivoting, a process that was slow, error-prone, and quickly out of date. The Solution To eliminate manual reporting, we designed a centralized Sales Dashboard in Power BI using Dynamics 365 Customer Service Leads as the data source. The report is built as a single interactive canvas covering: Lead Volume Trends Month-by-month tracking of lead creation to spot pipeline generation swings early. Business Process Stage Real-time view of how many leads sit at each stage of the sales process flow. Dynamics 365 Customer Service Integration Primary data source connecting lead records, source, county, and qualification status. Power BI Analytics Layer Global Account and Date slicers, source-mix pie charts, and geographic breakdowns. Dashboard Overview The dashboard gives sales leadership an instant read on pipeline health. It consolidates the key lead metrics into one interactive page: Count of Leads Leads by Month Business Process Stage Qualified Leads Qualified by Month Lead Source Mix Leads by County Account Filter Date Range Filter The dashboard includes interactive filters for Account and Date Range at the top of the page, enabling instant re-analysis across any account or time window without rebuilding a single visual. Lead & Stage Trends Rather than reviewing lead counts only at month-end, management can continuously monitor: Monthly lead creation volume vs. prior months How many leads currently sit in each business process stage Qualified lead volume by month, compared against total leads created These trends quickly surface slowing lead generation, stalled leads sitting too long in the pipeline, or a widening gap between leads created and leads qualified, turning lead tracking into an operational management tool rather than a monthly snapshot. Lead Source & Geographic Breakdown Understanding where leads come from matters as much as how many arrive. The report breaks leads down by Lead Source and County, helping marketing and sales identify: Which channel, trade show or referral, is driving the most volume Whether marketing spend is aligned with actual lead-generating channels Gaps in geographic data capture, such as an unpopulated County field Regional concentration of leads once location data is fully captured Filtering by Account and Date Using the page-level Account and Date slicers, users can instantly narrow the entire dashboard to answer strategic questions such as: How is a specific account’s lead activity trending? How did lead volume compare across a specific quarter? Where should the next trade-show investment go? Business Impact Before After Lead volume tracked manually in spreadsheets Live month-by-month lead trend in Power BI No visibility into where a lead sits in the sales process Business Process Stage visual shows real-time stage distribution Lead source ROI discussed anecdotally Lead Source pie chart quantifies channel contribution instantly Filtering by account meant exporting and re-pivoting data One dropdown filters the entire dashboard to a single account Qualified lead conversion checked only at month-end Continuous lead-to-qualified tracking across the year Frequently Asked Questions 1Does Dynamics 365 Customer Service provide pipeline reporting out of the box? Dynamics 365 Customer Service captures the underlying lead and process-flow data, but organizations typically need a customized Power BI report to combine lead volume, stage, source, and geography into one actionable view. 2Why show Business Process Stage alongside lead volume? Volume alone doesn’t tell you if leads are moving through the pipeline. Pairing stage distribution with monthly volume shows both how many leads are coming in and where they’re getting stuck. 3Who benefits most from this type of report? Sales leadership, marketing teams, and account managers all benefit. Leadership gets portfolio-level pipeline visibility, while account managers can filter straight down to a single account’s lead activity. 4Can this be extended to Opportunities? Yes. The same Account and Date slicer pattern can be reused on an Opportunity-based page to track pipeline value and win rate alongside lead volume. Conclusion Pipeline health is measured by more than how many leads come in. It’s defined by how well they move, where they come from, and whether the data behind them is trustworthy. By connecting Dynamics 365 Customer Service … Continue reading Turning Lead Chaos into Clarity: How a Massachusetts-Based Manufacturing Business Transformed Its Sales Reporting →