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

Summary A global life-sciences and laboratory equipment supplier sends purchase orders to our customer (BÜCHI’s customer-centric vision accelerates innovation using Azure Integration Services | Microsoft) as machine-generated cXML OrderRequest.xml documents. The customer runs Infor LN, which expects a SalesOrder BOD delivered through the Infor ION I/O Box. Between the two sat a translation problem that was being solved by hand. Every order arriving from the trading partner had to be read, interpreted and re-keyed into Infor LN by the order desk. That worked at low volume. It did not scale, it delayed order confirmation by hours, and it introduced transcription errors on the fields that matter most — quantities, delivery dates and ship-to addresses. We closed that gap with Azure Integration Services: API Management as the secure front door, Blob Storage as the immutable archive, Service Bus for asynchronous decoupling and retries, Azure Functions in C# for the cXML-to-BOD translation, and a write into the Infor ION I/O Box SQL database from which ION creates the sales order in LN. Key Vault and App Configuration hold secrets and environment-specific values; Application Insights makes every transaction traceable end to end. The result is a straight-through process: Partner posts cXML → Archive → Queue → Transform to BOD → I/O Box → Infor ION → Sales Order in LN. This article covers how the interface was designed, how the mapping and its business rules were kept maintainable, how failures are handled and replayed, and the guardrails that keep an asynchronous EDI interface trustworthy in production. Table of Contents From Manual Order Entry to Automated Order Intake The Business Challenge Solution Overview Receiving the Purchase Order: Azure API Management Decoupling the Interface: Azure Service Bus Translating cXML into the Infor Process.SalesOrder BOD The Business Rules Hidden Inside the Mapping Writing to the Infor ION I/O Box Handling Exceptions, Retries and Replay Technical Architecture Monitoring with Application Insights Designing the Integration Around Business Events Business Impact Design Constraints and Guardrails Final Thoughts This Blog Explains Why manual order entry from EDI purchase orders stops scaling, and what it costs. How a partner cXML OrderRequest is received, archived and queued on Azure. How the cXML document is translated into an Infor Process.SalesOrder BOD. How conditional business rules — partner cross-references, note construction, ship-date fallbacks — are kept out of hard-coded logic. How multi-line orders are looped into SalesOrderPosition blocks. How the BOD is handed to Infor LN through the ION I/O Box. How failures are retried, dead-lettered and replayed without asking the partner to resend. How a single transaction ID makes the whole interface searchable in Application Insights. From Manual Order Entry to Automated Order Intake For manufacturers that sell through large, process-driven customers, the order does not arrive as a phone call or an email attachment. It arrives as a machine-generated EDI document, posted to an endpoint at any hour of the day, in a format defined entirely by the buyer. Our customer — a European division of a global life-sciences and laboratory equipment supplier — runs Infor LN as its ERP. Their key trading partner sends purchase orders as cXML OrderRequest.xml documents. Infor LN, on the other side, expects a Process.SalesOrder BOD delivered through the Infor ION I/O Box. Both systems were working exactly as designed. The problem lived in the space between them, and that space was being crossed by a person with a keyboard. A purchase order that arrives electronically and is then typed in by hand is not an integrated process. It is a manual process with an electronic first step. The objective of the project was therefore narrow and concrete: when the trading partner posts an order, a sales order should appear in Infor LN — correctly mapped, without human intervention, and with enough visibility that the support team can prove it happened. The Business Challenge On the surface this looks like a file conversion. In practice, five things made it anything but. 1. Two Schemas That Share Almost No Vocabulary cXML is a flat, attribute-heavy commerce format. The Infor BOD is a deeply nested OAGIS structure with an ApplicationArea envelope, a DataArea payload and a UserArea carrying LN-specific properties. Almost every field required transformation rather than a straight copy. 2. Business Logic Hidden Inside the Mapping The partner’s identity codes had to be cross-referenced to Infor LN business partner IDs — with different values in Test and Production. Header comments needed a hardcoded Remark: prefix. Goods marks, customer references and order numbers had to be concatenated into a single footer note, skipping the values that did not arrive so no blank lines were left behind. 3. A Ship Date With a Rule of Its Own Requested ship date could not simply be copied. If the line carries a date, use it. If it is missing, or in the past, use the current date. If the order has multiple lines with different dates, take the earliest. A rule that reads as one sentence in a specification becomes a decision tree in code. 4. Line-Level Repetition A single order can contain many ItemOut elements, each of which becomes a SalesOrderPosition block in the BOD, carrying its own item ID, quantity, required delivery date and note. 5. No Second Chances, and No Visibility The exchange is asynchronous and real-time. If a message failed silently, the first sign of trouble would be the customer asking why their order had not shipped. Operations needed to answer “what happened to this order?” without raising a support ticket. Manual re-keying was the fallback, and it carried exactly the costs you would expect: order entry delays measured in hours, transcription errors on quantities and delivery dates, and a team doing work that added no value. Solution Overview We built the interface on Azure Integration Services as a set of small, independently deployable components rather than one monolithic job. The solution uses: Azure API Management Azure Blob Storage Azure Service Bus Azure Functions (C#) Infor ION I/O Box (SQL) Azure Key Vault and App Configuration Application … Continue reading From Trading Partner cXML to Infor LN Sales Order: How a European Life-Sciences Manufacturer Automated EDI Order Intake with Azure Integration Services →

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 Clean ERP data sitting in a data lake doesn’t answer the question every operations leader eventually asks: where exactly is our process breaking down? We built an automated pipeline that connects a client-facing web portal, Azure Table Storage, and Azure Databricks to a leading process mining platform, turning validated ERP data into a living view of how work actually flows. The pipeline is fully status-driven: every record is tracked from submission through processing to completion, with no manual exports or spreadsheet hand-offs. Purchase order data is modeled through a medallion architecture and delivered to the process mining platform, where AI-driven analysis automatically surfaces bottlenecks and deviations from the expected process. Business impact: process owners moved from static, after-the-fact reporting to a near real-time, evidence-based view of process performance. Table of Contents 01  About the Customer 05  The Six-Step Pipeline 02  The Challenge 06  Architecture Overview 03  The Solution 07  Business Impact 04  AI-Driven Process Mining 08  FAQs About the Customer Customer Spotlight A Leading Digital Transformation Partner — Europe Our customer is a leading enterprise headquartered in Europe, operating across diverse manufacturing and supply chain divisions. Having already standardized their ERP data through a medallion architecture on Databricks, leadership wanted to go a step further: not only manage ERP data at scale, but also connect it seamlessly into process mining tools to uncover how core processes truly perform in practice. The focus was on gaining operational clarity into workflows such as purchase order management, invoice handling, and procurement cycles. The Challenge Standardized, clean data answers “what happened.” It rarely answers “why is this taking so long” or “where exactly is this process breaking down.” The business kept running into the same limitations: 1Why do purchase orders take longer to close in some regions than others? 2Which approval step is quietly adding the most delay to the process? 3How do we get validated ERP data into a process analysis tool without manual exports every time? 4How do we know, at any point in time, what has been processed, what’s pending, and what failed? 5Can this insight be generated automatically, instead of requiring a manual investigation every quarter? The Solution We extended the existing Databricks-based data platform with an automated, status-driven delivery layer connecting a client web portal, Azure Table Storage, Azure Databricks, and a leading process mining platform, orchestrated end-to-end with minimal manual intervention. Status-Driven Orchestration Every record carries a live status, from initial submission through sync completion, tracked in Azure Table Storage. Automated Bulk Processing Azure Logic Apps trigger the pipeline through APIs, so batches of records are processed without manual intervention. Reusable Databricks Framework The same medallion pipeline used for data standardization models Purchase Order data for process mining. AI-Driven Process Analysis The process mining platform’s AI reconstructs the real, as-executed process and highlights bottlenecks automatically. The Six-Step Pipeline Here’s how a single record moves from submission to a fully synced, process-mining-ready state: ⚙ Client Web PortalEnd-to-end data pipeline · Azure + Databricks 6 steps 🌐 1) Website Input The user submits data via the client web portal, a form or API request initiates the pipeline. ↓ 🗃 2) Azure Table Sync Incoming data is written and synced into Azure Table Storage. ↓ 📁 3) Status Filter Records from Azure Table are filtered where status matches: ✓ Perfect🕑 Queue ↓ ⚡ 4) Databricks Pipeline The framework is executed through the Databricks pipeline, processing all filtered records in batch. ↓ 🔄 5) Azure Table Update Once the Databricks sync completes, status is updated in Azure Table: Queue→✓ Synced ↓ 📊 6) UI Reflection Synced data is reflected back to the client web portal UI for the end user. Architecture Overview Once records reach the “Synced” state, the same medallion architecture used for data standardization models Purchase Order Details and Purchase Order Lines and delivers them into the process mining platform: ERPExtracts Row-header files → Bronze Raw landing → Silver Cleansed & standardized → Gold Business-ready models → DeltaLake Parquet delivery → ProcessMining AI-driven analysis Because the framework is configuration-driven, the same architecture can extend to additional ERP data lake sources, SFTP feeds, or other cloud storage without a redesign. AI-Driven Process Mining Analysis With Purchase Order Details and Purchase Order Lines modeled and delivered on a reliable, automated cadence, the process mining platform’s AI reconstructs the real, as-executed purchase order process directly from the underlying event data. Instead of relying on assumptions about how the process should work, process owners see how it actually works: where orders stall, which approval paths deviate from the intended flow, and where cycle time is quietly being lost. “A purchase order may look fine on paper, but the process data tells you exactly where it got stuck, and that gap surfaces automatically.” Business Impact Before After Manual exports required to analyze process performance Fully automated, status-driven pipeline from intake to process mining No visibility into where a record stood in processing Live status tracking from submission through sync completion Process bottlenecks discovered through manual investigation AI-driven analysis surfaces deviations and delays automatically Static, after-the-fact process reporting Near real-time, evidence-based process visibility One-off integration effort per process area Reusable framework, extendable to other business processes Frequently Asked Questions Does this require a specific process mining platform? No. The pipeline delivers modeled, business-ready data through Delta Lake and Parquet, which can be connected to most modern process mining platforms. How often is data refreshed in the process mining platform? The pipeline is designed for batch processing on a defined schedule, and can be tuned toward near real-time delivery depending on business needs and source system constraints. Can this be extended beyond Purchase Order data? Yes. Because the framework is configuration-driven, the same approach can extend to other process areas such as order-to-cash or procure-to-pay. What happens if a record fails validation? Records that don’t meet the status criteria simply remain in a pending state and are not passed downstream, so failures are visible and traceable rather than silently dropped. Conclusion Clean data is the foundation, but process visibility is where the business … Continue reading From ERP Data to Process Mining Insights: Building an Automated Pipeline for Real-Time Process Visibility →

Summary Enterprises running large, multi-country ERP systems often extract data that is technically complete but practically unusable, split across duplicate language columns and encoded with undocumented numeric values. We built a self-service data platform on Azure so that business users, not just data engineers, could define, validate, and process ERP extracts without writing a single line of code. The solution resolves two of the most common ERP data problems: a single field like “Item Description” spread across nine language-specific columns, and reference fields like “Order Status” stored only as numeric codes. A custom web portal puts business users in control of table specifications, validation rules, and processing status, while Azure Databricks and Delta Lake quietly do the heavy lifting behind the scenes. Business impact: dozens of ERP tables moved from raw, multi-language, code-heavy extracts to a single, trusted, human-readable data layer, without adding headcount to the data engineering team. Table of Contents 01  About the Customer 05  Self-Service Data Onboarding 02  The Challenge 06  Medallion Architecture 03  The Solution 07  Business Impact 08  FAQs 09  Conclusion About the Customer Customer Spotlight A Leading Digital Transformation Partner — Europe Our customer is a leading enterprise headquartered in Europe, operating across diverse manufacturing and supply chain divisions. Having already standardized their ERP data through a medallion architecture on Databricks, leadership wanted to go a step further: not only manage ERP data at scale, but also connect it seamlessly into process mining tools to uncover how core processes truly perform in practice. The focus was on gaining operational clarity into workflows such as purchase order management, invoice handling, and procurement cycles. The Challenge Most organizations extracting data from a large ERP system successfully get the data out. The problem isn’t extraction, it’s making that data mean something the moment it lands. Business and IT teams found themselves asking the same questions on repeat: 1Why does the same field appear nine times, with a different value in each column? 2What does “Order Status= 3” actually mean, and who is the source of truth for that mapping? 3How much manual translation and lookup work happens before a single report can be trusted? 4Can business users resolve these issues themselves, without waiting weeks on an IT backlog? 5How do we scale this across dozens of tables without writing dozens of one-off scripts? Two problems came up again and again, and both are far more common across ERP implementations than most leadership teams realize. Multi-Language Columns Because the ERP system was configured for every Order Status the business operates in, a single logical field such as “Item Description” existed as up to nine separate columns, one per language: English, French, German, Spanish, and more. Reports built directly on top of the raw extract had no reliable way of knowing which column to use for which record. In practice, this meant a plant manager in France could open a report and see item names in German, while a sales report for the Spanish market silently pulled blank fields because the Spanish-language column hadn’t been populated for that record. The data was all there; it just wasn’t usable without someone manually deciding, table by table, which language column to trust. Undocumented Domain Values Reference fields like Country, Currency, and Order Status were stored as raw numeric codes rather than readable labels, for example Order Status: 1 = Completed , 2 = In Progress, 3 = Shipped. These mappings lived inside ERP configuration screens, not in the extracted data itself. That meant every downstream report, dashboard, or spreadsheet needed its own copy of the same lookup table, manually kept in sync. When a code changed or a new Order Status was added in the ERP, there was no guarantee every report using it would be updated at the same time, which meant leadership could be looking at the performance chart that was quietly wrong. The Solution Rather than writing custom transformation logic for every table (a solution that ages badly the moment a new table or region gets added), we designed a configuration-driven pipeline built on Azure Databricks, fronted by a self-service web application that puts control directly in the hands of business and functional users. Self-Service Web Portal Business users upload table specifications, review validation results, and queue tables for processing, entirely through a browser. Medallion Architecture Azure Databricks and Delta Lake refine raw extracts through Bronze, Silver, and Gold layers, without table-specific code. Automated Language Resolution Multi-language columns are detected and normalized automatically based on the specification, not hardcoded per table. Centralized Domain Mapping Numeric and coded reference values are resolved against a single, maintained lookup layer instead of scattered spreadsheets. Self-Service Data Onboarding: No Databricks Knowledge Required The centerpiece of the solution is a custom web application that lets a business or functional analyst, not a Databricks engineer, onboard a new ERP table from start to finish. Here’s what that looks like in practice: A business user uploads an Excel-based table specification defining the expected columns, data types, which fields are multi-language, and which fields are domain-coded and how to decode them. The portal validates the specification instantly, flagging missing mandatory columns or mismatches before any data is processed, so problems are caught at the source rather than three reports downstream. Once validation passes, the same user queues the table for processing with a single click. No notebook to open, no cluster to configure, no code to write or review. Behind the scenes, that specification feeds a generic, reusable Databricks framework that already knows how to apply the correct language resolution and domain-value decoding rules, so engineering effort doesn’t scale linearly with the number of tables. In effect, the portal turns “add a new ERP table to the analytics environment” from a data engineering request into a form a finance or operations analyst can complete in minutes, while still enforcing the same rigor and consistency a hand-built pipeline would require. Medallion Architecture on Databricks Once a table is queued through the portal, Azure Databricks takes over: Bronze: Raw ERP extracts are landed as-is, preserving … Continue reading How a Self-Service Data Portal Solved Multi-Language and Domain Value Chaos in ERP Data →

Summary A Netherlands-based non-profit sustainability certification organisation reduced manual certification configuration time from hours to mere seconds using Microsoft Power Apps, implemented by CloudFronts. CloudFronts configured a multi-level assessment framework — Scope, Category, Requirement, Criteria — to automate 100% of assessment generation based on user-selected certification types and versions. The solution integrated Microsoft Power Apps with Azure Blob Storage to provide a secure, centralised repository for thousands of pieces of certification evidence, linked directly to each requirement record. Microsoft Dynamics 365 Customer Service was configured to streamline global applicant inquiries with automated case routing across Marketing, Finance, and Info queues. Business impact: eliminated manual configuration errors, provided real-time progress visibility for global applicants, and established a scalable digital foundation for global circular economy standards. Table of Contents 01 Summary 02 Introduction 03 The Business Problem 04 The Solution 05 Implementation 06 Business Impact 07 FAQs 08 Conclusion Introduction In a world where manufacturers and brands are under increasing pressure to prove the sustainability credentials of their products, the rigour and speed of certification processes can directly determine an organisation’s ability to scale its global mission. For certification bodies operating across multiple geographies, managing assessments, evidence, and applicant communication through fragmented manual processes is a bottleneck that no amount of headcount can solve. For one Netherlands-based non-profit at the forefront of the global circular economy movement, this bottleneck was real and growing. Their certification programme, built on a rigorous multi-level standard covering material safety, circularity, and responsible production, was being administered through massive Excel files, disconnected email threads, and manual document searches. This blog documents how CloudFronts partnered with this organisation to replace those fragmented processes with a unified, automated certification platform built on Microsoft Power Apps, Azure Blob Storage, Dynamics 365 Customer Service, and Power Automate, reducing certification setup time from hours to under thirty seconds. The Business Problem The organisation operates as the leading global authority on circular economy certification, serving manufacturers and brands worldwide. Their certification programme evaluates products across categories like Material Health and Circularity, across multiple standard versions — v3.1 and v4.1 — each with its own hierarchy of scopes, categories, requirements, and criteria. Before partnering with CloudFronts, this complexity was managed almost entirely by hand: Each new certification application required assessors to manually configure assessment structures from sprawling Excel files with hundreds of rows, a process that took two to four hours per applicant. Supporting evidence such as product test reports, material declarations, and third-party certificates was stored without a structured system, making retrieval slow and validation unreliable. Neither applicants nor internal assessors had real-time visibility into application status or outstanding requirements, creating persistent communication delays. Managing different certification versions across different scopes manually made scaling the programme globally nearly impossible without proportionally growing the team. The organisation needed a platform that could encode their complex certification logic, automate the heavy lifting of assessment generation, and give every stakeholder a single, reliable view of the certification pipeline. The Solution CloudFronts implemented a comprehensive digital certification ecosystem anchored by a custom Microsoft Power Apps application — the Certification Manager. The platform automates the core logic of the certification standard end-to-end, from application intake through assessment generation, evidence management, and case resolution. Key Components Microsoft Power Apps Core Certification Manager application handling applications, multi-level assessments, and the applicant-facing UI. Azure Blob Storage Secure, centralised repository for all certification evidence, linked directly to individual requirement records. Dynamics 365 Customer Service Configured to streamline global applicant inquiries with automated case routing across Marketing, Finance, and Info queues. Microsoft Power Automate Automation layer handling document upload workflows and notification triggers throughout the certification lifecycle. How It Works, At a Glance The centrepiece of the solution is a version-driven automation engine. When an assessor creates a new certification application and selects the standard version and scope, the backend logic automatically generates the complete assessment structure — all categories, requirements, and criteria — without any manual configuration. What previously took hours now takes under thirty seconds. A custom HTML-based interface within Power Apps provides visual progress indicators, allowing assessors to track completion rates across requirements at a glance. All supporting evidence is stored in Azure Blob Storage and linked directly to the specific requirement record it supports, creating a fully auditable, ISO 17065-compliant evidence trail. Implementation 1 Step 1 Certification Scheme Definition and Version Logic The foundation of the platform is the Certification Scheme Definition module. CloudFronts built a backend logic engine that stores the full structure of each certification version including all scopes, categories, requirements, and criteria as configuration data rather than hardcoded templates. When a user selects a version and scope combination, this engine automatically pulls the correct downstream structure and generates it on the application record. Updates to global standards can be deployed instantly by updating the configuration, with no changes to the application logic required. The four-level assessment hierarchy: Scope, Category, Requirement, Criteria is the structural backbone of the entire certification standard, now encoded directly into the platform. 2 Step 2 Automated Assessment Generation Once the version and scope are selected on a new application, the platform’s automation engine generates the full assessment structure in under thirty seconds, replacing a manual Excel-driven process that previously took two to four hours per applicant. The generated assessment is displayed through a custom HTML interface inside Power Apps, with visual progress indicators showing completion rates at the category and requirement level. Assessors can immediately see which requirements are outstanding, which have linked evidence, and which are ready for review. 3 Step 3 Evidence Management via Azure Blob Storage A core architectural decision was to decouple evidence storage from the Power Platform’s native Dataverse storage. CloudFronts integrated Azure Blob Storage as the document repository, with each uploaded file linked directly to the specific requirement record it supports within Power Apps. This approach delivers high-performance scalability for large evidence files while significantly reducing long-term storage costs compared to storing files natively in Dataverse. Power Automate flows handle upload automation and trigger notifications … Continue reading How a Netherlands-Based Nonprofit Achieved Global Scalability with Microsoft Dynamics 365 CRM and Power Platform →

Summary This blog highlights how Azure Logic Apps was used to overcome a critical API limitation encountered during the integration of Zoho People with FNO for payroll management. During the implementation for a global manufacturing hardware enterprise, we discovered that Zoho’s API allows a maximum of 200 records to be fetched in a single request. While this limitation may not impact smaller organizations, it creates significant challenges for enterprises managing large employee datasets. To address this issue, a scalable Azure Logic Apps solution was developed that dynamically retrieves records in batches, consolidates the results, and returns a complete dataset for downstream processing. This blog explains: Table of Contents 1. Customer Scenario During the implementation of a payroll integration between Zoho People and FNO, employee master data needed to be synchronized automatically to support payroll processing. The organization maintained a large workforce within Zoho People, and payroll operations depended on accurate employee data being transferred to downstream systems. As the integration design progressed, a significant limitation was identified within Zoho’s API framework. The API could return a maximum of 200 records per request. For organizations with hundreds or thousands of employees, this restriction created a challenge in retrieving complete employee datasets efficiently. 2. Business Challenge The integration required access to the full employee dataset from Zoho People. However, the following challenges emerged: Limited API Response Size Zoho’s API only returns 200 records per request. Large Employee Dataset The organization maintained significantly more than 200 employee records. Manual Pagination Not Feasible Static API calls would require manual intervention or complex custom development. Scalability Concerns As employee counts continued to grow, the solution needed to support future expansion without requiring redesign. The objective was to create a scalable and automated mechanism capable of retrieving all employee records regardless of volume. 3. Integration Architecture The solution architecture follows a simple but highly scalable pattern. Process Flow 4. Configuration Steps Step 1: Add HTTP Trigger Step 2: Initialize Variables Step 3: Do Until Loop Step 4: HTTP Request Action Step 5: Output Variable Step 6: Compose Variable Step 7: Append to Array Variable Step 8: Set Variable Step 8: Increment Variable Step 9: Add Response Trigger 5. Why Azure Logic Apps? Azure Logic Apps was instrumental in creating a flexible and efficient solution. Key capabilities that made Logic Apps the ideal choice included: Dynamic Variable Management Allows runtime manipulation of counters and arrays. Scalable Workflow Execution Supports large datasets without requiring custom application development. Native API Integration Provides seamless connectivity with REST-based services. Low-Code Development Accelerates implementation and simplifies maintenance. Enterprise Reliability Offers monitoring, logging, and error-handling capabilities required for production environments. 6. Outcome The final solution successfully overcame Zoho’s API record limitation. The Logic App automatically: This approach ensured the success of the Zoho-FNO integration while maintaining scalability for future business growth. 7. Business Impact 1] Fully Automated Data Retrieval Employee data is retrieved without manual intervention. 2] Improved Scalability The solution can support organizations with thousands of employee records. 3] Reduced Development Complexity Logic Apps eliminated the need for extensive custom coding. 4] Faster Integration Processing Data retrieval occurs efficiently through automated pagination. 5] Improved Reliability Built-in monitoring and error handling improve operational stability. 6] Future-Proof Architecture The solution continues to perform effectively as employee counts grow. To conclude, Integration projects often reveal platform-specific limitations that require creative problem-solving. In this implementation, Zoho’s 200-record API limitation had the potential to impact payroll synchronization for a growing workforce. By leveraging Azure Logic Apps, we developed a scalable and automated solution capable of dynamically retrieving and consolidating employee data regardless of record volume. The solution not only resolved the immediate challenge but also established a reliable and future-ready integration framework capable of supporting continued organizational growth. For organizations facing similar API limitations, Azure Logic Apps provides a powerful platform for building scalable, low-code integration solutions that simplify complex data processing requirements.

As businesses scale, payroll complexity grows bringing challenges around employee data, attendance, compensation structures, and compliance. Manual processes not only consume valuable time but also increase the risk of costly errors. The Zoho People-FNO integration transforms payroll into a streamlined, automated process, ensuring accurate salary calculations, seamless data synchronization, and complete transparency across HR and finance operations. We recently implemented this solution for a global manufacturing hardware enterprise, enabling them to automate payroll workflows, eliminate manual data reconciliation, improve payroll accuracy, and reduce administrative overhead. The integration provided a scalable foundation for managing a growing workforce while maintaining compliance and enhancing the employee experience through faster, more transparent payroll processing. For organizations focused on operational efficiency and sustainable growth, this integration delivers measurable business value from day one. Understanding the Architecture of Zoho and FNO Integration The integration between Zoho People and FNO involves a clear, structured workflow. Below is an overview of the steps involved: This architecture ensures a smooth flow of data between Zoho and FNO, simplifying payroll management for businesses of all sizes. Key Advantages of Zoho and FNO Integration The integration between Zoho People and FNO streamlines payroll management, providing several key benefits: Effortless Payroll Management for Growing Businesses To conclude, efficient payroll management is essential for any growing business. By integrating Zoho People with FNO, businesses can automate payroll processes, ensure accurate calculations, and provide employees with easy access to their payslips. The seamless data flow, real-time updates, and reduced manual intervention significantly improve operational efficiency and transparency. If you’re ready to optimize your payroll system, now is the time to take action. Embrace the Zoho and FNO integration to simplify your processes, reduce errors, and create a transparent payroll system that benefits both your employees and your organization. Contact us today to learn how this integration can simplify your payroll management process. Reach out at transform@cloudfronts.com.

Sustainability certification is one of the most operationally demanding programs a nonprofit can run. It is not just a badge on a product, it is a multi-year, multi-stakeholder process involving manufacturers, independent assessment bodies, scoring frameworks, document issuance, and public transparency requirements. When you are managing thousands of products across global industries, the cracks in a manual, spreadsheet-driven operation show up fast. This is exactly the situation a Netherlands-based nonprofit found itself in. The organization administers a globally recognized product sustainability certification program, assessing products across five dimensions: material health, product circularity, clean air and climate protection, water and soil stewardship, and social fairness. Products move through certification levels Bronze, Silver, Gold, and Platinum across a lifecycle that spans application, third-party assessment, issuance, and periodic recertification every three years. As certification volumes grew, so did the operational complexity. Disconnected tools, manual document preparation, and no single place to track everything meant the team was spending more time managing the process than running it. Rather than bolt on yet another external tool, the organization made a deliberate architectural choice: build the entire certification management platform inside Microsoft Dynamics 365, extend it with Azure Function Apps for automation, and expose public APIs for ecosystem transparency. The Goal Build a unified, scalable certification lifecycle management system inside Dynamics 365 that automates document generation, manages logo assets, and exposes public APIs for published certification data — all without introducing new platform dependencies. The Business Problem To understand what was built, you first need to understand what was broken. The organization’s operational teams were trying to answer some fairly fundamental questions every single day — What is the current certification status of a given product? Which products are approaching their recertification deadline? Which assessment body certified a product and when? Is the certificate document ready for issuance? None of these questions had a reliable, centralized answer. Certification records lived across disconnected spreadsheets and email threads, which meant any “current” view of a product’s status was only as accurate as the last person who updated a row. Certificate documents were manually composed for every issuance a slow, error-prone process that created formatting inconsistencies and delayed the experience for certified manufacturers. Logo assets were managed informally, with no version control or consistent delivery process. No Single Source of Truth Certification records scattered across spreadsheets and email threads with no reliable current view. Manual Document Creation Every certificate composed by hand slow, inconsistent, and a bottleneck manufacturers felt directly. Zero Public Transparency External stakeholders relied on manually updated static pages with no programmatic access to live data. Unscalable Operations Growing program volumes with no automation meant every new product added to the manual workload. The Solution Architecture The platform was designed around one principle: build close to where the operational data already lives, and automate at the right trigger points rather than everywhere at once. The solution runs on three deliberate layers. Critically, this architecture avoided over-engineering entirely — no separate data warehouse, no heavy ETL pipeline, no dedicated certification SaaS platform requiring its own licensing and maintenance. Everything runs inside the Microsoft ecosystem. 1 Data Layer — Custom Dynamics 365 Tables Purpose-built Dataverse tables that mirror the certification domain exactly, products, certification events, assessment bodies, category scores, and logo assets all in a single relational, auditable structure. 2 Automation Layer — Azure Function Apps, Dynamics Plugins Two event-driven Function Apps sit alongside the CRM one for certificate document generation, one for logo package delivery, both triggered by real state changes in the certification lifecycle, not a schedule. 3 Transparency Layer — Public REST APIs Public-facing APIs expose published certification data to external stakeholders, brands, retailers, regulators, and third-party platforms without any manual data exchange with the organization. Custom Dynamics 365 Data Model The data model is the foundation everything else rests on. Rather than forcing certification concepts into standard CRM entities that were never designed for this domain, the team built purpose-specific custom tables inside Dataverse that mirror how the certification program actually works. Product data Core product records, variants, and identifiers — the foundational layer that everything else references. Application handling Applications, assessments, category and requirements assessments — all managed within accounts. Assessment bodies and related workflows live here too. Public-facing entities Public tables for products, certifications, certificates, and product variants — the data layer that powers external visibility and API exposure. Together, these layers gave the organisation a complete, relational view of every certified product across its full lifecycle — all within a single operational platform. Certificate Document Generation via Azure Function App Before this system existed, every certificate document was created by hand. Someone would take a template, fill in the product details, format it, check it, and send it. For an organization issuing certificates across thousands of products, this was not just slow — it was a source of constant inconsistency and a bottleneck that manufacturers felt directly. The Azure Function App for certificate generation eliminated this entirely. Here is how it works end to end: How It Works ⚡ Trigger Certification record reaches the correct status in Dynamics 365 → 🔍 Fetch Pulls record + product data via Dynamics 365 Web API → 📄 Generate Selects correct template, populates all fields, generates document → 🔗 Store & Link Saves document and links it back to the certification record What this means in practice is that certificate issuance is now consistent, fast, and entirely hands-off for the operational team. Formatting is guaranteed every time because the template logic is defined once and applied uniformly. The function also runs independently of the CRM interface — making it resilient and reusable across multiple trigger scenarios, including bulk recertification processing. The impact: A task that previously required manual effort for every single issuance now requires none. Eliminated entirely. Logo Image Generation via Azure Function App A certified product comes with more than a document — it comes with the right to use the certification mark. For manufacturers, that logo is a commercial asset. It goes … Continue reading How a Netherlands-Based Non-Profit Transformed Certification Management with Dynamics 365 and Azure Functions →