Summary This post started with a real request. A Netherlands-based sustainability certification company that runs its certification programme on Dynamics 365 wanted the certificates it issues to come straight out of the CRM, instead of being rebuilt by hand in a document every time. The problem itself is common. Certification bodies, testing labs and manufacturers issue certificates every day, and in most organisations that still means a Word template, a lot of copy and paste, and a PDF sent by email. The data that belongs on the certificate already lives in Dynamics 365, so why can’t the certificate come straight from the record? In this blog we build exactly that. A Generate Certificate button on a Dataverse form calls a Custom API, a small plugin hands the data to an Azure Function, and a branded, print-ready PDF comes back in about four seconds. Today the PDF is stored on the record as a base64 string, previewed and downloaded right on the form. Because the renderer only returns bytes, sending the same file to SharePoint, Azure Blob Storage or an email is a change to one step, not a rebuild. In This Blog This blog walks through a complete, working certificate generator for Dynamics 365, from the data model to the button, using a product certification scenario. The Scenario: A certification body issues product certificates and needs every one to be accurate, branded and traceable. The Approach: Keep the data in Dataverse, render the PDF in an Azure Function, and connect them with a Custom API. The Action: One click on the form produces the certificate, stores it on the record and shows a live preview. The Outcome: No manual formatting, no retyping, no per-document licence fees, and a design that can later publish to SharePoint or Blob storage. Table of Contents Summary→ In This Blog→ Business Challenges→ Solution Overview→ Technical Approach→ Impact→ Conclusion→ FAQ→ Get in Touch→ Business Challenges A certificate is a legal statement: this product, made by this company, meets this standard, from this date to that date. When it is produced by hand, the risks are small individually and expensive together. Copy and paste errors. Product names, model numbers and expiry dates are retyped from the CRM into a document. One wrong digit on an issued certificate means a reissue and an awkward conversation. Template drift. Every coordinator keeps a slightly different copy of the Word template, so logos, wording and signatories quietly diverge. No trail. Once the PDF leaves someone’s desktop there is no record of which version was produced, when, or from which data. Platform limits. Dataverse plugins run in a sandbox that cannot lay out and paginate a PDF, and a JavaScript-only solution would expose service keys to every user’s browser. Before Word template and email Values retyped from the record Layout depends on who made it File lives in someone’s Downloads folder No link back to the CRM record After One click on the record Values read directly from Dataverse One design, driven by configuration PDF stored on the record with its hash Preview and download on the same form Solution Overview The demo uses a fictional certification body, Contoso Product Assurance, which certifies products made by manufacturer accounts against its own published standards. The whole flow runs from a single button: FormGenerate CertificateCommand bar button on the Product Certificate form DataverseCustom APIBound action cf_GenerateCertificate PluginCollect the dataCertificate, product, holder and standard AzureRender the PDFFunction returns the file as base64 RecordStore and previewBase64 saved, previewed and downloadable Architecture One click on the form, one PDF back on the record. The dashed box is where SharePoint, Blob storage or email plug in later. Data modelThree custom tables (Standard, Product, Certificate) plus the standard Account table for manufacturers. Custom API and pluginOne server-side entry point. The function key never reaches the browser. Azure FunctionA .NET 10 renderer on the Consumption plan. Vector PDF, embedded fonts, QR code. Form experienceGenerate and Download buttons plus an inline PDF preview panel. A certificate generated from Dataverse data. Every value on it comes from the record; nothing is typed. Technical Approach 1. The data model Everything lives in one solution, CFCertificateGeneration, so it moves between environments as a unit. Table Purpose Key columns Certification Standard What products are assessed against Code, Version, Default Scope, Validity (Months) Certified Product What is being certified Product Number, Manufacturer (Account), Category Product Certificate The issued certificate Auto-numbered Certificate Number, Status, Issue and Expiry Date, Product, Standard, Holder, Signatory, PDF (Base64), File Name, SHA-256, Generated On The Product Certification app: every certificate with its status, validity and when it was last generated. The certificate number is a Dataverse auto-number column with the format CPA-{DATETIMEUTC:yyyy}-{SEQNUM:5}, so numbering is guaranteed unique by the platform rather than by a person. The certificate holder defaults to the product’s manufacturer and can be overridden when a brand owner holds the certificate for a product someone else makes. 2. The renderer The PDF is drawn with SkiaSharp and the QR code with QRCoder, both open source. The same drawing code targets either a PDF page or a PNG bitmap, which means the image you check during development is exactly what the customer receives. Text is real, selectable text in embedded fonts, every graphic is a vector shape rather than an image, and long product names shrink to fit instead of overflowing the frame. CertificateRenderer.csC# public RenderedCertificate RenderPdf(CertificateRequest request) { Validate(request); using var output = new MemoryStream(); using (var document = SKDocument.CreatePdf(output, metadata)) { var canvas = document.BeginPage(842f, 595f); // A4 landscape, in points Draw(canvas, request); // same code paints the PNG preview document.EndPage(); document.Close(); } return new RenderedCertificate(output.ToArray(), FileNameFor(request.CertificateNumber)); } Vector from edge to edge, so quality never breaks There is not a single raster image in the certificate. Every line of text is real text in an embedded font, and the frame, the seal, the dividers and even the QR code are drawn as vector shapes. Zoom to 800%, print it on A3 or project it on a … Continue reading How a Sustainability Certification Nonprofit Automated Certificate Generation in Dynamics 365 →

Summary This article explains how a data pipeline can be used to prepare Business Central data for demand forecasting. Raw data may contain missing values, inconsistent fields, and information that is not immediately suitable for analysis. The pipeline uses a three layer Medallion architecture: Bronze for storing the raw data, Silver for cleaning and preparing it, and Gold for creating the final data needed for analysis and forecasting. A key principle throughout the process is “NULL is not 0” . A missing value does not always mean that the value is zero. The pipeline therefore uses context aware handling and missing data flags so that the original meaning of the data is not lost. The article explains the complete flow from data ingestion through cleansing, NULL handling, transformation, and aggregation, along with the code and examples used to implement each step. Table of Contents 1. Introduction 2. The Business Problem The Solution 3.1 Medallion Architecture Overview 3.2 Ingestion API from Business Central 3.3 The NULL Philosophy 3.4 Silver: Intelligent Imputation 3.5 Flagging the Unknown 3.6 Gold: Aggregating Without Lying 4. Limitations & Considerations 5. Business Impact 6. FAQs 7. Conclusion 1. Introduction In modern supply chain and demand forecasting, data quality is the foundation of every decision. Business Central can serve as a source for sales, inventory, purchases, and transfer data. However, raw CDC (Change Data Capture) payloads extracted through the OData API may require additional cleansing before they are forecast ready. Fields were missing, column names were inconsistent, and most critically NULLs were everywhere . While Business Central stores transactional data reliably, the OData API exports often include null values for optional fields, unpopulated attributes, or fields that simply don’t apply to certain record types. Treating these NULLs as zeros would have been a catastrophic mistake in demand forecasting. A NULL in a sales quantity column doesn’t mean “zero units sold” it means “we don’t know”. Erasing that distinction would hide the difference between genuinely zero demand and missing data, leading to under forecasting, misplaced safety stock, and costly stockouts. To solve this, I built a 3 layer Medallion pipeline (Bronze → Silver → Gold) in Azure Databricks. I also designed a custom ingestion API using Databricks’ OData V4 connector wizard to pull 12 ERP entities directly into Azure Blob. The Silver layer introduced a “NULL is not 0” philosophy, with context aware imputation and boolean flags to preserve data quality signals. The Gold layer aggregated daily demand per item location, leaving NULLs as NULL to correctly represent “no data” days. This article walks through the architecture, the imputation logic, and the practical lessons learned from transforming 12 messy datasets into a clean, forecast ready mart. 2. The Business Problem The organization relied on manual Excel spreadsheets to prepare demand forecasts across 22 high impact items and 3 warehouse hubs a total of 66 item location combinations . This manual process was error prone and unscalable. Several challenges emerged: Heavy reliance on spreadsheets: Demand planning was executed via disconnected, static Excel files. Frequent formula errors, broken references, and accidental overwrites led to incorrect estimates. Lack of scalability: Manually calculating forecasts across 66 combinations was time consuming. Excel could not dynamically model complex interactions like monthly seasonality and day of week demand patterns simultaneously. Reactive procurement and stockouts: Teams spent more time cleaning data than analyzing risk. Static buffer stocks failed to account for changing supplier lead times, resulting in emergency purchase orders or stockouts during peak seasons. NULLs were treated incorrectly: In many cases, missing values were simply replaced with 0, masking the true state of the data and causing the forecast model to underestimate demand. The Objective: Build a reliable, automated pipeline that ingests raw CDC data from Business Central, cleanses it with context aware logic, and produces a daily demand mart that distinguishes between “zero sales” and “unknown sales” . 3. The Solution The solution was designed as a Medallion architecture with three distinct layers, each serving a specific purpose in the data quality journey. 3.1 Architecture + Diagram 3.1 Medallion Architecture Overview The pipeline processes 12 raw JSON datasets from Business Central through Bronze, Silver, and Gold layers in Azure Databricks. SVG Diagram 1: Medallion Architecture Medallion Architecture Business Central Data Pipeline Business Central OData V4 / REST API 12 CDC datasets Databricks OData V4 Connector Auth · Pagination · Parsing Azure Blob Bronze (Raw JSON) Immutable landing 🥈 Silver Layer Cleaning · Typing · Flagging • Remove @odata.etag • Standardize columns · Cast types 🥇 Gold Layer Aggregation · Business Logic • Daily demand per item location • NULLs preserved as “no data” 📊 Forecasting & Analytics Power BI · ML Models · Business Decision Support Read only pipeline cleaned data remains in the analytical pipeline Medallion architecture: Business Central OData → Bronze → Silver (cleaning) → Gold (aggregation) → Analytics 3.2 Ingestion API from Business Central The first step was to build a reliable ingestion layer. I used the OData V4 connector wizard in Databricks to set up an authenticated connection directly to Business Central’s REST API. This connector handled pagination, authentication (Azure AD OAuth 2.0 with Key Vault), and parsing of the OData response format (data wrapped inside a “value” array). I configured it to pull all 12 datasets that feed into the forecasting pipeline. Security: Zero hard coded credentials all secrets stored in Azure Key Vault. Endpoints: Pulled items , sales_lines , purchase_headers , item_ledger_entries , and 8 other entities. Landing: Raw JSON payloads were written to Azure Blob (Bronze) as immutable snapshots, preserving the original CDC state. 3.3 The NULL Philosophy Before writing a single line of PySpark, I defined a clear rule: NULL is not 0 . This principle guided every transformation in the Silver layer. In demand forecasting, a NULL in a sales quantity column means “we don’t know”. It could be due to a missing transaction, a CDC gap, or a field that doesn’t apply to that record type. Treating it as zero would artificially deflate demand, … Continue reading Building a 3-Layer Pipeline to Cleanse Business Central Data for Forecasting →

The Warning Signs Were Always There – Project Risk Engine Summary On most delivery projects, the warning signs appear well before the escalation. They sit in email threads, support case notes, overdue invoice reminders, and resource utilization reports – scattered across systems that nobody has the time to cross-reference every week. By the time a project gets formally marked at risk, it is usually already a difficult conversation. This post shares what we built at CloudFronts to solve that problem from the inside. The Project Risk Engine uses a multi-model AI approach running on Azure Databricks to read unstructured project communication, score project health, and flag projects in RED – all surfaced to project managers inside Microsoft Teams through Databricks Genie, in plain English. We built it for our own PMO first. This article walks through why we built it, how it works, and what it changed. Table of Contents 01 Where This Started 02 Where Project Health Actually Lives 03 What the Risk Engine Does 04 How It Works – Four Layers 05 How a Project Gets Flagged RED 06 Genie in Teams 07 What Changed for the Team 08 Who It Helps 09 How to Implement This 10 Challenges We Faced 11 FAQs 12 Conclusion Where This Started This did not start as a product idea. It started as a recurring frustration inside our own team – the group at CloudFronts responsible for delivery and billing excellence. Three things kept happening. Early warning signs were buried in long email chains, so risks only surfaced after they had grown. Project managers had no quick way to assess project health, which meant the team reviewed each project by hand every week just to work out where things stood. And because we run many projects simultaneously, it was easy for a real problem to slip through unnoticed. Here is a real example. One of our clients had a support agreement coming up for renewal. It is the kind of thing everyone assumes someone else is tracking – but it was not flagged until almost the last day. If that client had decided not to renew, leadership would have had no early warning at all. The information was there. It just was not in front of anyone in time. In another case, a project had two phases and the client had not yet confirmed the scope for the second. That was a clear risk to the final payment. Most of us were aware of it in some abstract way – but the project was not formally flagged until the invoice was already due. A few weeks earlier would have made a real difference. “The warning signs were already there. They were just scattered, and easy to miss until it was too late.” Where Project Health Actually Lives A project’s health is not in one place. It is spread across four areas – and any one of them, left unmonitored, can become a risk that affects cash flow, client relationships, or delivery quality. Booking Contract renewals, new work coming in, and MSA status. A contract quietly approaching expiry is a risk most teams only notice when it is almost too late. Billing & Delivery Project status, open risks, support tickets, internal notes, and the client emails tied to them. This is where the unstructured signals sit. Collection What has been invoiced, what is outstanding, and what is running overdue. Delayed invoicing and unpaid milestones are early indicators of a project in trouble. Resource & Utilization Who is working on what, how busy they are, and where allocation gaps are forming. Low utilization on a contracted engagement is a billing risk waiting to happen. Any one of these on its own does not tell you much. You only see the full picture when you put all four together – and that is exactly what the engine does. What the Project Risk Engine Does 1Unifies the data – Delivery, support, billing, and resourcing data from Dynamics 365 CRM and Outlook is pulled into one governed dataset on Azure Databricks, structured through a Medallion Architecture (Bronze → Silver → Gold). 2Reads the unstructured signals – AI reviews client emails, internal notes, and case history to surface hidden threats: delays, blockers, escalation patterns, and unanswered client requests that never make it into a status field. 3Scores and flags – Every project receives a health score from zero to ten, along with a risk summary, identified threats, and next recommended actions. Projects meeting RED criteria are automatically flagged. 4Makes it conversational – Project managers can ask questions about any project in plain English, directly inside Microsoft Teams through Databricks Genie. No dashboards to open, no reports to pull. How It Works – A Multi-Model, Four-Layer Approach The risk analysis is not a single AI call. It is a deliberate, layered process – lightweight checks first, heavy AI only where it is needed. This keeps it fast and cost-efficient while ensuring accuracy on the things that matter. Layer1 Rule-Based Pre-Filter No AI involved. Simple rules filter out inactive email threads not part of any recent communication, eliminating noise before any model is engaged. Layer2 Lightweight AI Triage A smaller model sorts remaining threads into four categories: active, completed, informational, or waiting. Only active and waiting threads move forward. Layer3 Deep Risk Analysis A larger model – Claude Sonnet 4.5 – runs deep analysis on threads that survived the first two layers. It is used here because this stage requires stronger reasoning: detecting underlying threats, assessing likelihood, and estimating impact. Layer4 Executive Summary Everything is rolled up into a project health score (0–10), top threats, and recommended next actions – a clear, evidence-backed picture of where each project stands. Solution Architecture Here is how the full architecture fits together – from data sources through to the project manager asking a question in Teams. Data flows from Dynamics 365 CRM and Outlook → Azure Logic Apps → ADLS Gen2 Medallion layers → Azure Databricks → Genie AI → Microsoft Teams … Continue reading How CloudFronts Built a Project Risk Assessment Engine with Databricks Genie →

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

Summary Enterprises have spent years solving the data extraction problem — moving SAP data into warehouses, lakes, and reporting platforms. But extraction is largely a solved problem. The real challenge now is making that data understandable, trustworthy, and useful — to both business users and AI systems. That shift requires business context, metadata, and governance, not another connector. This blog shares observations from an enterprise data modernization assessment and offers a perspective on how SAP Business Data Cloud should be evaluated — not as just another extraction tool, but as a capability that can bring SAP data, business semantics, metadata, and governance closer together. It also examines why zero-copy data sharing, while valuable, is only part of the answer, and why metadata strategy should be defined before any platform is selected. The central argument is straightforward: AI without trusted business context produces answers that are technically valid but business-wrong. Before any AI layer is added, the foundation must be right — and that means starting with the right question: not “which tool?” but “what does this organization need its data platform to become?” Table of Contents 01 Introduction 02 Extraction Is No Longer the Challenge 03 BDC Is Not Just a Connector 04 Metadata Is the Foundation 05 Zero-Copy — Important but Incomplete 06 From Technical Data to Business Data 07 The AI Conversation 08 Evaluate the Outcome, Not the Tool 09 So, Why SAP Business Data Cloud? 10 FAQs 11 Conclusion Introduction Most conversations about SAP data integration start in the wrong place. They begin with extraction — which tool moves data fastest, which connector supports CDC, which platform has the best SAP adapter. These are reasonable technical questions, but they are increasingly the wrong ones to be leading with. The organizations genuinely advancing their data capabilities are not asking “how do we get SAP data out?” They are asking “how do we make SAP data understandable, trustworthy, and useful — to both our people and our AI systems?” This blog shares observations from an enterprise data modernization assessment and offers a perspective on how we should be thinking about SAP Business Data Cloud — not as just another extraction option, but as part of a broader conversation about metadata, business context, and what modern enterprise data platforms actually need to deliver. Data Extraction Is No Longer the Biggest Challenge Over the years, organizations have invested heavily in moving data from ERP systems into data warehouses, data lakes, and reporting platforms. The architecture often becomes: SAP → Extraction → Staging → ETL → SQL → Semantic Model → Power BI It works. But over time, every additional layer introduces another copy of data, another technology to maintain, another process to monitor, and another place where business logic can be implemented. In one enterprise modernization assessment, the existing landscape included SAP, DP Agents, SAP Datasphere, SSIS, SQL Server, and Power BI. The challenge was not a shortage of technology. The challenge was multiple movement layers, duplicated logic, and no single place where the data could be understood as a whole. That is where the conversation about SAP BDC needs to start. BDC Is Not Just Another SAP Connector If we compare SAP BDC only on extraction capability, the difference becomes difficult to justify. Most modern tools — BDC, Datasphere, and various DBT-based approaches — can all support data extraction and incremental or CDC scenarios to varying degrees. But when we introduce another dimension — business context — the discussion changes entirely. A modern enterprise data platform needs to answer: 1What does this field actually mean in business terms? 2Is this a customer, vendor, product, or financial measure? 3What is the agreed business definition — and who owns it? 4Which KPIs depend on this data element? 5How does this business object relate to others? 6Can this data be trusted — and can an AI agent understand its context? This is where metadata stops being a nice-to-have and becomes the foundation on which everything else depends. Metadata Is the Foundation Metadata should be one of the first things defined before selecting a data platform. Technology should follow business requirements — not the other way around. A modern metadata strategy needs to cover: Business Metadata Technical Metadata Relationships Business Glossary Semantic Definitions Data Quality Ownership Lineage Classification & Change Why does this matter? Because the direction of enterprise analytics is shifting: From “Where is my data?” To “What does my data mean?” And eventually “Can AI understand my data and give me a trusted answer?” That progression requires context — and context requires metadata. You cannot shortcut this by starting with AI. “The future of analytics is not about finding data faster. It is about understanding data better — and making that understanding available to both people and AI systems.” Zero-Copy Is Important — But It Is Not the Whole Story One of the strongest technical capabilities highlighted in the assessment is BDC’s managed zero-copy data sharing approach. It can reduce unnecessary data movement while allowing SAP data to participate in the broader enterprise data architecture without being physically duplicated across systems. This matters because data movement has a cost — in infrastructure, in latency, in maintenance, and in the accumulation of inconsistent versions of the same data sitting in different places. But zero-copy should not be positioned as the only reason to choose BDC: Zero-copy solves the movement problem — reducing duplication and infrastructure cost Metadata and business semantics solve the understanding problem — making data meaningful and trusted The second problem is becoming increasingly important, and it is the one most extraction-focused evaluations fail to address. From Technical Data to Business Data A traditional data platform is typically designed around tables and pipelines. A modern data platform needs to move closer to business objects and business domains. Instead of asking a business user to understand technical SAP table names like VBAK, VBAP, KNA1, or MARA, the platform should provide business-level concepts: Customer → Sales Order → Product → Revenue → … Continue reading SAP Business Data Cloud: More Than a Data Platform →

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

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

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

What the CloudFronts PMO Does on a Microsoft Dynamics 365 ERP Project Summary Most Microsoft Dynamics 365 ERP implementations that struggle do so for the same reason: the technology was delivered, but the collaboration wasn’t. The CloudFronts PMO runs every Dynamics 365 ERP engagement on a structured operating model, onsite discovery, daily working sessions, Azure DevOps tracking, a clear RACI framework, and tiered communication, so both teams always know what’s happening, what was decided, and what comes next. On a real Dynamics 365 deployment for a Leading North American commercial vehicle manufacturer, this structure replaced scattered status updates with a live, always-current view of project health that protects the Client well beyond go-live. Table of Contents 01 Summary 02 About the Engagement 03 The Challenge 04 The PMO Approach 05 RACI Framework 06 Environment Pipeline 07 Communication Cadence 08 Documentation & Handover 09 Business Impact 10 FAQs 11 Conclusion About the Engagement Engagement Spotlight A Leading North American Commercial Vehicle Manufacturer Dynamics 365 ERP Rollout, Run Onsite from Day One What follows comes directly from a real Microsoft Dynamics 365 ERP deployment CloudFronts is running for a manufacturing Client. Before a single configuration was touched or a user story written in Azure DevOps, our Solution Architect and the project manager visited the Client’s manufacturing facility together, walking the production floor, spending time in warehousing and operations, and sitting with the teams who work with these processes every day. The goal was straightforward: understand the business before touching the system. Every practice described below, the onsite visit, the daily sessions, the structure, is something the team lived, not something read about. The Challenge Dynamics 365 ERP projects don’t usually fail because the technology can’t do the job. They fail because of how teams collaborate, communicate, and take ownership throughout the project. Without a structured PMO, teams on ERP engagements frequently find themselves asking: 1Did the Client actually sign off on this, or did we just move on? 2Who owns this decision, us or the Client? 3Is this environment actually production-ready? 4Has this been tested, or just built? 5Will the Client’s team be able to run this on their own after go-live? Left unanswered, these questions turn into scope creep, missed sign-offs, go-live delays, and end users who were never truly ready. The PMO Approach To close that gap, the CloudFronts PMO runs every Dynamics 365 ERP engagement on four connected practices: Onsite Discovery Walking the production floor and operations areas before configuration starts, so scope reflects the real business, not just what’s written in a document. Scope Tied to Outcomes Every phase begins with a written scope, and milestone sign-offs are tied to confirmed outcomes, not calendar dates. Daily Working Sessions Four sessions a week, Monday through Thursday, where work is demonstrated, tested, and decided on in real time. Azure DevOps Tracking Every Epic, Feature, User Story, Task, and Bug tracked on one shared board, visible to the Client at all times. RACI Framework One of the first things the CloudFronts PMO does on any Dynamics 365 ERP engagement is establish a clear RACI matrix, who is Responsible, Accountable, Consulted, and Informed for every area of the project. It isn’t a governance document that sits in a folder; it’s a shared agreement people refer to when a decision needs to be made. Project Area Client CloudFronts Requirements & business process documentation Accountable Responsible Build & configuration — Responsible & Accountable Testing & go-live Accountable Responsible (supports & executes) Environment Pipeline The CloudFronts PMO maintains a full environment pipeline for every D365 ERP implementation. Each environment has a defined purpose, and nothing reaches Production that hasn’t been proven first. 1Developer VM — configuration and build work begins here 2QA — demonstrated and validated in daily working sessions 3UAT / Sandbox — the Client’s business users test and sign off 4Gold — the clean backup environment 5Pre-Production — a full mock cutover before the real go-live 6Production — go-live, after repeated proof it works The Client goes live with confidence because they have already seen their system work under production-like conditions, repeatedly. Communication Cadence The CloudFronts PMO structures communication deliberately across three levels, so the right people get the right information at the right time: Every 2 weeks — Management Status readout for leadership, covering project status, risks, and decisions that need escalation Twice a week — Project managers align on priorities and blockers Four days a week — Implementation and integration teams run hands-on working sessions There are no surprises at the executive level, because issues are surfaced and handled before they become big enough to need that conversation. Documentation & Handover Every CloudFronts D365 ERP implementation produces a complete documentation set, stored in SharePoint/Teams and Azure DevOps so both teams can access it at all times: Status Update Presentations Daily Checklists Configuration & Customisation Docs Integration Documents User Manuals Test Scenarios Issue-Solution Tracker Documentation is the work nobody enjoys doing. But it’s also what allows the Client’s internal team to support and maintain the system independently after go-live. A well-documented implementation is not just a delivered project, it’s a handover that actually works. Business Impact Before After Status updates delivered monthly, after the fact Live working sessions four days a week Ownership unclear across workstreams RACI matrix used daily to resolve decisions Environments used inconsistently across the project Full Dev-to-Production pipeline with a mock cutover Documentation created only at the end, if at all Complete documentation set maintained throughout Sign-offs based on completed sprints Sign-offs tied to outcomes confirmed in QA Frequently Asked Questions 1What does the CloudFronts PMO approach look like on a Microsoft Dynamics 365 ERP project? The CloudFronts PMO combines structured scope definition, daily working sessions, Azure DevOps-based tracking, a clear RACI framework, and a full environment pipeline from Dev through to Production. This ensures the Client has full visibility at every stage and that every milestone is signed off on outcomes, not just activity. 2Does CloudFronts implement both Dynamics 365 Finance & Operations and Business Central? … Continue reading A Successful Microsoft Dynamics 365 ERP Implementation Isn’t Just About the Software – It’s About How You Show Up →

Summary Designed and deployed a mobile-first Power Apps Canvas App for a Texas-based industrial cybersecurity firm specializing in operational technology (OT) security for oil and gas infrastructure. Unified time tracking, expense management, material consumption logging, and approvals into a single experience integrated with Dynamics 365 Project Operations. Eliminated fragmented desktop-based workflows that delayed project reporting, approvals, and billing. Automated expense receipt processing through Power Automate, improving compliance and reducing manual effort. Implemented project-scoped approval routing to ensure submissions were reviewed only by authorized stakeholders. Enabled real-time project visibility through structured Dataverse-driven workflows and lifecycle tracking. Provided mobile approvals and submission monitoring, dramatically reducing turnaround times. Improved data accuracy, audit readiness, and billing efficiency across field operations. Table of Contents Introduction Requirement & Business Scenario Solution Implementation Implementation Gallery Outcome FAQs Conclusion 1. Introduction Field-driven organizations live and die by the accuracy and speed of their project data. For a company securing critical infrastructure like oil rigs, every hour an engineer spends fighting with a clunky time-entry screen is an hour not spent on the job site — and every delayed expense submission is a delay in client billing and financial reporting. This is the story of how a Texas-based cybersecurity firm moved away from a fragmented, desktop-oriented workflow inside Dynamics 365 Project Operations and adopted a unified, mobile-first Canvas App that brought time tracking, expense submission, and material logging into one place, with built-in compliance controls and project-specific approval routing. The Goal: Build a unified mobile-first experience that allows field engineers to submit time, expenses, and materials from anywhere while ensuring compliance, controlled approvals, and real-time project visibility. 2. Requirement & Business Scenario The firm manages multiple concurrent field engagements using Dynamics 365 Project Operations as its system of record. Consultants and field engineers were expected to log three categories of activity against active projects: Time entries for hours worked Expense entries covering travel, accommodation, airfare, and related costs Material usage logs for equipment, parts, and consumables The core issue was that the underlying system was built for desktop use, not for engineers working on-site at remote rig locations. This created several compounding problems: Field staff had no efficient way to submit entries from a mobile device, so submissions piled up until they were back at a desk. Time, expense, and material tracking lived in separate workflows, forcing users to context-switch between screens for what should have been a single daily task. Expense compliance was inconsistent — receipts were sometimes attached, sometimes forgotten, and the process for linking a receipt to an expense record involved several manual, error-prone steps behind the scenes. Approvals had no project-level boundaries, making it hard to guarantee that only the right project stakeholders could review and approve specific submissions. Project managers lacked real-time visibility into resource usage, which meant billing and client reporting cycles were consistently delayed. Left unaddressed, these gaps were directly affecting data accuracy, audit readiness, and the speed at which the business could invoice clients. 3. Solution CloudFronts designed a unified mobile experience using Power Apps Canvas Apps layered on top of Dynamics 365 Project Operations and Dataverse, built around one guiding principle: One App. All Submissions. Controlled Approvals. Real-Time Visibility. For field users, the app became the single place to submit time entries on a daily or weekly basis, create expense entries with automatic receipt handling, log material consumption against the correct project, and track the live status of every submission. For project approvers, the same app surfaced only the entries tied to projects they were actually responsible for, let them approve or reject submissions directly from their phone, and preserved a clean, audit-ready trail for every decision. Day Mode and Week Mode Users could switch between a detailed single-day entry view, useful for precise logging and corrections, and a bulk weekly view that sped up repetitive data entry — letting each person work the way that suited their role. Calendar-Based Swipe Navigation A Dynamics-style calendar with swipe gestures let users move quickly across days and weeks, reviewing or correcting historical entries without friction. Stage-Aware Interface Every record followed the same lifecycle — Submitted, Pending, Approved, Rejected, Recall Requested, Recall Approved, Recall Rejected — and the UI adapted to whatever stage a record was in. Action buttons such as Submit, Approve, Reject, and Recall only appeared when they were actually valid, significantly reducing user confusion and accidental actions. Conditional Receipt Enforcement Rather than requiring a receipt for every expense category, the app applied compliance rules selectively. Receipts were mandatory for airfare and OT hardware purchases, while remaining optional for lower-risk categories such as meals and local transportation. 4. Implementation The technical implementation centered on a unified Dataverse data model and a set of automations that removed manual work from both the field user and the back office. Unified Data Model Time, expense, and material entries were all structured in Dataverse and linked back to the relevant project, resource, approval record, and — for expenses — supporting documentation. Every submission created a record with a clearly defined lifecycle stage, ensuring all three entry types behaved consistently even though their underlying business logic differed. Validation Before Submission The Canvas App enforced field-level validation before allowing a record to be saved, checking that essentials such as transaction date, project, category, quantity, and cost information were populated. If( Or( IsBlank(DatePicker.SelectedDate), IsBlank(ProjectCombobox.Selected), IsBlank(CategoryCombobox.Selected), IsBlank(QuantityInput.Value), IsBlank(PriceInput.Value) ), Notify(“Required fields are missing.”, NotificationType.Error) ) Patch-Based Record Creation Once validation passed, the application used Dataverse Patch operations to create records and calculate derived values such as expense subtotals dynamically based on quantity and unit price. Automated Receipt Handling For expense submissions, the previously manual chain of creating an Expense Receipt record, attaching a file as a Note, converting it to the correct document format, and updating the status to Submitted was fully automated. The Canvas App passed the expense ID, file name, and file content to a Power Automate flow, which created the Expense Receipt record, stored the file as a Note (Annotation) with the correct MIME type, … Continue reading How an Industrial Cybersecurity Company in Texas Improved Field Time and Expense Tracking with Microsoft Power Apps and Dynamics 365 Project Operations →