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 This article covers the implementation of barcode-based location movement scanning in Dynamics 365 Finance & Operations (WMS) for a North American manufacturing operation. The physical warehouse was built into D365 using an Aisle–Rack–Shelf–Bin location model created through the Location setup wizard, and Work templates, Location directives and Mobile device menu items were configured so that every material movement becomes directed, scanner-guided work. Multi-stage routing with enforced stop-work breaks ensures that complex movements across stations are captured step by step, replacing paper-based and manual location tracking with real-time scanning on the Warehouse Management mobile app. Finally, inventory adjustment journals close the loop so that work-order completion reconciles on-hand inventory accurately. Table of Contents Introduction The Business Problem The Solution Building the Warehouse Location Model (Aisle–Rack–Shelf–Bin) Creating Locations with the Location Setup Wizard Enabling the Worker on the Warehouse Mobile App Work Templates Location Directives Mobile Device Menu Items The Multiple Scanning Movement Process Inventory Adjustment Journals for Work-Order Closure Implementation Considerations & Limitations Business Impact FAQs Conclusion 1. Introduction In Microsoft Dynamics 365 Finance & Operations, the warehouse is only as accurate as the data captured on the floor. Every receipt, put-away and internal move has to be recorded against a precise physical location, otherwise on-hand inventory, replenishment and downstream planning all drift out of alignment. For high-volume manufacturing and distribution operations, keying that information manually is slow, error-prone and impossible to audit after the fact. Location movement scanning solves this by making the warehouse location itself the anchor of every transaction. Instead of typing where something is, an operator scans it. Dynamics 365 F&O Warehouse Management (WMS) turns those scans into directed work — the mobile device tells the worker exactly where to go, what to pick and where to put it, and the system records each step in real time. This article walks through how location movement scanning was designed and delivered for a North American commercial vehicle manufacturing operation as part of a Warehouse Management, Inventory and Scanning rollout. It covers how the physical warehouse was modelled in D365, how the Aisle–Rack–Shelf–Bin location structure was created, and how Work templates, Location directives and Mobile device menu items work together to convert a floor movement into a traceable, scanner-guided sequence — all closing out cleanly against inventory. Scan on the mobile device Directed work system-guided steps Accurate inventory real-time, to the binFigure 1. Location scanning turns a floor movement into directed, traceable work with real-time inventory. 2. The Business Problem The operation runs a large, multi-zone warehouse footprint where materials move continuously between receiving, pick stations, sub-assembly areas and staging. Before the D365 F&O rollout, location tracking depended heavily on manual entry and local knowledge. Workers knew where things were, but the system frequently did not. As volume and layout complexity grew, several operational problems surfaced: On-hand inventory did not reliably reflect the physical location of stock. Internal movements between aisles, racks and stations were captured inconsistently, or after the fact. There was no directed, enforced sequence for multi-step movements, so steps were skipped or done out of order. Work could not be traced — it was difficult to prove who moved what, from where, to where, and when. Manual keying of long item and location codes introduced errors that rippled into planning and replenishment. Reconciling inventory at the end of a work order required time-consuming manual investigation. The business needed the physical warehouse represented accurately inside D365, and every movement on the floor captured through scanning — directed by the system, enforced in the right order, and reconciled against inventory without manual guesswork. The Objective: Model the warehouse down to the bin, and make every material movement a scanner-directed, traceable transaction so on-hand inventory, work status and location data stay accurate in real time. 3. The Solution Dynamics 365 F&O Warehouse Management provides the full building blocks for scanner-directed movement: a structured location hierarchy, Work templates that define the sequence of steps, Location directives that decide where each step happens, and Mobile device menu items that expose the process on the handheld scanner. The solution was assembled in layers — first the physical location model, then the worker enablement, then the three configuration objects (templates, directives, menu items) that turn a movement into directed work, and finally the inventory reconciliation that closes it out. Work templatesWHAT stepsPick · Custom · Put sequenceLocation directivesWHERE it happensresolves the exact binMobile menu itemsHOW on the scannerstart / resume work Directed, scanner-guided work every floor movement — enforced & traceableFigure 2. Work templates, Location directives and Mobile menu items combine into a single directed-work engine. 3.1 Building the Warehouse Location Model (Aisle–Rack–Shelf–Bin) The foundation of location scanning is a location structure that mirrors the physical warehouse. In this rollout the model followed an Aisle–Rack–Shelf–Bin hierarchy, using a location profile (RSBA) applied consistently across warehouse zones such as floor locations, tugger lanes and rack storage. Each physical position becomes an addressable location in D365 that a barcode can represent. Getting this hierarchy right is what allows a single scan to resolve to an exact bin. Location hierarchy Site └─ Warehouse └─ Aisle └─ Rack └─ Shelf └─ Bin ← scannable location SiteWarehouseAisleRackShelfBin — scannable locationFigure 3. The Aisle–Rack–Shelf–Bin location hierarchy modelled in D365, resolving to a scannable bin. 3.2 Creating Locations with the Location Setup Wizard Locations were generated using the Location setup wizard rather than created one by one, which keeps naming consistent and saves considerable effort across a large footprint. Navigation Warehouse management > Setup > Warehouse > Locations > Location setup wizard Steps 1. Open the Location setup wizard 2. Set up all relevant details (profile = RSBA, aisle/rack ranges) 3. Click Create 4. Repeat per bin identifier: Enter “A” → Create Enter “B” → Create Enter “C” → Create Because the bins were A, B and C, the create step was repeated for each. To verify, open the Location field, filter by “C”, and confirm every location generated for the “C” rack is present. The same wizard-driven … Continue reading Location Movement Scanning in Dynamics 365 Finance & Operations: Turning Warehouse Floor Movements into Traceable, Scanner-Directed Work →

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 As part of our implementation for HDFC Maldives, we encountered a complex payment approval requirement in Microsoft Dynamics 365 Business Central involving multiple approval stages, any-one-user approval behavior, Checked By validation, actual approver tracking, and Internet Banking approval. Instead of replacing the standard Business Central workflow framework, we extended it only where the required business behavior differed from the standard process. This approach allowed us to retain Workflow User Groups, Approval Entries, workflow progression, and standard approval capabilities while introducing custom controls for Checked By processing, Sequence 2 approval handling, actual approver logging, and final payment voucher traceability. Table of Contents Introduction Understanding the Business Requirement What Worked with Standard Business Central? The Challenge at the Second Approval Sequence Finding the Right Approach The Second Challenge: Who Actually Approved? Introducing the Actual Approver Log Why Checked By Was Kept Separate Automatic Transition to Standard Approval Improving Payment Voucher Traceability Final Solution Architecture Preview Video Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows often look straightforward when they are first discussed: one person submits a transaction, the required approvers review it, and the process continues once approval is completed. In practice, the requirements can become much more complex when different stages need different approval behaviors. During a loan management implementation for a Maldives-based financial services organization, we encountered exactly this situation while designing the approval process for Payment Journals in Microsoft Dynamics 365 Business Central. The business did not want a simple sequential approval process. Some stages required any one authorized user to complete the approval, another stage required a separate pre-check before the standard workflow could begin, and the final payment process required two Internet Banking approvals. The challenge was therefore not simply to configure a workflow. It was to determine how much of the standard Business Central approval framework could be retained, where customization was genuinely required, and how to maintain an accurate audit trail of the users who actually performed each approval action. The Design Principle Rather than replacing Business Central’s standard workflow framework, we decided to keep the standard approval engine wherever possible and customize only the areas where the required business behavior differed from the standard process. Understanding the Business Requirement The Payment Journal required several approval stages, with different rules at each level. Stage Approvers Required Behavior Checked By Multiple Checkers Any one authorized checker Sequence 1 2 Approvers Any one approver Sequence 2 4 Approvers Any one approver Internet Banking 2 Approvers Two-level validation The intended business process was: Payment Journal → Checked By – Any One → Sequence 1 – Any One of 2 → Sequence 2 – Any One of 4 → Posting → Internet Banking Approval At first glance, the standard Workflow User Group functionality appeared capable of handling most of this requirement. However, testing revealed an important difference between the expected business behavior and the approval behavior encountered at the later approval sequence. Fig: Payment approval workflow configured for the multi-stage payment process. What Worked with Standard Business Central? Workflow User Groups were the natural starting point because they already provide a structured way to maintain approvers without hardcoding individual users in custom development. For the first approval sequence, two approvers were configured and the required behavior worked as expected. Sequence 1 Approver A + Approver B → Any one approver completes the stage → Workflow continues This initially suggested that the standard approval configuration would be sufficient for the entire process. The benefit of continuing with standard Business Central was significant because the platform was already managing Workflow User Groups, Approval Entries, statuses, approval requests, cancellations, notifications, and workflow progression. The Challenge at the Second Approval Sequence The main challenge appeared when the transaction progressed to the second approval sequence. Four approvers were configured at this level, but the business requirement remained the same: any one of the four authorized approvers should be able to complete the stage. Expected Behavior Approver C / Approver D / Approver E / Approver F → Any one approves → Approval stage completes However, the workflow behavior encountered at this subsequent sequence did not allow the stage to complete in the required manner after only one user approved. The transaction remained pending because the approval requests associated with the sequence were still active. This created the central mismatch between the standard workflow behavior encountered during testing and the customer’s required approval model. Finding the Right Approach One option would have been to replace the approval process entirely with a custom approval engine. We deliberately avoided that approach. Business Central was already successfully handling several important parts of the process: Workflow User Groups Approval Entries Approval statuses Sending approval requests Cancelling approval requests Workflow progression Rebuilding all of this would have introduced unnecessary complexity and additional maintenance. The Approach Keep the standard Business Central workflow and customize only the approval behavior that did not meet the business requirement. For the second approval sequence, we introduced a custom Approve Approval Request action that allows one authorized approver to complete the required stage while preserving the surrounding standard workflow framework. :contentReference[oaicite:4]{index=4} The Second Challenge: Who Actually Approved? Solving the approval progression created another important requirement. When one user completed the customized approval stage, the related standard Approval Entries could ultimately reflect an Approved status for the eligible approvers. Consider four users: Approver C Approver D ← Actually clicked Approve Approver E Approver F If the final Approval Entries are reviewed only by status, they may not clearly identify that Approver D was the person who physically performed the approval action. This became especially important because the Payment Voucher needed to answer a very simple audit question: Who actually clicked Approve? The standard Approval Entry status alone was therefore not sufficient for the reporting requirement. :contentReference[oaicite:5]{index=5} Introducing the Actual Approver Log To preserve the identity of the person who actually performed the approval, we introduced a separate Actual Approver Log. At the moment the user performs the approval action, the solution captures: User ID … Continue reading How a Maldives-Based Loan Firm Streamlined Multi-Level Payment Approvals with Microsoft Dynamics 365 Business Central →

01Summary A leading North American manufacturer of heavy-duty commercial vehicles moved three years of procurement history from a legacy ERP into Dynamics 365 Finance and Operations, and roughly 4,000 of those Purchase Orders were already cancelled in the source system. The Data Management Framework imported them as records without complaint, but DMF cannot run a PO cancellation, so those orders landed in D365 F&O as confirmed supply and the first test Master Planning run returned net requirements of zero for hundreds of items the assembly line actually needed. CloudFronts extended the DMF staging entity with a cancel flag and added a post-import X++ batch job that reads the flag and calls the same cancellation API behind the Cancel button on the Purchase Order form. All 4,000 cancelled POs now hold the correct state in D365 F&O, MRP plans against real supply, and a reconciliation log gives procurement a line by line count to check against legacy. Table of Contents 01Summary→ 02About the Customer→ 03Business Challenges→ 04Solution Overview→ 05Technical Approach→ 06Business Impact / Key Takeaways→ 07Conclusion / Final Thoughts→ 08Call to Action / Connect With Us→ 02About the Customer Our customer is one of North America’s leading manufacturers of heavy-duty commercial vehicles, operating an extensive network of manufacturing and logistics facilities. As part of its supply chain operations, the organization manages high-volume production, component manufacturing, and distribution processes that require seamless integration across enterprise systems. 03Business Challenges The customer builds heavy-duty commercial vehicles across a network of manufacturing and logistics facilities, running high-volume component production that feeds a fixed assembly schedule. Master Planning was a go-live dependency, not a phase two item. If MRP could not be trusted on the first run, the build schedule could not be trusted either. Uncancelled POs are phantom supply D365 F&O nets demand, meaning sales orders, production orders and forecasts, against supply, meaning on-hand inventory, Purchase Orders and planned orders. Every confirmed PO counts as expected incoming material. Import 4,000 cancelled legacy POs as confirmed orders and the planning engine sees 4,000 supply lines that no vendor will ever ship. The arithmetic is unforgiving. Net requirement is demand minus supply, so inflating supply with dead orders drives net requirement to zero or below. MRP then raises nothing. The warehouse stays empty and the line stops. ⚠One PO can suppress an entire item A single uncancelled PO for a high-value component, an engine assembly, a transmission housing or a steel frame, suppresses MRP planning for that item across every production order that needs it. At 4,000 phantom POs, the whole planning output stops being usable. Where the existing pipeline stopped Legacy system exports PO line recordsEvery Purchase Order, active or cancelled, leaves the legacy ERP as a flat file record. DMF imports the records into D365 F&OPO lines land in PurchTable and PurchLine through the standard Purchase Order Lines data entity. Backend automation approves and confirms POs starting with NThe automation picks up everything matching that number series prefix and pushes it through approval and confirmation. That pipeline handled active orders well. The cancelled ones broke it in four separate ways. No flag in the file. The legacy export mixed active and cancelled POs, and the DMF entity carried no field to mark which ones needed cancelling in D365 F&O. The automation confirmed the wrong orders. It ran on every PO matching the number series, so orders cancelled in legacy were approved and confirmed into live supply commitments. Manual cancellation cost weeks. The UI cancels one PO at a time. The team sized 4,000 POs at three to four weeks of clicking, and MRP could not run reliably until that cleanup finished. No reconciliation record. Even a manual pass would leave no structured log proving each cancellation completed, and no way to match the cancelled count between legacy and D365 F&O. Why the cancelled POs could not simply be dropped from scope MRP accuracy was the reason this work became non-negotiable, but three other requirements pointed the same way. Audit and compliance. Procurement auditors trace why a purchase was raised, who approved it and why it was reversed. Three years of history with the cancellations missing is a history with holes in it. Vendor performance analysis. Cancellation patterns are where lead time failures and specification mismatches show up. Migrate only active and completed POs and procurement loses the evidence it negotiates with. Financial reconciliation. Cancelled POs that carried prepayments, accruals or commitments have to exist in D365 F&O so finance can close out historical transactions without opening the legacy system again. 04Solution Overview Before the fix makes sense, one thing about D365 F&O has to be clear. Cancelling a Purchase Order is not a data update. It is a business operation, and the status field is the last thing it touches, not the first. What the Cancel button actually does Validation checks. The system tests eligibility. Has a product receipt posted against any line? Has an invoice been matched? Are registrations pending? Any of these blocks the cancellation or narrows it to specific lines. Workflow recall. If Change Management is enabled, the approval workflow is recalled so the PO leaves its approved state through the proper channel instead of a status override. Accounting distribution reversal. Encumbrances, pre-encumbrances and budget reservations created at confirmation are reversed or voided. Inventory marking cleanup. Marking references between PO lines and sales or production order lines are removed. MRP exclusion. The PO drops out of Master Planning calculations and stops counting as incoming supply. For this migration, that was the step that mattered. Status update. Only once all of the above completes does the PO status become Cancelled. The Purchase Order Lines DMF entity writes field values into PurchTable and PurchLine. It does not invoke any of those six steps. Push a status value of Cancelled through DMF and you get one of three outcomes, a validation failure, a silently ignored value, or a written status with none of the underlying logic behind it. That third outcome is the dangerous … Continue reading How a Leading North American Commercial Vehicle Manufacturer Bridged the Legacy PO Cancellation Gap in Dynamics 365 Finance & Operations Using DMF and X++ →

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 Part 1 covered the data model behind a certification Agreement Manager in Microsoft Dataverse: eleven tables, a strict ownership boundary that leaves signing to Adobe Acrobat Sign and document storage to Azure Blob, and a coverage model whose whole purpose is to let certification logic answer a question with a query instead of a judgement call. This part covers the automation built on top of it, and it is written against the environment rather than the specification. I went back into the development org and checked, because a build note written at two in the morning is not evidence. What is there: six cloud flows, all activated, a validation action with a plugin step behind it, Adobe configured with real workflow identifiers, and eight agreement requests that have genuinely run through the process, four of them to Fully Executed. What is not there: the custom API that creates coverage, which was never built. Nothing else is permitted to write coverage, so the coverage table is empty. The interesting part is that the system already says this about itself. 02In This Blog What is actually deployed, verified against the environment, and what the gap between the specification and the org tells you about handing work over. The Scenario: A finished data model that still needed to send agreements, track them, store evidence, and produce coverage. The Approach: A decision table fixing flow against plugin against custom API for every operation, written before any automation existed. The Action: Six solution aware flows, a validation action with a plugin behind it, and Adobe wired to real template workflow identifiers. The Outcome: A process that runs end to end up to signature, and one clearly identified missing component that the validation data names out loud. A half finished system is safe to inherit when it tells you what is missing. It is dangerous when you have to find out. Table of Contents 01Summary→ 02In This Blog→ 03Where Part 1 Left Off→ 04Flow, Plugin, or Custom API→ 05What Is Built, and What Comes Next→ 06The Coverage Gate→ 07Impact→ 08Conclusion→ 09FAQ→ 10Get in Touch→ 03Where Part 1 Left Off The foundation was eleven Dataverse tables in three layers. A configuration layer holding Agreement Type, Agreement Template Version, Agreement Role Definition and Agreement Requirement Policy. A process layer centred on Agreement Request with four parental children: Agreement Party, Agreement Recipient, Agreement Document and Agreement Validation Issue. An evidence layer of Agreement Coverage and Agreement Coverage Scope. Adobe Acrobat Sign for Microsoft Dynamics 365 owns signature execution. Azure Blob Storage owns the binaries. Dataverse owns the business decision. Eight alternate keys hold the integrity guarantees, the strongest being the one that makes a second active coverage for the same scope impossible. Everything below assumes that foundation, because the specification forbade starting automation until the tables, keys, forms and views were finished and validated. That sequencing held, and it is the reason the automation layer is as small as it is. 04Flow, Plugin, or Custom API Most Power Platform builds decide implementation style per developer preference, which produces a system where nobody can predict where a given behaviour lives. This build used one canonical decision table, written before any automation existed. Operation Preferred implementation Escalate to code when Validate Agreement Request Solution aware flow or command action that clears unresolved issues, writes new ones, and updates the validation summary The gate needs synchronous reuse, in which case it is promoted to a custom API Send for Signature Power Automate using the Adobe connector, only after validation leaves no blocker Multiple callers need one stable callable action Adobe status sync Adobe managed app plus a lightweight sync flow where needed Concurrency or idempotency require server side code Retrieve and store documents Power Automate for small files, Azure Function for large ones Blob SDK, managed identity, hashing or retry handling are awkward in a flow Create Coverage Custom API, mandatory. A pure flow is explicitly not acceptable Always, because supersession must be transaction safe Open final document Flow or Azure Function generating a short lived link Managed identity and key vault access are easier in a function Coverage gate Synchronous plugin or custom API Certificate issuance must be blocked immediately rather than eventually The canonical matrix. Deviating from it required a written justification, not a preference. Why coverage creation cannot be a flow Creating active coverage means superseding the previous active row, clearing its key, linking the supersession, and inserting the replacement. A flow performs those as separate operations, so a failure between them leaves the legal entity with either no coverage or two. A custom API performs them in one transaction, which is why the specification made it mandatory rather than preferred. The three custom APIs Validate Agreement RequestRe runs validation, populates the policy reference date if blank, enforces legal review approval where the agreement type demands it, upserts validation issues by alternate key, and returns a summary with blocker and warning counts. Create Agreement CoverageResolves policy and scope, builds the coverage match key, supersedes the prior active row and inserts the new one in a single transaction, creates the scope rows, and moves the request to Coverage Created. Evaluate Coverage GateGiven an account, legal entity, agreement type code, scope context and reference date, returns pass, block or exception with the reason and the coverage identifier that satisfied it. 05What Is Built, and What Comes Next It is worth being precise here, because a diagram of the full design would overstate what runs. The following is what the environment reports, not what the specification asked for. Figure 1: What is running today, and what is designed and waiting The automation, as deployed Component What it does State in the environment Validate Agreement Request Writes a structured issue row for every problem found on a request Custom action and plugin step, both activated FLW-01 Send for Signature Hands the prepared agreement to Adobe Activated FLW-02 Adobe Status Sync Brings signing progress back onto the request and … Continue reading How a Sustainability Certification Nonprofit Automated Agreement Management with Adobe Acrobat Sign and Power Automate →

Summary This article covers the implementation of the Vendor Collaboration Portal with Request for Quotation (RFQ) in Dynamics 365 Finance & Operations for a North American manufacturing operation. Vendors were enabled for collaboration and given portal access, RFQs were created and dispatched to one or more suppliers, and vendors responded with price, delivery date and comments directly in the portal. Buyers then compared the responses side by side, accepted the winning quote, and generated a purchase order carried at the quoted price — which flowed straight into the PO approval workflow. The result replaced scattered email-based quoting with a single, structured, auditable sourcing process. Table of Contents Introduction The Business Problem The Solution Vendor Setup for Collaboration Portal User Setup The RFQ Process, Step by Step Considerations & Limitations Business Impact FAQs Conclusion 1. Introduction Sourcing decisions are only as good as the quotes behind them. In many procurement teams, requests for pricing go out over email, come back in inconsistent formats, and get compared in a spreadsheet that no one can audit later. Dynamics 365 Finance & Operations addresses this with Vendor Collaboration — a supplier-facing portal — and the Request for Quotation (RFQ) process that runs on top of it. With this in place, a buyer raises an RFQ inside D365, sends it to selected vendors, and those vendors log in to a secure portal to submit their price and delivery commitments. The buyer compares the responses in one place, accepts the best offer, and turns it into a purchase order without re-keying a single line. This article walks through how the capability was configured and operated end to end. Enable vendorfor collaborationCreate &send RFQVendor submitsquote in portalBuyer compares& acceptsCreate POat quoted priceSubmit toapprovalFigure 1. The RFQ journey — from enabling a vendor on the portal to a purchase order in the approval workflow. 2. The Business Problem Before the rollout, collecting quotes was a manual, email-driven exercise. That created several recurring problems: Quotes arrived in different formats, making a fair side-by-side comparison difficult and slow. There was no single record of who was asked, what they offered, and why a supplier was chosen — weak auditability. Re-keying accepted prices into a purchase order introduced errors and delay. Sending the same request to multiple vendors, and tracking their replies, was hard to manage. Supplier onboarding and access were handled ad hoc, with no controlled activation. The Objective: Give suppliers a controlled self-service portal to respond to quotation requests, and give buyers a structured, auditable way to compare offers and convert the winner into a purchase order in a few clicks. 3. The Solution The solution has three parts: enabling the vendor for collaboration, provisioning the portal user, and then running the RFQ cycle itself. Each is described below with the exact navigation used. 3.1 Vendor Setup for Collaboration The vendor record is prepared first so the supplier can be invited to the portal and confirm orders automatically. Navigation : Accounts payable > Vendors > All vendors 1. Enter the vendor Contact name and Email 2. Enable the vendor for Vendor Collaboration 3. Set PO Confirmation = Auto 3.2 Portal User Setup Next, the individual portal user is created and activated through the standard user request workflow, which runs automatically. 1. In All contacts, add the user: Name, Email address, and Vendor details (assign the legal entities) 2. Click Activate 3. Workflow runs automatically: System administration > Workflows > User workflows > User request workflow (platform) 4. Verify activation: Vendor collaboration > Contacts > Vendor collaboration users 3.3 The RFQ Process, Step by Step With the vendor and user in place, the buyer runs the quotation cycle. Prices are intentionally left blank on creation — the vendor supplies them. Navigation : Procurement and sourcing > Request for quotations > All RFQs Step 1 Create RFQ — add Vendor(s) on the header, and Item, Quantity and Delivery date on the lines. Keep Price blank. Step 2 Send — click Send (selected lines) or Send all. The vendor receives the RFQ in the portal. Step 3 Vendor responds — logs into the portal, enters Price, Delivery date and Comments, then clicks Submit. Step 4 Buyer reviews — open the RFQ, view replies, compare Price, Delivery date and Terms. Step 5 Accept — select the winning vendor response and click Accept. Step 6 Create purchase order — the PO is created at the vendor quote price. Step 7 Submit workflow — open the PO and click Workflow > Submit. RFQ cycle — buyer and vendor actions1Create the RFQ (vendor, item, quantity, delivery date; price blank)2Send the RFQ to one or more vendors via the portal3Vendor submits price, delivery date and comments in the portal4Buyer reviews and compares all vendor replies5Accept the winning quote6Create the purchase order at the quoted price7Submit the PO to the approval workflowFigure 2. The seven-step RFQ cycle, from creation to a submitted purchase order. Multiple vendors can be added on a single RFQ header, so the same request goes out to a competitive field and every reply lands back against one record. 4. Considerations & Limitations A few configuration choices shape how the process behaves in practice. Configuration point Setting used What it controls PO Confirmation Auto Purchase orders confirm automatically once created from the accepted quote. Vendor Collaboration flag Enabled Grants the vendor access to the portal to receive and respond to RFQs. Price on RFQ line Left blank Deliberately empty so the vendor supplies the price — the basis for comparison. Multiple vendors on header Supported One RFQ can be sent to several suppliers for competitive quoting. User activation Workflow-driven Portal users are activated through the platform user request workflow, keeping access controlled. Note: The portal experience depends on correct vendor contact and legal-entity assignment. If a user is not activated through the user request workflow, they will not see RFQs in the portal. 5. Business Impact Moving quoting onto the collaboration portal delivered clear operational gains: Faster quote turnaround, because vendors respond directly in … Continue reading Vendor Collaboration in Dynamics 365 Finance & Operations: Running Request-for-Quotation from Portal Invite to Purchase Order →