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

Executive Summary In Part 1, we explored how Emirates Consortium LLC expanded its use of Microsoft Dynamics 365 Business Central from primarily finance operations into a structured procurement process. The journey begins with a Purchase Request, moves through approval and supplier selection, continues through Purchase Quotes, and ultimately reaches the Purchase Order stage. For Emirates Consortium, however, creating a Purchase Order is not simply the final step in procurement. It is also an important financial control point. The implemented solution evaluates the Purchase Order against the applicable departmental budget and provides visibility into the available budget, any budget shortfall, and whether a budget revision is required. This creates a connected process in which procurement decisions and financial controls are managed within the same ERP environment. Table of Contents Introduction Why Budget Control Matters Budget Validation at the Purchase Order Stage Understanding Budget Information on the Purchase Order What Happens When the Budget Is Exceeded? Finance and Budget Revision Supporting Documentation for Budget Decisions Budget Consumption and Financial Visibility Final Approval Control End-to-End Budget-Control Process Key Benefits Frequently Asked Questions Conclusion Introduction In a procurement process, approving a business requirement and selecting the right supplier are only part of the decision-making process. Organizations also need to determine whether the planned expenditure is aligned with the approved budget. For Emirates Consortium, budgets were previously managed manually through Excel, while certain procurement activities were performed outside Business Central. As part of the broader procurement implementation, the objective was to bring budget visibility directly into the purchasing process and establish a structured mechanism for determining whether planned expenditure could proceed. The customized solution therefore evaluates the Purchase Order against the applicable departmental budget. How Is the Applicable Budget Determined? The budget is identified using a combination of: Department + Budget Year + Budget Month + Category + Subcategory The Purchase Order amount is then compared against the applicable budget to determine whether sufficient budget is available. This provides the foundation for the organization’s over-budget control process. Why Budget Control Matters Without budget visibility, procurement and finance can easily become two disconnected processes. The procurement team may know that a particular purchase is required to support the business, while Finance may know that the relevant department has a defined financial limit. However, without connecting these two perspectives, it can be difficult to determine whether the planned expenditure is within the approved budget. The implemented process brings these perspectives together at the Purchase Order stage. The Purchase Order is therefore more than a document used to communicate an order to a vendor. It becomes a financial control point where planned expenditure can be evaluated against the applicable budget. Budget Validation at the Purchase Order Stage Once a Purchase Quote has been reviewed and finalized, it can be released and converted into a Purchase Order using Make Order. There is no separate approval workflow at the Purchase Quote stage in the implemented process. The primary budget control is applied when the transaction reaches the Purchase Order stage. At this point, the system determines the applicable budget based on: Department Budget Year Budget Month Category Subcategory The Purchase Order amount is then evaluated against the applicable departmental budget. This allows the organization to determine whether the planned purchase is supported by the available budget before the expenditure proceeds further through the procurement lifecycle. Understanding Budget Information on the Purchase Order The customized Purchase Order provides users with visibility into several budget-related fields. Budget Information Purpose Budget Year Identifies the applicable financial year for the budget evaluation. Budget Month Identifies the applicable budget period. PO Budget Amount Shows the budget amount considered for the Purchase Order. Available Budget Amount Shows the amount of budget available for the purchase. Budget Exceeded Amount Shows the amount by which the Purchase Order exceeds the available budget. Budget Available Indicates whether sufficient budget is available. Budget Exceeded Identifies whether the Purchase Order exceeds the applicable budget. Budget Checked Indicates whether the budget validation has been performed. Budget Checked By Identifies the user who performed the budget check. Budget Checked Date/Time Records when the budget validation was performed. Budget Revision Required Identifies whether additional budget consideration is required. These fields provide procurement and finance teams with a common view of the financial position associated with the purchase. Key Questions Answered at the Purchase Order Stage How much budget is applicable to the purchase? How much budget is currently available? Is the Purchase Order within the available budget? If the budget is exceeded, by how much? Is a budget revision required? Who performed the budget check and when? What Happens When the Budget Is Exceeded? The key control comes into play when the Purchase Order amount is greater than the available budget. Rather than treating the Purchase Order as an ordinary purchasing transaction, the system identifies that the planned expenditure requires additional financial consideration. The Purchase Order provides visibility into: Budget Exceeded Budget Exceeded Amount Budget Revision Required This establishes a clear distinction between a Purchase Order that falls within the available budget and one that requires further financial action. The over-budget scenario therefore becomes an explicit part of the procurement process rather than something Finance needs to identify separately after the purchase has already progressed. Budget control visibility when a Purchase Order exceeds the available budget. Why This Matters When budget exceptions are identified directly within the purchasing process, users have greater visibility into the financial implications of a purchase before it proceeds through the final control process. Finance and Budget Revision An over-budget Purchase Order requires a different level of financial consideration from a Purchase Order that falls within the available budget. The implementation establishes the foundation for Finance to handle the budget revision process and ensures that an expenditure requiring additional budget consideration is not treated in the same way as a transaction that already has sufficient budget available. The budget-control framework therefore connects: Purchase Order → Budget Evaluation → Budget Revision, if Required → Final Approval The Purchase Order provides … Continue reading How an Abu Dhabi-Based Diversified Holding Company Built a Budget-Controlled Procurement Process in Dynamics 365 Business Central – Part 2 →

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 We built a Databricks Genie agent for our own PMO at CloudFronts, running on Dynamics 365 data held in a Databricks lakehouse. Project managers ask a question in plain English and get an answer back across resource utilization, time tracking, billing and milestones, tickets and cases, and project status. This blog covers what the agent does, what email sentiment analysis shows that the numbers do not, and how it works inside Microsoft Teams. Table of Contents Introduction The Challenge The Solution See It in Action Business Impact Frequently Asked Questions Conclusion Introduction This started inside our own PMO — the Billing and Delivery Excellence function at CloudFronts. We learned about a project risk when someone escalated it. The warning signs came earlier than that, in email threads and internal notes, but reading every thread across every project each week was not work anyone could take on. The rest of the picture was split across systems. Billing held the invoice that had passed its due date, delivery held the milestone that had moved, support held the ticket that had been open for weeks. No one screen put those next to each other, so the PMO opened each project every week and compiled the status by hand. So we built the agent for ourselves first: a Databricks Genie agent running on Dynamics 365 data held in a Databricks lakehouse, which project managers query in plain English. The Challenge Dynamics 365 Project Operations holds everything a project manager needs — resource assignments, logged hours, billing milestones, project budgets, and delivery timelines. The data is there. The challenge is that getting specific answers from it still requires navigating multiple modules, running reports manually, and in many cases, exporting to spreadsheets to piece things together. This created a set of questions that were surprisingly hard to answer: Identifying which resources are overutilized or sitting idle requires pulling allocation data and comparing it manually against actual hours logged Understanding whether a project is at risk means cross-referencing milestone progress, budget consumption, and team capacity — a process that can take hours Billing questions — what has been invoiced, what is pending, what is approaching a milestone — require moving between finance and project views that are not always aligned Status updates for leadership need to be manually compiled, often pulling from data that was accurate yesterday but may have shifted today The result is that project managers operate on a lag — making decisions based on reports that reflect the past, not the present, and spending time producing those reports instead of acting on them. The Solution — A Genie Agent Built on Databricks and D365 Project Operations We built a Genie agent on Azure Databricks, connected to Dynamics 365 Project Operations. Project managers can now ask questions in plain English and get answers drawn directly from their project data — without building a single report. The agent is designed around the areas that matter most to project managers on a daily basis: a. Resource UtilizationThe agent can answer questions about who is overallocated, which resources have capacity available, and how utilization is trending across the team or a specific project. What previously required pulling allocation reports and comparing them against timesheets can now be answered in a single question. b. Time TrackingProject managers can ask which team members have not logged hours for the week, where hours are being spent versus what was planned, and whether a specific project is tracking within its estimated effort. The agent surfaces this from logged timesheet data in D365. c. Billing and MilestonesThe agent connects billing milestone data with project progress, allowing project managers to ask what is due for invoicing, which milestones are approaching, and whether any billing triggers are at risk of being delayed. This brings finance and delivery into the same conversation. d. Tickets and CasesThe agent surfaces open tickets and cases linked to a project — how many are open, which are overdue, how they are distributed across team members, and whether any are blocking delivery. Project managers can ask for a snapshot of issue health across one or multiple projects without navigating case queues manually. e. Email Sentiment AnalysisOne of the more telling signals of how a project is going is often hiding in the inbox. The agent analyses email communication patterns and sentiment across project stakeholders — flagging when tone is shifting, when a client’s responses are becoming shorter or more urgent, or when concerns are being raised repeatedly. This gives project managers an early, qualitative read on relationship health before it shows up in a formal escalation. f. Project StatusInstead of assembling a status report, a project manager can ask for a summary of where a project stands — budget consumed, milestones completed, risks flagged, and remaining timeline. The agent compiles this from D365 data and presents it in plain language, ready to share or act on. The conversation does not stop at one question. A project manager can ask a follow-up — drill into a specific resource, filter by project phase, or compare two projects side by side — and the agent follows the thread, refining its response at each step. Available directly in Microsoft TeamsThe Genie agent is also available as a Databricks App inside Microsoft Teams — meaning project managers do not need to switch tools to get answers. They can ask questions about their projects, resources, and billing directly from the Teams interface they already work in every day. See It in Action Weekly Work Summary — Time Tracking in ActionA project manager asks Genie for a summary of work completed last week. The agent returns a full breakdown — total hours logged, billable vs non-billable split, project-wise distribution, and key observations — in seconds. Case Detail View — Tickets and Cases in ActionA project manager asks for details on a specific case. The agent surfaces the full case record — status, owner, priority, activity timeline, and a follow-up alert — without the manager needing to … Continue reading From Project Reporting to Project Intelligence: How AI is Transforming Project Management →

Predicting the Demand: Automating Demand Forecasting in Dynamics 365 Business Central Using Azure Logic Apps, Data Lake, and Databricks Summary Knowing how many products to keep in warehouses is tough for manufacturers and distributors. During busy seasons, customer orders can jump 10 times higher than normal. When teams rely on manual spreadsheets, they often run out of products or buy too much and run out of storage space. This article explains a simple, automated solution built with Microsoft Dynamics 365 Business Central, Microsoft Azure, and Azure Databricks. Table of Contents The Problem: Swings in Customer Demand The 5-Step Solution Overview How Data is Collected and Cleaned (Medallion) How the Prophet Forecasting Model Works Clear Decision-Making with Forecasted Metrics Real Benefits for Businesses Frequently Asked Questions What You Will Learn Why manual spreadsheets and static inventory numbers fail when demand spikes. How Azure Logic Apps fetches data from Business Central automatically by using scheduled triggers. How raw records are organized into Bronze, Silver, and Gold layers. How the Prophet model forecasts demand using yearly trends and weekly patterns. How dynamic safety stock gives purchasing teams clear replenishment recommendations. 1. The Problem: Swings in Customer Demand Most manufacturers and distributors face a big challenge: customer demand is not steady throughout the year. Some months are quiet, while other months bring huge surges in orders. Season Months Demand Level What Happens Peak Busy Season June – August 8x – 10x Surge Huge spike in customer orders. Suppliers take longer to deliver, risking major stockouts. Mid-Year Rush January 3x – 4x Normal Quick wave of replacement orders and new account setups. Spring Planning March – May 2x Normal Customers use annual budgets to place advance orders for summer projects. Regular Season Off-Peak Months 1x Baseline Standard, steady daily orders. Why Traditional Methods Fail: Static Rules: Standard ERP rules use fixed inventory numbers all year. These are too small for busy seasons (causing stockouts) and too large for slow seasons (wasting money). Longer Supplier Delays: When everyone orders at once during peak seasons, suppliers take weeks longer to deliver parts. Full Warehouses: Storing large boxes during slow months takes up valuable warehouse space and ties up cash. Manual Spreadsheet Errors: Planning teams spend hours copying and pasting data into Excel spreadsheets without automated forecasting tools. “You don’t need to replace your ERP system. By adding automated cloud forecasting with Azure and Databricks to Dynamics 365 Business Central, past sales history turns into clear, actionable purchasing foresight.” 2. The 5-Step Solution Overview To solve this, we created an automated pipeline that connects daily ERP transactions to cloud forecasting and delivers clear inventory planning targets. How the Automated Flow Works 1 Dynamics 365 Business Central Holds daily sales, purchases, items, and warehouse records. ↓ 2 Azure Logic Apps (Scheduled Ingestion) Fetches data from Business Central automatically by using scheduled triggers without slowing down the ERP system. ↓ 3 Azure Data Lake (Cloud Storage) Stores all historical files securely in one central place. ↓ 4 Azure Databricks (Prophet Model) Cleans the data, runs Prophet forecasting models, and calculates the forecasted buffer stock needed for every item. ↓ 5 Visual Reports in Power BI Forecasted demand and recommended safety stock are displayed in Power BI reports for clear decision-making. 3. How Data is Cleaned & Organized (Bronze, Silver, Gold) In Azure Databricks, data moves through three simple stages known as the Medallion Architecture: Bronze Layer Raw Data Stores exact copies of daily files directly from Business Central (sales, purchases, items, warehouses). Keeps a complete, untouched history so nothing is ever lost. Silver Layer Cleaned Data Fixes missing dates, removes duplicates, and standardizes item numbers across all warehouses. Separates real customer orders from internal warehouse transfers. Gold Layer Forecasting Results Combines daily sales into clear trends and calculates forecasted stock targets for each product. Ready to feed interactive Power BI reports for planners and stakeholders. 4. How the Prophet Forecasting Model Works The Prophet forecasting model analyzes four key factors from past sales: The 3 Things the Model Learns: Overall Growth: Is customer demand growing year over year? Yearly Seasons: Which months have huge order spikes, and which months are quiet? Weekly Patterns: Do customers place most orders on weekdays compared to weekends? By combining these patterns, the system calculates the recommended safety stock for every item and warehouse: Forecasted Safety Stock: The recommended buffer quantity to keep on hand to protect against unexpected surges or supplier delivery delays. 5. Clear Decision-Making with Forecasted Metrics Instead of relying on guesswork in disconnected spreadsheets, supply chain planners have clear, data-driven targets calculated by Azure Databricks. These forecasted metrics give purchasing and warehouse managers actionable recommendations: Projected Demand: Forward-looking estimates of how many units customers will need in upcoming months. Early Order Timing: Clear signals on when to order from suppliers before peak seasons begin. Warehouse Stock Balancing: Guidance on how much inventory to position across regional warehouse hubs. 6. Real Benefits for Manufacturers Order 6–8 Weeks Ahead Purchasing teams get early warnings before big busy seasons, allowing them to book orders before supplier queues fill up. Balanced Warehouses Items are placed in the right regional warehouses closest to where customers will buy them. More Warehouse Space Bulky products arrive only when needed, keeping aisles clear and reducing expensive storage costs. Data-Driven Planning No more spending days building complicated formulas in Excel. Machine learning provides reliable demand curves and inventory targets. 7. Frequently Asked Questions (FAQ) 1 Will this slow down Business Central for daily users? No. Data is copied automatically during quiet nighttime hours into Azure. All calculations happen in the cloud, so Business Central stays fast and responsive for everyday business. 2 Why use the Prophet model instead of standard ERP reorder rules? Standard ERP rules use one fixed number for the entire year. The Prophet model automatically adapts to upcoming seasons, supplier lead times, and sales trends. 3 How do planning teams use these calculated metrics? Planning and purchasing teams access these forecasted metrics directly through interactive Power … Continue reading Predicting the Demand: Automating Demand Forecasting in Dynamics 365 Business Central Using Azure Logic Apps, Data Lake, and Databricks →

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 →

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