01Summary A manufacturer of custom steel windows and doors was running its entire sales pipeline through a default BPF that ended at the Opportunity stage. Once a deal was won, production tracking moved to spreadsheets and email threads. Sales could not tell a client where their order stood. Operations had no consolidated view of which orders were in engineering review, which were in fabrication, and which were waiting on finishing. CloudFronts designed and implemented a multi-entity Business Process Flow in D365 Sales that spans Lead, Opportunity, and a custom Order Fulfillment entity. The BPF now tracks every order through its production stages, from engineering sign-off through fabrication, finishing, quality inspection, and dispatch. Sales sees order status without calling the shop floor. Operations reports on production bottlenecks across the full pipeline. Table of Contents 01Summary→ 02Business Challenges→ 03Solution Overview→ 04Technical Approach→ 05Business Impact→ 06Conclusion→ 07Connect With Us→ 02About the Customer A manufacturer of custom steel windows and doors uses Dynamics 365 Sales to manage its customer relationships and order pipeline. The business builds bespoke, high-specification products where every order is unique, every unit requires individual engineering, and every delivery carries a direct reputational commitment to the client. 02Business Challenges Every product this manufacturer builds is bespoke. Every steel window and door is individually engineered, fabricated, and finished to specification. Every delivery carries a direct reputational commitment to the end client, whether that client is a homeowner, an architect, or a commercial developer. The sales cycle does not end when the deal is won. It ends when the product is delivered, installed, and accepted. The D365 Sales environment had been live for over a year when CloudFronts began the engagement. The standard Lead-to-Opportunity BPF was in place. The problems started the moment a deal moved to Won. Production tracking lived outside the CRM. Once an opportunity was marked as Won, the order moved to a shared spreadsheet. The operations team tracked engineering review, fabrication, finishing, and dispatch dates in separate columns. Version control was manual. Updates were delayed. Sales had no visibility into order status. When a client called to ask where their order was, the sales rep had to phone or email the shop floor. The answer took hours, sometimes a day. For a business built on bespoke, high-specification products, that delay eroded the client experience. No single view from inquiry to delivery. Management could report on pipeline (leads and opportunities) or on production (the spreadsheet), but not on the full journey from first inquiry to delivered product. There was no way to measure the total cycle time from lead capture to dispatch, or to identify where orders stalled. The lead form had accumulated 40+ custom fields. Contact data, project specifications, engineering notes, and production preferences were all on the Lead entity. Sellers filling in a new inquiry from a trade show had to scroll past glazing specification fields that only mattered later. The form was slow to load and difficult to use on mobile. No distinction between project types in the process flow. A residential architect requesting a quote for three casement windows and a commercial developer scoping a 200-unit curtain wall project followed the same BPF stages. The qualification criteria, production complexity, and delivery timelines are fundamentally different, but the system treated them identically. 03Solution Overview CloudFronts designed a multi-entity Business Process Flow that extends the sales process beyond the Opportunity into production. The BPF spans three entities: Lead, Opportunity, and a custom Order Fulfillment entity. Instead of ending at Won, the process flow continues through the production stages that define this manufacturer’s delivery commitment: engineering review, fabrication, finishing, quality inspection, and dispatch. The Lead entity was trimmed to fewer than 15 fields. Contact details, referral source, project type (residential or commercial), and initial product interest (windows, doors, curtain walls, or mixed) are the only data captured at the lead stage. Engineering specifications, production requirements, and order details move to the entities where they belong: the Opportunity and Order Fulfillment records. The Order Fulfillment entity tracks the production lifecycle of each won deal. Each fulfillment record is linked to an Opportunity and carries its own set of production stages, dates, owners, and status fields. Sales reps see a live production status on the opportunity record without accessing the shop floor system. Operations managers see a consolidated production pipeline across all active orders, with the ability to filter by stage, project type, and expected dispatch date. ⓘWhy extend the BPF instead of building a separate production tracker? A separate production module would have created two disconnected systems: one for sales, one for operations. By extending the BPF into Order Fulfillment, the entire lifecycle from first inquiry to delivery lives in a single process flow. The sales team does not need to switch systems. Reporting joins lead source, deal value, and production cycle time in one data model. And the BPF enforces stage gates that prevent an order from advancing to fabrication before engineering sign-off is complete. 04Technical Approach Entity Model The framework uses three primary entities in the BPF and two supporting reference tables. Entity Type Purpose Key Fields Lead Standard First contact: who the lead is and where they came from Contact name, company/architect firm, referral source, project type (Residential/Commercial), initial product interest (Windows/Doors/Curtain Walls/Mixed) Opportunity Standard Deal record: commercial qualification and proposal Estimated project value, product mix, unit count, expected order date, project timeline, sales stage Order Fulfillment Custom Production lifecycle: tracks each won order through manufacturing to delivery Engineering review status, fabrication start/end dates, finishing status, quality inspection outcome, dispatch date, delivery confirmation, Opportunity lookup Entity model for the multi-entity BPF framework The Order Fulfillment entity carries a lookup to the Opportunity. When an opportunity moves to Won, the BPF transitions to a new Order Fulfillment record. This record becomes the single source of truth for production status. The Opportunity record retains the commercial data (deal value, product mix, client details), while the Order Fulfillment record tracks manufacturing progress. 💡Keep each entity focused on one job … Continue reading How a U.S.-Based Steel Windows and Doors Manufacturer Built a Multi-Entity Business Process Flow in Dynamics 365 Sales →

How a Leading Professional Services Organization Eliminated Invoice Posting Blind Spots Between D365 Project Operations and Finance Using Custom Business Events Summary In a D365 Project Operations and Finance integrated setup, invoices are created in Project Operations but posted in Finance. Once the accountant posts the invoice in F&O, the project team in PO has no real-time signal that it happened — so they wait for an email, check a report the next day, or chase finance with “has my invoice been posted yet?” CloudFronts solved this with a custom business event in D365 Finance that fires the moment a project invoice proposal is posted. The event triggers an Azure Logic App, which sends the posted status straight back into D365 Project Operations. The project manager sees the update instantly — no emails, no waiting, no manual follow-up. This article walks through the end-to-end flow, the custom business event, the exact JSON payload, what the Logic App receives, and the related scenarios where the same pattern applies. Table of Contents 01 About the Scenario 02 Why This Matters 03 Why We’re Writing This 04 How D365 F&O Business Events Work 05 The Problem 06 The Fix 07 The Payload 08 The Logic App 09 Other Scenarios 10 Conclusion 11 Your Next Step 01 — Context About the Scenario A Familiar PO–FO Integration Gap In a D365 Project Operations and Finance integrated environment, the billing lifecycle is split across two systems. Project invoices originate as invoice proposals in Project Operations, then get reviewed and posted by the accountant in D365 Finance. The posting creates the general ledger entry, records tax and subledger postings, and finalizes the financial transaction. For growing organizations running this dual-system setup, real-time visibility is non-negotiable. As invoice volume climbs and project teams depend on accurate billing status to communicate with clients and forecast cash flow, even a small gap in how posting status is communicated can quietly erode trust between delivery and finance. One of the most common and most overlooked gaps in a PO–FO integration is surprisingly simple: the project team never finds out, in real time, that their invoice was posted in Finance. Have you ever posted a project invoice in F&O, then spent the rest of the day answering “has invoice AC-000051 been posted yet?” messages from project managers? If you’re nodding, this article is for you. Consider this: in most PO–FO implementations, the only way the project team learns an invoice is posted is through a manual email from finance, a next-day report, or a direct follow-up. Multiply that across dozens of invoices every month, and the overhead — and the risk of a missed update — adds up fast. The cumulative effect on billing visibility, client communication, and finance–delivery trust is significant. By the end of this article, you will understand exactly why this happens, how D365 F&O’s Business Events framework can close the gap, and the single pattern that eliminates the problem entirely. 02 — Impact Why This Matters No Real-Time Posting Visibility Creates Real Business Risk When the project team in PO has no real-time way of knowing that their invoice has been financially posted in Finance, it isn’t just an inconvenience. It leads to delayed client communication that chips away at trust, manual follow-ups that clog up both delivery and finance, and worst of all, project managers who stop trusting the system and start maintaining their own spreadsheets of “what’s been posted.” Once that happens, the entire value of a unified PO–FO integration is gone. Dynamics 365 Finance — Custom Business Event Dynamics 365 Finance — Project Invoice Proposal Posting 03 — Our Perspective Why We’re Writing This A Pattern We See Across D365 PO–FO Integrations At CloudFronts, we’ve implemented and supported Dynamics 365 Project Operations and Finance integrations across professional services, engineering, and project-based organizations. This specific issue — the project team being left blind to invoice posting in Finance — has come up in nearly every engagement where invoices originate in PO and are posted in F&O. We’ve seen the pattern, diagnosed the root cause repeatedly, and built the automation to prevent it. This article distils that experience into something actionable. 04 — The Flow How D365 F&O Business Events Work The Flow: F&O → Business Event → Logic App → Project Operations The integration is straightforward. Four things happen in sequence: Step What Happens Detail 1 Invoice is Posted in D365 Finance The project invoice proposal — which originates from D365 Project Operations — is reviewed and posted by the accountant in D365 Finance. The posting creates the GL entry, records tax and subledger postings, and finalizes the financial transaction. 2 Custom Business Event Fires The moment the posting completes, our custom business event (CFProjectInvoiceProposalUpdatedBusinessEvent) fires automatically. It sends a lightweight JSON payload containing the ProposalId, ProjectContractId, Currency, Company, and event timestamp to the configured endpoint. 3 Logic App Receives and Processes The Azure Logic App (FO-PO-Integration-Invoice-Confirmation) is triggered instantly. It receives the payload, extracts the relevant fields, and executes the configured workflow — updating the invoice status in Project Operations and notifying stakeholders. 4 Status Updated in D365 PO The Logic App calls back into D365 Project Operations and updates the invoice record with the “Posted” status. The project manager sees this immediately in PO without any manual intervention. The entire sequence — from the accountant clicking Post in Finance to the status appearing in Project Operations — takes less than a second. 05 — The Gap The Problem The Project Team Is Left in the Dark Here’s how the issue plays out. A project invoice proposal is created and sent from D365 Project Operations to Finance for posting. The accountant reviews and posts it in D365 F&O. The financial transaction is complete — GL, tax, and subledger all finalized. But in Project Operations, the invoice record still looks unposted. The project manager has no automated signal that the posting happened. Root Cause There is no event-driven bridge between the two systems for this … Continue reading How to Eliminate Invoice Posting Blind Spots Between D365 Project Operations and Finance Using Custom Business Events →

Summary We built an AI-powered meeting briefing solution on top of Dynamics 365 CRM that assembles a complete, structured briefing – customer details, meeting history, email insights, professional profile, and open action items – with a single button click, delivered in under 30 seconds. Powered by Azure Functions and Azure OpenAI GPT-4.1, the solution sits inside the existing CRM workflow with zero change to the tools the team already uses. Built for private equity and asset management firms where missing context isn’t just inefficient – it’s a credibility cost. Table of Contents 01Summary 02Customer 03Challenge 04Solution 05Architecture 06Briefing 07Intelligence 08Enterprise 09Benefits 10Why PE About the Customer Customer Overview Our customer is a US based private equity investment firm focused on partnering with and growing businesses over the long term. With a portfolio of investments and a strong emphasis on operational excellence and value creation, the firm required an AI-powered solution to streamline client preparation, consolidate information from multiple sources, and enable investment professionals to make more informed decisions before meetings. The Challenge Data Exists. Context Doesn’t. Modern CRM platforms are excellent at storing information. On their own, they’re not built to assemble it into something a person can use in the next fifteen minutes. It’s 8:45 AM. Fifteen minutes before an important client call, a relationship manager has four tabs open – CRM, Outlook, LinkedIn, and a folder of old meeting notes – trying to reconstruct the relationship before the call starts. Nothing here is missing. It’s just scattered. And the fifteen minutes meant for preparing get spent finding what to prepare instead. As firms manage more relationships – more portfolio companies, more LPs, more prospects – this problem doesn’t stay the same size. It grows with every account added to the book. A typical prep routine still looks like this: 01Reviewing CRM records for account history 02Reading through recent email threads 03Searching old meeting notes for what was actually discussed 04Looking up a contact’s current role and background 05Trying to remember what was promised – and what’s still open Each source holds something useful on its own. None of them, alone, tells the whole story – and stitching them together by hand is what actually eats the morning. The result is inconsistent prep, lost productivity, and context that depends entirely on who happens to be covering the account that day. Today 01Manually researching each contact across CRM, LinkedIn, and email 02Meeting notes scattered across CRM records, shared drives, and inboxes 03Generic AI summaries that miss relationship context 04Key background often missed before the meeting even starts With AI-Powered Briefings 01A structured briefing generated in the team’s own template, on demand 02Contact details, professional background, and CRM data pulled automatically 03Past meetings and email threads summarized with real context 04The team arrives prepared in seconds, not hours Turning CRM Data Into Meeting Intelligence One Click. A Complete Briefing. We built an AI-powered meeting briefing solution that sits directly on top of Dynamics 365 CRM — adding a single button to the record teams already work from, with no change to the existing workflow underneath it. 01 Click The relationship manager clicks “AI Meeting Insights” on the contact or prospect record – the trigger for everything that follows. 02 Gather Azure Functions orchestrates the retrieval: CRM history, grouped email threads, past meeting notes, and the contact’s public professional profile. 03 Analyze Azure OpenAI GPT-4.1 reads everything chronologically, identifying what was discussed, what’s outstanding, and the tone of recent exchanges. 04 Deliver A formatted briefing, built in the team’s existing template, lands in minutes — a progress indicator keeps the user informed while it runs. In practice, the full sequence — from button click to finished document – runs in under 30 seconds. Solution Architecture How It Works — End to End From a single button click in Dynamics 365 to a formatted briefing delivered in under 30 seconds. Inside the Document What’s Actually in the Briefing Instead of a generic summary, the output is built around the fields teams actually need before walking into a conversation. 01 Customer & Contact Details Pulled directly from the CRM record — no re-typing, no re-checking. 02 Previous Meeting Summary Condensed from historical notes into a concise interactions record. 03 Recent Email Insights Key topics and sentiment from the latest correspondence. 04 Business Overview A short, current description of the company and its context. 05 Meeting Attendees Who’s expected in the room, drawn from calendar and CRM data. 06 Professional Profile Reference Publicly available background on the contact, added automatically. The Intelligence Behind the Briefing Structured, Not Just Summarized What makes this different isn’t simply the use of Generative AI — it’s the structure behind it. Rather than summarizing documents in isolation, the model reads a customer’s engagement history chronologically: completed and upcoming meetings, attendees, recent conversations, sentiment, and open action items, resolved into one coherent picture. Every section of the briefing is mapped back to a defined source. Customer details come from CRM. Meeting summaries come from meeting records. Communication insights come from email. Profile information is referenced separately and flagged as such. That traceability is what keeps the output contextual and consistent, rather than a plausible-sounding but generic AI summary. It’s also reviewed, not just trusted. Fields the model is less confident about are flagged for a human to check, and the team approves AI-generated sections before a briefing goes out. The goal isn’t to remove judgment from the process — it’s to remove the search that used to come before it. Built for the Enterprise Enterprise-Ready by Design This runs inside the systems and controls teams already trust — not alongside them. 01 Role-Based Access Visibility follows existing Dynamics 365 security roles — no new permission model to manage. 02 Data Protection Data is encrypted in transit, credentials sit in a secure Azure vault, and only the fields needed reach the model. 03 Graceful Failure Handling A failed run is flagged clearly, prior briefing data stays intact, and the user can … Continue reading How AI-Powered Meeting Briefings Are Transforming Client Preparation for a Boston based Private Equity Firm →

Summary A leading North American commercial vehicle manufacturer was experiencing incorrect purchase prices on Purchase Orders in Dynamics 365 Finance & Operations. The root cause: overlapping trade agreement records in the PriceDiscTable that were never closed when new prices were introduced. CloudFronts diagnosed the issue and implemented a single rule – close the active trade agreement record before creating a new one – enforced through automation on both inbound integrations and manual entry workflows. The result: deterministic price resolution, clean audit trails, and procurement teams that trust the system again. Table of Contents 01Summary 02Customer 03Why it matters 04Our perspective 05Price logic 06Problem 07Fix 08Example 09Automation 10Edge cases 11Conclusion About the Customer Customer Overview 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. For growing businesses running Dynamics 365 Finance & Operations, procurement accuracy is non-negotiable. As order volumes climb and vendor pricing evolves, even a small gap in how purchase prices are managed can quietly erode margins, trigger invoice disputes, and undermine trust in the system. One of the most common and most overlooked causes of pricing errors on Purchase Orders is something surprisingly simple: outdated trade agreement records that were never closed. Have you ever updated a vendor’s price in D365 FO, only to find that Purchase Orders raised the next week still show the old price? If you’re nodding, this article is for you. Consider this: organisations that leave overlapping trade agreement records unmanaged often find hundreds, sometimes thousands, of duplicate active price records for the same Item x Vendor combination in their PriceDiscTable. Each one is a potential pricing conflict waiting to surface on a Purchase Order. The cumulative effect on procurement accuracy, AP reconciliation time, and vendor relationships is significant. By the end of this article, you will understand exactly why this happens, how D365 FO’s price engine actually resolves trade agreements, and the single rule that eliminates the problem entirely. Why This Matters Incorrect Purchase Prices Create Real Business Risk Incorrect purchase prices on POs are not just a data nuisance. They lead to overpayments that chip away at margins, invoice mismatches that clog up Accounts Payable, and worst of all, procurement teams who stop trusting the system and start overriding prices manually on every order. Once that happens, the entire value of centralized pricing governance is gone. Why We’re Writing This A Pattern We See Across D365 F&O Implementations At CloudFronts, we’ve implemented and supported Dynamics 365 F&O procurement modules across manufacturing, distribution, and services organisations. This specific issue, stale trade agreements causing wrong PO prices, has come up in nearly every engagement where vendor prices are managed through the Trade Agreement Journal. We’ve seen the pattern, diagnosed the root cause repeatedly, and built the automation to prevent it. This article distils that experience into something actionable. How D365 F&O Resolves Purchase Prices The Price Comes From Trade Agreements, Not the Item Master The price on a Purchase Order line does not come from the item master. It is resolved from a Trade Agreement, a dated record that says: “For this item, from this vendor, in this currency, starting from this date, the unit price is X.” These records are created through the Trade Agreement Journal, posted, and stored in the PriceDiscTable. When a PO line is created, the price search engine finds every posted record whose date window, from From Date to To Date, covers the PO date. It then filters by matching keys such as item, vendor, currency, site, warehouse, and quantity break, and selects the price. Critically, the system does not prefer the most recently posted record. It looks at date windows. If two records both cover today, the engine has two valid candidates. Its tie-breaking behaviour is not something you should rely on for pricing accuracy. The Problem Overlapping Records Create Pricing Conflicts Here’s how the issue plays out. A vendor price is loaded into D365 FO, either from a legacy system integration or manually by a buyer. The record is created with an open-ended To Date, the sentinel 1900-01-01 or a far-future date, meaning it never expires. Months later, a new negotiated price arrives. A fresh trade agreement line is added for the same Item x Vendor. But nobody closes the original record. Both records now have date windows that include today. The price engine finds two matches, and sometimes the older, stale price wins. Root Cause There is no closure step. Every new price is layered on top of the old one instead of replacing it in time. The Fix Close Before You Create The rule is simple: whenever a new price record is created for an Item x Vendor combination, the currently active record must have its To Date set to Today – 1. The new record’s From Date is set to Today. This produces two non-overlapping windows: old price valid up to yesterday, new price effective from today. Why Today – 1? If both dates include the same day, the engine still finds two candidates. One day’s difference makes the price resolution deterministic. Worked Example One Item, One Vendor, One Clean Price Timeline Item purchased from Vendor A, USD, quantity break of 1: Event Action From Date To Date Price 22 June – Initial load Create Record A 22 June 2026 Open-ended $7.00 24 June – New price Close Record A 22 June 2026 23 June 2026 $7.00 24 June – New price Create Record B 24 June 2026 Open-ended $6.50 After posting, any PO dated 24 June or later picks $6.50. Historical POs on or before 22 June still resolve to $7.00. Clean, unambiguous, audit safe. Where to Enforce This Rule Automation Should Handle the Closure Inbound Integration If prices flow from a legacy system via OData, build a custom API endpoint in D365 FO that … Continue reading How a Leading North American Commercial Vehicle Manufacturer Prevented Incorrect Purchase Prices on Purchase Orders Using Dynamics 365 Finance & Operations →

What happens when a global manufacturing giant needs to modernize its operations without grinding critical business processes to a halt? The answer is not a rip-and-replace approach – it is a carefully engineered integration strategy that lets modern and legacy systems co-exist, communicate, and complement each other. Are you planning an ERP upgrade but worried about what happens to the legacy systems your operations depend on? If so, this is for you. One of North America’s leading commercial vehicle manufacturers faced exactly this dilemma. With decades of investment in legacy financial and warehouse management systems, a hard cutover to a new ERP was not an option. Yet the need for a modern, scalable platform was undeniable. Their solution? Introduce Microsoft Dynamics 365 Finance & Operations (D365 F&O) as the new operational backbone – while keeping their legacy systems in play for financial control – and build robust, bi-directional integrations to bridge both worlds. At CloudFronts, we had the privilege of architecting and implementing those integrations. This blog walks you through three core data flows: Spot Purchase Orders, Advance Shipment Notices (ASN), and Goods Receipt Notes (GRN) – and what it really takes to make a modern ERP talk to a legacy system without missing a beat. Why Replace When You Can Integrate? Legacy systems in large manufacturers are not just old software. They carry years of financial logic, vendor relationships, and compliance configurations that are too risky to discard overnight. Replacing them introduces enormous operational and compliance risk. Doing nothing, however, is not an option either. The approach our client took – and one we increasingly recommend for manufacturers, distributors, and large enterprises – is a co-existence model: This means the business gets the agility of a modern ERP on day one, without putting financial operations at risk. The three integrations do the heavy lifting. Architecture at a Glance Before diving into each integration, it helps to understand the overall data flow pattern and the Azure services involved: Component Role D365 F&O System of record for purchasing and receiving operations Legacy System Retains financial control, inventory management authority Azure Logic Apps Parent-child middleware: orchestrates, transforms, and routes data Azure Blob Storage Checkpoint management for reliable incremental processing Azure Table Storage Full execution logs for traceability, audit, and failure replay The three integrations work in concert: Integration 1: Spot Purchase Orders — D365 F&O to Legacy Business Problem A Spot Purchase Order is an ad-hoc purchase order raised outside of long-term contracts — often for urgent material procurement. Spot POs are created and managed in D365 F&O by procurement teams. However, the legacy system is the system of financial record, meaning every Spot PO created in D365 must be reflected in the legacy system for financial commitment tracking and vendor payment processing. Without integration, this would require manual re-entry – a process prone to error, delay, and duplication. How the Integration Works Parent Logic App – Spot PO Orchestrator The primary Logic App runs on a scheduled recurrence and uses a checkpoint mechanism stored in Azure Blob Storage to fetch only incremental changes – purchase orders created or modified since the last successful run. This ensures efficiency and prevents reprocessing of already-handled records. The workflow determines the operation type required for each PO: For each scenario, the Logic App fetches enriched data from multiple D365 F&O OData entities and constructs a structured JSON payload tailored for the legacy system’s API. ⚙ Tech Note: OData Entities Used PurchaseOrderHeaders, PurchaseOrderLinesV2, PurchaseLineDataEntities, WHSPurchLines, StatusCustomDatas Child Logic App – SendRequest (Reusable) Rather than embedding API communication logic directly in the orchestrator, we separated it into a reusable child Logic App. This child app receives the constructed payload, retrieves an OAuth 2.0 Bearer token, and executes the HTTP POST call to the legacy system’s API endpoint. This modular design pays dividends during maintenance: any change to authentication logic or API communication is made once in the child app and automatically applies to all parent integrations. Failed Record Handler Every enterprise integration needs robust failure recovery. When an API call fails: Sample Payload – Spot PO Create Sample JSON Payload: {   “userId”: “JSMITH”,   “order”: “456789”,   // Last 6 digits of D365 PO number   “vendor”: “VEND001”,   “receiptLoc”: “SITE01”,   “vendorOvrdCd”: “14”,   “lineItems”: [{     “orderLine”: “001”,     “item”: “ITEM001”,     “openQty”: 10,     “deliveryDate”: “061526”,  // MMddyy format for legacy compatibility     “comment”: “MPSSYS order – JSMITH” }] } } ✓ Business Impact: Zero manual re-entry of purchase orders between systems. Every Spot PO created or changed in D365 F&O is automatically reflected in the legacy system within minutes. Integration 2: Advance Shipment Notices — Legacy to D365 F&O Business Problem An Advance Shipment Notice (ASN) is a notification sent by the legacy WMS to the receiving system, informing it of an incoming shipment before it physically arrives. D365 F&O needs to receive ASNs to create Inbound Load Headers and Load Lines – enabling warehouse teams to prepare for receiving. Without this integration, receiving teams in D365 would be blind to incoming shipments until trucks arrived at the dock – eliminating any opportunity for advance dock scheduling, labor planning, or inventory pre-positioning. The Hybrid Integration Approach This integration presented an interesting technical challenge: the standard D365 F&O Inbound ASN V5 API supports a well-defined XML format, but the business required additional fields beyond what the standard API supports. The solution was a two-step Hybrid ASN Integration approach: ⚙ Tech Note: API Endpoint Pattern Insert:  POST {{BASE_URL}}/api/connector/enqueue/{{ACTIVITY_ID}}?entity=Inbound ASN V5 Enrich:  PATCH on InboundLoadHeaders and WHSASNWorkData Smart Insert vs. Update Determination To handle scenarios where an ASN might be re-sent for corrections or resynchronization, the integration includes a check before processing: This idempotent design prevents duplicate inbound loads from being created when the legacy system re-sends an ASN. One nuance worth noting: in D365’s standard ASN structure, the LoadId, ShipmentId, and LicensePlateNumber must carry the same value. The legacy system’s outbound ASN payload is configured to honour this requirement – ensuring clean data entry … Continue reading How a Top North American Commercial Vehicle Manufacturer Connected D365 F&O with Legacy Systems Without Disrupting Operations →

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

Are you struggling to build secure, low-latency APIs on Azure without spinning up expensive always-on infrastructure? Traditional serverless models like the Azure Functions Consumption Plan are great for scaling, but they fall short when it comes to VNET integration and consistent low latency. Enterprises often need to connect serverless APIs to internal databases or secure networks — and until recently, that meant upgrading to Premium Plans or sacrificing the cost benefits of serverless. That’s where the Azure Functions Flex Consumption Plan changes the game. It brings together the elasticity of serverless, the security of VNETs, and latency performance that matches dedicated infrastructure — all while keeping your costs optimized. What is Azure Functions Flex Consumption? Azure Functions Flex Consumption is the newest hosting plan designed to power enterprise-grade serverless applications. It offers more control and flexibility without giving up the pay-per-use efficiency of the traditional Consumption Plan. Key capabilities include: Why This Matters APIs are the backbone of every digital product. In industries like finance, retail, and healthcare, response times and data security are mission critical. Flex Consumption ensures your serverless APIs are always ready, fast, and safely contained within your private network — ideal for internal or hybrid architectures. VNET Integration: Security Without Complexity Security has always been the biggest limitation of traditional serverless plans. With Flex Consumption, Azure Functions can now run inside your Virtual Network (VNET). This allows your Functions to: In short: You can now build fully private, VNET-secure APIs without maintaining dedicated infrastructure. Building a VNET-Secure Serverless API: Step-by-Step Step 1: Create a Function App in Flex Consumption Plan Step 2: Configure VNET Integration Step 3: Deploy Your API CodeUse Azure DevOps, GitHub Actions, or VS Code to deploy your function app just like any other Azure Function. Step 4: Secure Your API How It Compares to Other Hosting Plans Feature Consumption Premium Flex Consumption Auto Scale to Zero ✅ ❌ ✅ VNET Integration ❌ ✅ ✅ Cold Start Optimized ⚠️ ✅ ✅ Cost Efficiency ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐ Enterprise Security ❌ ✅ ✅ Flex Consumption truly combines the best of both worlds – the agility of serverless and the power of enterprise networking. Real-World Use Case Example A large retail enterprise needed to modernize its internal inventory API system.They were running on Premium Functions Plan for VNET access but were overpaying due to idle resource costs. After migrating to Flex Consumption, they achieved: This allowed them to maintain compliance, improve responsiveness, and simplify their architecture — all with minimal migration effort. To conclude, in today’s API-driven world, you shouldn’t have to choose between speed, cost, and security. With Azure Functions Flex Consumption, you can finally deploy VNET-secure, low-latency serverless APIs that scale seamlessly and stay protected inside your private network. Next Step:Start by migrating one of your internal APIs to the Flex Consumption Plan. Test the latency, monitor costs, and see the difference in performance. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudFronts.com

Building low-latency, VNET-secure APIs with Azure Functions Flex Consumption is only the beginning.The next step toward modernization is setting up a DevOps release pipeline that automatically deploys your Function Apps-even across multiple regions – using Azure CLI. In this blog, we’ll explore how to implement a CI/CD pipeline using Azure DevOps and Azure CLI to deploy Azure Functions (Flex Consumption), handle cross-platform deployment scenarios, and ensure global availability. Step-by-Step Guide: Azure DevOps Pipeline for Azure Functions Flex Consumption Step 1: Prerequisites You’ll need: Step 2: Provision Function Infrastructure Using Azure CLI Step 3: Configure Azure DevOps Release Pipeline Important Note: Windows vs Linux in Flex Consumption While creating your pipeline, you might notice a critical difference: The Azure Functions Flex Consumption plan only supports Linux environments. If your existing Azure Function was originally created on a Windows-based plan, you cannot use the standard “Azure Function App Deploy” DevOps task, as it assumes Windows compatibility and won’t deploy successfully to Linux-based Flex Consumption. To overcome this, you must use Azure CLI commands (config-zip deployment) — exactly as shown above — to manually upload and deploy your packaged function code. This method works regardless of the OS runtime and ensures smooth deployment to Flex Consumption Functions without compatibility issues. Tip: Before migration, confirm that your Function’s runtime stack supports Linux. Most modern stacks like .NET 6+, Node.js, and Python run natively on Linux in Flex Consumption. Step 4: Secure Configurations and Secrets Use Azure Key Vault integration to safely inject configuration values: Step 5: Enable VNET Integration If your Function App accesses internal resources, enable VNET integration: Step 6: Multi-Region Deployment for High Availability For global coverage, you can deploy your Function Apps to multiple regions using Azure CLI: Dynamic Version (Recommended): This ensures consistent global rollouts across regions. Step 7: Rollback Strategy If deployment fails in a specific region, your pipeline can automatically roll back: Best Practices a. Use YAML pipelines for version-controlled CI/CDb. Use Azure CLI for Flex Consumption deployments (Linux runtime only)c. Add manual approvals for productiond. Monitor rollouts via Azure Monitore. Keep deployment scripts modular and parameterized To conclude, automating deployments for Azure Functions Flex Consumption using Azure DevOps and Azure CLI gives you: If your current Azure Function runs on Windows, remember — Flex Consumption supports only Linux-based plans, so CLI-based deployments are the way forward. Next Step:Start with one Function App pipeline, validate it in a Linux Flex environment, and expand globally. For expert support in automating Azure serverless solutions, connect with CloudFronts — your trusted Azure integration partner. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In today’s automated world, businesses depend on secure, streamlined connections between systems to improve efficiency. Power Automate, a robust tool for building workflows between various services, allows seamless integration of applications and APIs. However, when working with third-party services, ensuring that data access is secure and well-managed is critical. This is where OAuth 2.0, a secure and standard protocol for authorization, comes into play. Are you struggling to configure OAuth 2.0 authentication in your Power Automate flows? If you are considering automating workflows that interact with secured APIs, this article is for you. I will walk you through configuring OAuth 2.0 in Power Automate, so you can ensure the safety of your automation while keeping your services accessible. Why OAuth 2.0? OAuth 2.0 is the industry-standard protocol for authorization. It allows users to grant third-party applications limited access to their resources without exposing passwords. By using OAuth 2.0 in Power Automate, you ensure that the services and APIs you connect to are secure, and that tokens are used to access data on behalf of the user. How OAuth 2.0 Enhances Security OAuth 2.0 significantly improves security by eliminating the need to share sensitive credentials. Instead, access is granted through tokens, which are time-limited and easily revocable. OAuth 2.0 is widely used by many companies, including Microsoft, Google, and Salesforce, to integrate applications securely. Step-by-Step Guide to Configuring OAuth 2.0 in Power Automate 1. Set Up OAuth 2.0 Credentials Before configuring OAuth 2.0 in Power Automate, you need to set up OAuth 2.0 credentials in the platform you’re working with. For example, if you’re using Microsoft Graph API or any third-party service, follow these steps: 2. Initialize OAuth 2.0 Variables in Power Automate Now that you have your client ID and client secret, it’s time to configure them in Power Automate. Set up the variables: 3. Configuring the OAuth 2.0 Connection in Power Automate With the client credentials set, it’s time to establish the connection to the service using OAuth 2.0. 4. Use OAuth Token to Access Secure Data Now that you have the OAuth token, you can use it to authenticate your requests to third-party APIs. 5. Best Practices for OAuth 2.0 in Power Automate To conclude, OAuth 2.0 authentication provides a secure and effective way to authorize third-party applications in Power Automate. By following the steps outlined in this guide, you can set up OAuth 2.0 authentication, ensure data security, and integrate third-party services into your automation workflows with ease. If you’re ready to secure your Power Automate workflows with OAuth 2.0, follow the steps outlined in this post and start integrating APIs in a secure manner today. For more tips and detailed guides, check out our other blog posts on Power Automate and API integration. Need help with the OAuth 2.0 integration? Feel free to reach out for assistance! We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Struggling to Monitor Your Logic App Workflows End-to-End? Azure Logic Apps are a powerful tool for automating business workflows across services. But as these workflows grow in size and complexity, so do the challenges in tracking, debugging, and optimizing them. The built-in monitoring options, while helpful often don’t provide full visibility. This leaves teams scrambling to understand failures, bottlenecks, or performance issues. Here’s the good news: OpenTelemetry can change that. In this post, you’ll learn how to gain complete observability into your Logic Apps workflows using OpenTelemetry, the industry-standard framework for telemetry data. Why Observability Matters in Azure Logic Apps Logic Apps connect multiple services , APIs, databases, emails, on-prem systems, and more. But as you stitch these workflows together, it becomes harder to: While Azure provides diagnostics via Monitor and Application Insights, they often produce fragmented data. These tools lack native support for distributed tracing, which is essential when workflows span many components. That’s where OpenTelemetry helps. With it, you can gather: Together, these three “pillars of observability” give you actionable insights into your Logic App’s behavior. What is OpenTelemetry? OpenTelemetry is an open-source standard for collecting and exporting telemetry data. It supports multiple platforms, Azure, AWS, GCP and can export data to tools like Application Insights, Jaeger, or Prometheus. With OpenTelemetry, you can: It ensures a consistent observability strategy across your cloud-native systems — including Logic Apps. How to Integrate OpenTelemetry with Azure Logic Apps Azure Logic Apps don’t yet support OpenTelemetry out of the box. But with a smart setup, you can still plug them into an OpenTelemetry pipeline. 🛠️ Step-by-Step Guide: Real Example: Order Processing with Observability Imagine this: Without OpenTelemetry: With OpenTelemetry: This means faster resolution, less guesswork, and a better customer experience. ✅ Use correlation IDs across services✅ Add custom dimensions to enrich telemetry✅ Configure sampling to control trace volume✅ Monitor latency thresholds for each Logic App step✅ Log business-critical metadata (e.g., Order ID, region) Start Small, See Big Results Observability is no longer optional. It’s a must-have for teams building scalable, resilient workflows. Here’s your action plan: