Summary Connecting Dynamics 365 Project Operations with Business Central creates a continuous data journey from project planning and execution to financial visibility. Project and task information, planning lines, time, materials, expenses, billable values, and invoices must retain their identity and meaning as they move between systems. This implementation focuses on preserving those relationships so that Budget, Actual, Billable, and Invoiced values remain traceable and meaningful throughout the project lifecycle. The result is an integration that does more than synchronize records: it creates a reliable data story that supports project operations, ERP processes, financial analysis, and decision-making. Table of Contents Why Project Data Needs a Journey The Data Journey Entity-to-Entity Mapping Planning Lines Budget vs. Actual vs. Billable vs. Invoiced Execution and Project Journals From Activity to Invoice The Analytics View Implementation Lessons Conclusion The Project Does Not Live in One System Project Operations is where teams plan and manage project work. Business Central is where the project becomes part of an ERP financial workflow. The interesting part is the space between them. When the same customer, project, task, resource, or transaction crosses that boundary, the integration has to preserve more than a name. It has to preserve relationships and translate the source record into the target system’s business model. The Engineering Question “Did the record sync?” is only the first question. “Does the record still mean the same thing?” is the engineering question. CRM Project Operations Where the Project Is Planned Customer, project, tasks, resources, estimates, time, and project activity are planned and managed here. ERP Business Central Where the Project Becomes Financial Project tasks, planning lines, journals, invoices, and financial visibility form the ERP financial structure. CRM side Figure 1: A Project Operations project with stages, customer, dates, estimates, and project context. ERP side Figure 2: The corresponding project structure in Business Central. A Different Way to Look at the Integration Think of It as a Data Pipeline Source entities become mapped entities, mapped entities become ERP records, and ERP records eventually become transactions and financial metrics. How a record moves between the two systems Project Operations projects · tasks · resources → Mapping Layer identity · transformation → Business Central projects · planning lines 01 Plan Estimates, tasks, resources, and planned quantities describe what the project is expected to consume. 02 Execute Time, materials, and expenses create operational evidence of what happened. 03 Bill Billable value moves toward invoicing, turning project activity into commercial output. Entity-to-Entity Mapping Is Where Meaning Gets Preserved One of the most important parts of a Project Operations to Business Central integration is deciding what a source entity becomes in Business Central. The mapping is effectively a semantic contract. Project Operations Business Central Why It Matters Account (Customer) Customer Customer identity must remain consistent across systems Project msdyn_project Project / Job The project becomes the parent financial structure Project Task msdyn_projecttask Project Task / Job Task Task identity is required for planning and transaction attribution Estimate msdyn_estimateline Job Planning Line Planning becomes a structured Business Central financial planning record Time Entry msdyn_timeentry Project Journal Recorded effort can become project usage Figure 3: Account data flowing into Business Central as a customer, carrying its identity across the boundary. Planning Lines Are the Semantic Bridge Planning lines sit at the point where a project plan starts becoming an ERP financial model. In Business Central, planning lines can represent planned cost, billable value, or both, depending on how they are configured. That makes them especially important when explaining the transition from “what we intend to do” to “what the ERP expects this project to cost or generate.” Quantity How much work, material, or resource usage is expected? Unit Cost / Price What cost or commercial rate is associated with the planned quantity? Total Cost / Price The planning line turns quantity and rates into project-level financial expectations. CRM side Figure 4: The work breakdown structure decomposes project work into manageable tasks. ERP side Figure 5: Resource assignments become structured planning lines in Business Central. The Four Numbers People Confuse Most These values answer different questions. Treating them as interchangeable is one of the fastest ways to misread a project dashboard. 01 Budget: What Did We Expect to Spend? Budget represents planned cost. It is a planning value, not proof that the cost has already occurred. 02 Actual: What Cost Was Recorded? Actual (usage) cost is tied to execution and recorded project usage. A blank actual does not mean the budget disappeared; it means no actual usage has been recorded in that context. 03 Billable: What Value Can Be Charged? Billable represents chargeable project value according to the project’s planning and billing configuration. 04 Invoiced: What Has Actually Been Billed? Invoiced is downstream of billable value. A project can have billable value before the corresponding amount has been invoiced. The Simplest Mental Model Budget → Actual answers the cost question. Billable → Invoiced answers the revenue and billing question. Figure 6: Project budgeting concepts in Project Operations (source: Microsoft Learn). Execution Creates the Evidence Once the project moves from planning into execution, operational records begin to tell the story of what actually happened. Time entries, material usage, and expenses are examples of records that contribute to project actuals and downstream ERP transactions. What feeds the project journal Time hours worked + Materials items consumed + Expenses project spend → Project Journal CRM side Figure 7: Time entries recorded against projects and tasks. ERP side Figure 8: Approved time entries represented in the Business Central project journal. Figure 9: Material usage follows the same project-to-ERP transaction path. Engineering Insight An integration should be traceable backwards. If a number appears in an ERP report, you should be able to explain which transaction produced it and which project and task it belongs to. From Project Activity to Invoice The final part of the journey is commercial. Billable project data eventually feeds invoicing, creating a visible chain from planned work to customer-facing financial output. 01 Project Activity Time, materials, expenses, and … Continue reading From Project Operations to Business Central: Following the Data Behind Project Financials →

Summary Project-based organizations often manage project delivery in Microsoft Dynamics 365 Project Operations while relying on Microsoft Dynamics 365 Business Central for finance, purchasing, inventory, and accounting. Without a connected process, project teams and finance teams can end up working with different versions of the same information. CloudFronts built an integration between Project Operations and Business Central using Dataverse plugins. Instead of relying on users to manually recreate records, the integration responds to important Project Operations events and sends the relevant data to Business Central through web services. It covers customers, projects, timesheets, expenses, invoices, and inventory availability, writes the Business Central identifier back to the originating Project Operations record, and captures failed transactions in an Error Log for troubleshooting. Table of Contents The Project Integration Challenge Our Integration Architecture Keeping Project Customers in Sync Connecting Projects to Business Central Synchronizing Timesheets Moving Project Expenses into Finance Connecting Project Invoices End-to-End Project Integration Flow Business Benefits Key Implementation Considerations Frequently Asked Questions Conclusion About the Example in This Post To show how the integration behaves end to end, the screenshots use a sample customer, Westview Ltd, and its project, Westview-Project-003. These are sandbox records used purely to demonstrate the data flow between Project Operations and Business Central. The Project Integration Challenge Project-based businesses have a unique challenge: the people delivering the project and the people managing its financial impact often work in different systems. Project Operations can be the place where project teams manage customers, projects, resources, tasks, time, expenses, and project billing. Business Central, meanwhile, can be responsible for financial management, purchasing, inventory, and other ERP processes. When these systems are not connected, the same project information may have to be entered more than once. A project manager may record time in Project Operations while finance needs the same information in Business Central. A project invoice may be created in one system while the corresponding financial information needs to be reflected in another. The Core Problem Project teams need to work in the system designed for project delivery, while finance needs accurate and timely information in the ERP. Manual re-entry creates extra effort, delays, and opportunities for data inconsistency. The objective of the integration was therefore not simply to move records between two applications. It was to connect the project lifecycle with the corresponding Business Central processes. Our Integration Architecture The integration uses Dataverse plugins as the event-driven layer connecting Project Operations with Business Central. A Dataverse plugin is a piece of C# code that runs when a Dataverse record is created, updated, or otherwise processed. This provides an opportunity to respond to project-related events and send the relevant information to Business Central. High-Level Flow A user creates or updates a project-related record in Project Operations. The corresponding Dataverse event triggers the plugin. The plugin reads the required information from Dataverse. The data is transformed into the structure required by Business Central. The plugin calls the relevant Business Central web service. Business Central creates or updates the corresponding record. The Business Central identifier is written back to the Project Operations record where required. If the request fails, the integration captures the error and the data involved in an Error Log. Why an Event-Driven Approach? The integration reacts when project information changes, instead of depending on users to remember when and where the same information must be entered. Figure 1: High-level architecture of the Project Operations to Business Central integration. Keeping Project Customers in Sync Customers are a fundamental dependency for project processes. Before project transactions can be represented correctly in Business Central, the corresponding customer needs to exist there. When a customer is created or processed in Project Operations, the integration sends the relevant customer information to Business Central. What the Integration Achieves 01 Create or Sync Creates or synchronizes the customer in Business Central. 02 Map the Fields Uses the appropriate source-to-target field mapping. 03 Capture the Number Captures the Business Central customer number. 04 Write It Back Writes the Business Central identifier back to the originating record where required. This creates an important link between the two systems. The Project Operations record retains the Business Central number, so users do not have to search manually for the corresponding ERP record. In our example, Westview Ltd is created as an account in Project Operations. The integration synchronizes it to Business Central and writes the resulting Business Central customer number (C00280) back onto the Project Operations record. Figure 2: Westview Ltd in Project Operations, with the Business Central customer number (C00280) written back to the int_sourceid field. Figure 3: The corresponding Westview Ltd customer record (C00280) synchronized into Business Central. Connecting Projects to Business Central Customer synchronization is only the beginning. The central object in a project-based integration is the project itself. When a project is created or prepared for synchronization, the integration retrieves the project information required by Business Central and creates the corresponding project record. It then maintains the relationship between the Project Operations project and the Business Central project using the relevant identifiers. Why Project Identifiers Matter A Project Operations record may contain Dataverse identifiers and lookup references, while Business Central works with its own project numbers. These identifiers cannot simply be assumed to be interchangeable. The integration needs to resolve the correct project identifier and use it when subsequent project-related transactions are sent to Business Central. Project Integration Principle Synchronizing a project is not only about copying project fields. It establishes the reference that later transactions, such as time, expenses, materials, and billing, use to reach the correct Business Central project. Continuing the example, Westview-Project-003 is created under Westview Ltd in Project Operations. The integration creates the matching project in Business Central and writes the Business Central project number (PR00340) back to the int_sourceid field on the Project Operations record. Figure 4: Westview-Project-003 in Project Operations, with the Business Central project number (PR00340) written back to int_sourceid. Figure 5: The corresponding Project Card (PR00340) for Westview-Project-003 in Business Central. Synchronizing Timesheets Time is one … Continue reading How to Integrate Dynamics 365 Project Operations with Business Central Using Dataverse →

01Summary Project-based businesses often run their projects in Dynamics 365 Project Operations and their finance in Dynamics 365 Business Central. The two systems do not talk to each other out of the box, so every customer, project, timesheet, expense and invoice ends up being typed into both, and the numbers finance reports on are always a step behind the project teams. CloudFronts built an integration that closes this gap using Dataverse plugins: small pieces of C# code that run inside Project Operations every time a record is saved. When someone creates a customer, sets up a project, approves a timesheet or confirms an invoice, the plugin sends that record straight to the matching Business Central web service and writes the Business Central number back onto it. Before material is used on a project, it looks up how much stock Business Central holds at that location. Anything that fails is saved in an Error Log with the exact data that was sent. To keep the examples concrete, this post follows a sample scenario: Wexford County Council orders a satellite broadband installation at its Castlemoyle and Bunclody water treatment sites, and the project runs from the first lead to the final invoice across both systems. Table of Contents 01Summary→ 02Business Challenges→ 03Solution Overview→ 04Technical Approach→ 05Business Impact→ 06Conclusion→ 02Business Challenges Project Operations and Business Central each work well on their own. The trouble is the gap between them: nothing entered in Project Operations reaches Business Central unless someone types it in again. Without an integration, teams run into the same problems: Everything is entered twice. A new customer or project is created in Project Operations, then created again in Business Central. Every later change has to be repeated by hand. Master data drifts apart. Countries, postcodes, currencies, payment terms, dimensions and work types have to match in both systems. When one side changes and the other does not, records fail to post. Approved work reaches finance late. Approved timesheets, expenses and material only arrive in Business Central after someone exports and imports them, so project costs in finance are always behind. Material is used without checking stock. Site teams log material against a project without knowing whether Business Central actually has it at that location. Invoices are keyed twice. A confirmed project invoice has to be rebuilt in Business Central, line by line, before finance can post it. Errors are hard to trace. When a record does not match, nobody can see what was sent or why Business Central rejected it. 03Solution Overview CloudFronts built one main plugin, RequestProcessor, and registered it on every Project Operations table that finance needs. Two small helper plugins handle the stock check for material. Whenever one of those records is created, updated or deleted, Dataverse runs the plugin. The plugin works out which table the record came from, turns it into the shape Business Central expects, and sends it to the matching Business Central web service. When Business Central replies, the plugin stores the Business Central number on the Project Operations record, such as the BC customer number or the project code. Next time the record changes, the plugin uses that number to update the same record in Business Central instead of creating a new one. All the settings the plugin needs, such as where to sign in, which web service to call for each table, and which user is the integration user, live in a single Integration Configuration record in Dataverse. Moving from a test company to the live one is a change to that record, not to the code. ⓘKey terms, in plain words Dataverse plugin: C# code that Dataverse runs automatically when a record is saved, like a trigger in a database. Business Central web service: an address in Business Central that accepts records from other systems, one for customers, one for projects, and so on. Project Journal: where costs are recorded against a project in Business Central before they are posted. Project Planning Lines: the budget of a project in Business Central. ⓘWhy a plugin instead of Power Automate? A cloud flow could copy simple records, but this integration covers 20 tables with detailed mapping rules for each one. In a plugin, that logic lives in one C# project that can be versioned, reviewed and tested like any other code. The plugin runs the moment the record is saved, only on the tables and messages it is registered for, and it ships in the same Dataverse solution as the rest of the Project Operations customisation. 04Technical Approach How It Works Every save takes the same path through the plugin: A record is saved in Project OperationsFor example, the project manager approves a week of time entries on the Wexford County Council broadband project. RequestProcessor loads its settingsIt reads the Integration Configuration record. If the record is missing, the plugin stops quietly instead of failing the user’s save. It skips its own changesIf the record was last modified by the integration user, the plugin stops. This keeps it from running again on the Business Central number it has just written back. The handler for that table maps the recordIt checks the record’s status, so only approved entries or confirmed invoices go further, and copies the fields into the JSON shape Business Central expects. Business Central creates or updates the recordPOST creates a new record; PUT updates the one already linked by its Business Central number. The result is savedOn success, the Business Central number is written back onto the Project Operations record. On failure, an Error Log record is created with the details. What Moves Between the Systems The plugin handles 20 Project Operations tables. They fall into five groups, in the order a project normally runs. Group Saved in Project Operations Created in Business Central When It Is Sent Customers Account Customer, or Vendor when the account type is Vendor Create and update; a delete blocks the record in BC instead of removing it Customers Contact Contact Create, update and delete … Continue reading How We Built a Project Operations to Business Central Integration Using Dataverse Plugins →

Summary Most project businesses we work with have the same quiet problem. The project team plans and tracks work in Dynamics 365 Project Operations. The finance team bills, buys and closes the books in Dynamics 365 Business Central. Everything the project team decides has to be typed again by finance. The two teams spend their week checking each other’s numbers. At CloudFronts we closed that gap with plugins: small automatic helpers that sit inside Project Operations and act the moment someone saves a record. When a project, a plan, a timesheet or an invoice is saved, the helper creates the matching record in Business Central and writes the Business Central reference back on the project. This integration is available as the PO-BC Integration Module 2.0 on Microsoft Marketplace. To show how this works in practice, we ran a real example through our demo environment: CloudFronts – Smart Office Rollout, Mumbai, a short project to fit out a new office floor. Every screenshot in this post comes from that one project. Table of Contents Summary→ Business Challenges→ The Idea in Plain Words→ Walkthrough: The Mumbai Office Rollout→ What Moves, and When→ The Safety Nets→ What We Learned Building It→ Business Impact / Key Takeaways→ Questions We Get Asked→ Conclusion / Final Thoughts→ Call to Action / Connect With Us→ Business Challenges Picture the Mumbai office rollout without any connection between the two systems. Monday. The project manager sets up the project, splits it into four tasks and plans 104 hours of work in Project Operations. Finance is told about it in an email. Tuesday. Finance creates the same project in Business Central, retypes the four tasks, and builds a budget from a spreadsheet the project manager sent over. One task name is spelt differently. Nobody notices. Wednesday. The plan changes: cabling needs an extra day. Project Operations is updated. The budget in Business Central is not. Thursday. Twenty desks are taken from the warehouse for the new floor. The site team records it in Project Operations. Business Central still believes the desks are on the shelf. Friday. Finance asks why the project margin looks wrong. Two people spend the afternoon comparing screens. None of this is anyone’s fault. Each system is doing its job. They just do not talk to each other. The Idea in Plain Words A plugin is a small piece of code that lives inside Project Operations and wakes up at a specific moment, for example when a project is saved or a timesheet is approved. Ours does three things each time it wakes up: It reads what just changedThe project name, the customer, the task, the hours, the item and quantity: whatever finance would otherwise have to retype. It creates or updates the same record in Business CentralIt signs in to Business Central with its own dedicated account, not a person’s login, so it keeps working when people change roles or leave. It writes the answer backBusiness Central replies with its own reference, such as a project number or an invoice number. That reference is saved on the Project Operations record, so both teams can always find the matching record in the other system. 💡Why a plugin and not a scheduled sync? A scheduled sync runs every hour or every night and moves whatever has changed. A plugin acts on the exact save, so Business Central is updated within seconds, and only the record that changed is sent. It is also packaged with the rest of the Project Operations setup, so moving it from the test system to the live one is a single, repeatable step. Walkthrough: The Mumbai Office Rollout Here is the same week again, this time with the integration switched on. The customer is CloudFronts Technologies, already known to Business Central as customer C00310. The work is 40 new workstations, meeting-room screens and office Wi-Fi. The customer account, integrated to Business Central with its customer number sent back. Step 1: The Project Manager Creates the Project, Once The project manager creates the project in Project Operations with a name, the customer, a start date of 12 October and a finish date in December. The project code is left blank because nobody knows it yet. A few seconds after saving, the code J00700 appears in the Project Code field. That number came back from Business Central. The project integrated to Business Central. The project code J00700 was filled in automatically. Step 2: The Tasks Follow The project manager adds four tasks in the project plan: Site Survey and Floor Plan, Network Cabling and Wi-Fi, Workstation and Screen Installation, and Testing and Handover. Each one is created under project J00700 in Business Central with the same name and dates, numbered 1272 to 1275. Finance did not open anything. Step 3: The Plan Becomes the Budget Next, the project manager assigns a named person to each task: 16 hours for the survey, 40 for cabling, 32 for installation and 16 for testing and handover. The integration turns that plan into budget lines in Business Central, one line per working day per person, so finance sees not only how much work is planned but when it falls. Weekends are skipped automatically. Resource assignments from Project Operations, turned into daily planning lines in Business Central. ⓘWhy one line per day? A single line of "104 hours" tells finance the total but nothing about timing. Daily lines let finance see cost landing in October versus November, which matters at month end. If the plan changes, the same lines are updated, not duplicated. Step 4: Real Work and Real Material Arrive as Actuals On 12 October, the consultant logs a day on the site survey: "Walk-through of the new floor; desk layout and cable routes agreed with facilities." A week later, the site team records 20 ATHENS desks taken from the Main Warehouse for the installation task. The integration does not send rough drafts. Time and material only go to Business Central once they are submitted for approval, and the … Continue reading No More Retyping: How We Connected Project Operations and Business Central with Plugins →

Please find this CloudFronts Product at – Integration Module between Dynamics 365 Project Operations and Finance & Operations | Microsoft Marketplace Summary Manually creating custom fields in Dynamics 365 Project Operations across multiple environments is time-consuming, error-prone, and blocks automation. This challenge can be addressed by using Dataverse Metadata OData APIs to programmatically create, update, and publish custom attributes during deployment. The process involves authenticating with Azure AD, calling Metadata API endpoints to create attributes, and publishing the changes with the PublishXml action, all through a fully automated approach. As a result, organizations achieve zero manual intervention, environment consistency, integrations, reduced human error, and a reusable framework that can be applied across all field types. Please find this CloudFronts Product at – CloudFronts – PO-FO Connector Table of Contents Introduction Business Challenge Why OData Metadata APIs? Implementation Procedure End-to-End Working Why This Approach Works Real-World Use Cases Conclusion Introduction When integrating external business applications with Microsoft Dynamics 365 Project Operations, it is common to discover that every customer requires additional fields to store information originating from ERP systems, manufacturing platforms, pricing engines, or product lifecycle management systems. For one of our internal projects & Prospect PoC implementing product-centric integrations, we needed a way to provision these custom fields automatically during deployment. Traditionally, creating new columns involves opening the Power Apps Maker Portal, adding fields manually, publishing the table, exporting a solution, and repeating the same process across multiple environments. While this approach works for occasional changes, it quickly becomes a bottleneck for automated deployments and CI/CD pipelines. The Solution: CloudFronts implemented a fully automated approach using the Dataverse Metadata OData APIs, enabling integration deployments to create and publish new Project Operations attributes programmatically. Business Challenge The customer’s integration platform exchanged large volumes of product and financial information with Dynamics 365 Project Operations. Each deployment required several custom attributes such as: Product identifiers ERP reference numbers Financial synchronization IDs External integration keys Processing status fields Creating these fields manually across Development, Test, UAT, and Production introduced several challenges: Manual configuration effort (time-intensive) Human errors (typos, misconfigurations) Environment inconsistencies (field variations across environments) Longer deployment windows Difficult CI/CD automation The Objective: Allow the deployment process itself to provision any missing attributes before importing data, eliminating manual touchpoints entirely. Why OData Metadata APIs? Most developers use the Dataverse Web API for CRUD operations on business records. However, Dataverse also exposes Metadata APIs, allowing developers to programmatically manage the schema itself—including tables, columns, relationships, and option sets. Microsoft documents creating attribute metadata by posting to the Attributes navigation property of an entity definition. This means integrations can: Create new columns dynamically Update existing metadata Publish customizations instantly Eliminate manual portal work Scale across multiple environments consistently Unlike traditional manual solutions, the Metadata API approach is fully programmable, auditable, and repeatable. Implementation Procedure Step 1 – Authenticate with Dataverse The integration first authenticates against Azure Active Directory using an application registration and retrieves an OAuth Bearer Token. That token is then supplied with every Metadata API request. Authentication Flow: Register application in Azure AD Configure permissions for Dataverse access Obtain OAuth 2.0 Bearer Token Include token in Authorization header for all API calls Step 2 – Creating a Custom Attribute The Dataverse Metadata API exposes the following endpoint for creating new attributes: POST /api/data/v9.2/EntityDefinitions(LogicalName=’msdyn_contractlineinvoiceschedule’)/Attributes Instead of creating business records, this endpoint creates metadata at the schema level. For this implementation, we created a new string attribute with the following properties: Schema Name: int_fnoid Display Name: FNO ID Data Type: String Maximum Length: 100 The request body uses the Microsoft.Dynamics.CRM.StringAttributeMetadata type together with standard metadata properties such as SchemaName, DisplayName, RequiredLevel, and MaxLength. Supported Metadata Types: Microsoft supports multiple metadata types through the same endpoint including String, Decimal, Boolean, Picklist, DateTime, Lookup, Currency, and more. Step 3 – Publishing the Metadata Creating an attribute does not immediately make it available. Like changes made through the Power Apps Maker Portal, metadata created through the Web API must also be published. This is accomplished using the PublishXml action. POST /api/data/v9.2/PublishXml The request specifies the entity to publish. After publishing completes successfully, the new attribute immediately becomes available throughout Dynamics 365. End-to-End Working The complete deployment process follows these steps: Integration authenticates with Azure AD. Dataverse access token is generated. Metadata API checks whether the required attribute exists. Missing attributes are created automatically. PublishXml is executed. New attributes become available. Product synchronization begins. External systems start populating the new fields immediately. Integration Points: This Attribute creation setup can be utilized across Logic Apps, Plugins, Azure Functions, and other Custom Workflows. Why This Approach Works ✓ Fully Automated Deployments No manual intervention is required when new integration fields are introduced. ✓ Environment Consistency Development, Test, UAT, and Production remain synchronized because every environment provisions the same metadata through code. ✓ CI/CD Friendly Metadata creation can be incorporated directly into Azure DevOps or GitHub deployment pipelines. ✓ Reusable Framework The same framework can create String, Decimal, Currency, Lookup, Date, Option Sets, and Boolean fields. ✓ Reduced Human Error Eliminates mistakes caused by manual customization and inconsistent naming conventions. ✓ Prevented Duplication Eliminates duplication of records, preventing system garbage in the database. Real-World Use Cases Use Case 1: PO-FO Integration (Project Operations to Finance Operations) For enterprises running integrated Project Operations and Finance Operations modules, this approach ensures that: ERP reference numbers sync automatically across all linked tables Financial synchronization IDs are created before data import External integration keys propagate consistently Processing status tracking fields exist in all dependent entities No manual re-entry of attribute definitions across environments Impact: Reduces deployment time from hours to minutes, eliminates sync mismatches between PO and FO modules, and enables real-time data reconciliation. Conclusion For an internal project and prospect PoC implementing product-centric integrations, automating metadata creation transforms what was previously a manual administrative task into a repeatable deployment process. Rather than relying on solution imports or manual customization through the Power Apps Maker Portal, integrations can now provision required Project Operations attributes on demand … Continue reading Automating Attribute creation in D365 Project Operations, Using Dataverse OData Metadata APIs for an Internal Project Operations–Finance & Operations Integration →

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 →

Blogger CloudFrontsbloggerEdit Profile Summary Expense management processes in enterprise project environments often require strict documentation controls to ensure financial accuracy and compliance. One common requirement is the mandatory attachment of receipts when submitting expense entries, especially for specific expense categories such as airfare, accommodation, or high-value reimbursements. My blog describes how a project-driven organization streamlined its expense submission workflow using Canvas Apps integrated with Dynamics 365 Project Operations. The solution I had implemented automates the validation and submission process for expense entries while ensuring that receipt files are attached before submission. By combining form validation logic in the Canvas App with backend automation using Power Automate, the organization eliminated the manual process of attaching receipts and creating notes in the system. The result was a seamless, user-friendly expense submission experience that enforces compliance while significantly improving operational efficiency. Table of Contents 1. Customer Scenario 2. Solution Overview 3. Understanding the Expense Data Structure 4. Canvas App Validation Logic 5. Expense Creation and Submission Process 6. Automating Receipt Handling with Power Automate 7. Enforcing Mandatory Receipts for Specific Categories 8. Business Impact 9. Solution Walkthrough 10. Final Thoughts 1. Customer Scenario A Texas based Cyber Security organization managing multiple client engagements relied on Dynamics 365 Project Operations to track project expenses incurred by consultants and field staff. While the system allowed users to create draft expense entries, the process of submitting those expenses required additional manual steps. To submit an expense, users had to: Create the expense entry in draft mode. Upload the supporting receipt manually. Navigate to the expense record. Create an associated Expense Receipt record. Attach the receipt file under Notes (Annotations). Convert the file into the required document format stored in the system. Update the expense status to Submitted. This workflow introduced several challenges: Users frequently forgot to attach receipts. Manual creation of Notes records was error-prone. Finance teams had to follow up for missing documentation. Expense approvals were delayed due to incomplete submissions. Employees found the process unnecessarily complex. The organization needed a simpler, controlled way to ensure receipts were always attached when expenses were submitted, without requiring users to understand the underlying system structure. 2. Solution Overview To address these challenges, a custom expense submission experience was built using Canvas Apps integrated working in conjunction with D365 Project Operations. The solution introduced a dynamic expense entry submission interface where users can: Create expense entries Upload receipt files Submit expenses directly from the app Figure: Canvas App interface enabling dynamic expense entry submission with receipt attachment. Figure: Canvas App interface enabling dynamic expense entry submission with receipt attachment. Behind the scenes, the application automatically: Creates the expense entry in Dataverse Generates the related Expense Receipt record Uploads the receipt file to Notes (Annotations) as a document Updates the expense status to Submitted Figure: A Submitted Expense Entry Record. Figure: The Expense Receipt Record + Receipt PDF Annotation associated with the Expense, without which Submission won’t have been possible. This automation completely overrides the manual procedure of attaching receipts and creating notes, ensuring the process is both compliant and seamless for users. 3. Understanding the Expense Data Structure Within Dynamics 365 Project Operations, expense documentation follows a structured relationship model. The hierarchy looks like this: Expense ↓ Expense Receipt ↓ Notes (Annotation) ↓ Blob/Base64 File Storage of Expense Receipt. Figure: Implementation of the Expense Entry -> Expense Receipt -> Annotation -> Receipt File Workflow. In this structure: The Expense record stores the financial transaction. The Expense Receipt record acts as a container for receipt documentation. The Notes (Annotation) entity stores the actual file. The receipt file is stored as Base64 binary data (blob). While this structure is technically sound, it requires multiple manual steps when performed directly by users. The custom Canvas App abstracts this complexity and handles it automatically. 4. Canvas App Validation Logic To ensure all required data is captured before submission, the Canvas App includes dynamic validation logic. The application checks whether essential fields are populated before allowing the expense to be saved or submitted. These validations include fields such as: Transaction Date Project Expense Category Reimbursable Indicator External Comments Unit Quantity Unit Price If any required field is missing, the user receives an immediate notification explaining what needs to be completed. Example logic used in the application: If( Or( IsBlank(DatePicker2_5.SelectedDate), IsBlank(Project_Combobox_5.Selected), IsBlank(ExpenseCategory_Combobox.Selected), IsBlank(Dropdown1.Selected.Value), IsBlank(External_Input_7.Text), IsBlank(Project_Combobox_6.Selected), IsBlank(NumberInput2.Value), IsBlank(NumberInput2_1.Value) ), Notify(“Required fields are missing.”, NotificationType.Error) ) This validation ensures data completeness before the expense record is created. 5. Expense Creation and Submission Process Once validation passes, the Canvas App uses a Dataverse Patch operation to create or update the expense record. The logic dynamically calculates financial values such as the subtotal based on quantity and unit price. Example logic: Set( varSavedExpense, Patch( Expenses, Defaults(Expenses), { ‘Transaction Date’: DatePicker.SelectedDate, Project: Project_Combobox.Selected, ‘Expense Category’: ExpenseCategory_Combobox.Selected, Quantity: Value(NumberInputQuantity.Value), ‘Unit Price’: Value(NumberInputPrice.Value), Subtotal: Value(NumberInputQuantity.Value) * Value(NumberInputPrice.Value) } ) ); ‘SubmitExpense(CanvasApp)’.Run( varSavedExpense.Expense, First(fileupload.Attachments).Name, First(fileupload.Attachments).Value ); Notify( “Expense submitted successfully.”, NotificationType.Success ) This creates the draft expense entry in the system. 6. Automating Receipt Handling with Power Automate After the expense entry is saved, the Canvas App triggers a Power Automate flow. The flow receives: Expense record ID File name Receipt file content The flow then performs the following steps automatically. Step 1: Create Expense Receipt Record A new Expense Receipt record is created and linked to the expense entry. Step 2: Upload Receipt as Note The receipt file is stored as a Note (Annotation) associated with the expense receipt. This note contains: File Name Document Type Base64 encoded file content MIME type Step 3: Update Expense Status Finally, the expense record status is updated from Draft to Submitted. This ensures the expense becomes available for approval workflows and financial processing. 7. Enforcing Mandatory Receipts for Specific Categories An important requirement D365 PO is ensuring that certain expense categories cannot be submitted without receipts. Examples include: Airline tickets Travel expenses Accommodation High-value reimbursements The Canvas App logic ensures that a receipt file must be attached before submission is triggered. If the … Continue reading Dynamic Expense Entry Submission with Receipt Attachments in Power Apps: A Practical Implementation for a Texas-Based Operational Technology Security Organization →

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 →

Summary Implemented Markdown-based formatting standards for Power Automate Approval Requests at a Texas-based Operational Security Provider. Transformed plain-text approval emails into structured, executive-friendly approval experiences. Improved readability through headers, sections, tables, lists, hyperlinks, and emphasis formatting. Reduced approver effort by presenting key business information in a consistent and easily consumable format. Leveraged native Power Automate Approval Markdown capabilities without requiring custom development. Improved approval turnaround times by making critical information easier to review and approve. Table of Contents Introduction The Business Problem The Solution Using Headers for Section Separation Using Line Breaks and Paragraphs Using Bullet Lists for Business Information Using Numbered Lists for Approval Steps Using Nested Lists for Additional Context Using Tables for Approval Summaries Using Hyperlinks for Record Navigation Using Emphasis for Important Information Escaping Special Characters Building a Structured Approval Request Limitations Business Impact FAQs Conclusion 1. Introduction In Microsoft Dynamics 365 Project Operations, quotes represent a critical milestone in the sales lifecycle. Before a quote can be activated and progress toward project execution, organizations often require review and approval controls to ensure pricing accuracy, contractual compliance, and business alignment. Since Quote Review & Approval is not a standard capability within Dynamics 365 Project Operations, this requirement typically requires customization. For a Texas-based Operational Security Provider, the requirement extended beyond a simple approval process. The organization needed a controlled workflow where only designated business leads associated with a specific Opportunity or Quote could generate, submit, and approve customer quotations, ensuring accountability and governance throughout the approval chain. A custom approval framework was developed using Microsoft Power Automate and Dynamics 365 Project Operations to automatically identify approvers and route quotes through the required approval process before activation. While the workflow successfully enforced the necessary business controls, the approval requests themselves were difficult to review. Critical information such as customer details, quote values, approval notes, and record links were presented as plain text, making approvals slower and less efficient. To improve the approver experience, Markdown formatting was introduced within Power Automate Approval Requests. Using structured headers, tables, hyperlinks, emphasis formatting, and organized sections, approval notifications became significantly more readable and actionable across Outlook, Outlook Web, and Power Automate approval channels. This article focuses on how Markdown was used to transform standard approval request bodies into professional, executive-friendly approval experiences that improved readability, reduced approval effort, and accelerated quote approval decisions. 2. The Business Problem The organization manages a high volume of customer opportunities and project-based engagements, where quotes serve as the commercial foundation for service delivery. Before a quote could be activated and converted into an operational project, it needed to undergo a formal review and approval process involving designated business stakeholders. To support this requirement, a custom quote approval workflow was implemented within Dynamics 365 Project Operations and Power Automate. The workflow successfully enforced business rules, ensured only authorized personnel could submit and approve quotes, and provided the necessary governance around pricing and customer commitments. However, a significant usability challenge emerged during adoption. The approval requests being sent to approvers contained all the required information, but the content was presented as large blocks of plain text. As quote complexity increased, approvers found it difficult to quickly identify key details such as: Customer Name Opportunity Information Quote Number Total Quote Value Requested Approval Type Business Justification Requestor Information Direct Links to Dynamics 365 Records This often forced approvers to spend additional time reviewing approval requests or navigating back into Dynamics 365 to locate information that should have been immediately visible within the approval notification itself. The lack of visual structure created several operational challenges: Slower approval turnaround times Increased requests for clarification Inconsistent user experience across approval requests Difficulty identifying critical information at a glance Reduced executive engagement with approval emails Higher likelihood of approval delays for time-sensitive opportunities The business needed a way to present approval information in a format that was clear, professional, and easy to consume without requiring additional custom applications or significant development effort. The Objective: Transform approval requests from plain-text notifications into structured, decision-ready approval experiences that allowed stakeholders to review and act on quote approvals quickly and confidently. 3. The Solution One important limitation of the Power Automate Approval action is that it does not support custom HTML rendering within approval request bodies. Unlike standard email notifications where HTML templates can be used extensively, Approval actions rely on a restricted rendering engine that supports a subset of Markdown syntax. As a result, many approval requests are delivered as large blocks of plain text, making them difficult to review, especially when multiple business details need to be presented to approvers. To improve readability without introducing custom applications or alternative notification mechanisms, the approval request body was redesigned using Power Automate’s native Markdown capabilities. This approach allowed approval requests to be structured into clearly defined sections, highlight important information, provide direct navigation links, and present approval summaries in a more professional format. 3.1 Using Headers for Section Separation Headers are one of the simplest ways to introduce structure into approval requests. Syntax # Main Heading ## Section Heading ### Subsection Heading Example # Quote Approval Request ## Opportunity Information ## Financial Summary ## Approval Notes Headers create visual separation between different parts of the approval request and help approvers quickly locate relevant information. 3.2 Using Line Breaks and Paragraphs Approval requests often contain multiple fields and explanatory comments. Proper spacing prevents information from appearing crowded. Syntax Line One Line Two Or force a new line using two trailing spaces: Line One Line Two Example Requested By: John Smith Department: Operations Approval Required Before Quote Activation Proper spacing significantly improves readability compared to continuous blocks of text. 3.3 Using Bullet Lists for Business Information Bullet lists are useful when presenting multiple approval considerations, requirements, assumptions, or supporting notes. Syntax – Item One – Item Two – Item Three Example ### Key Considerations – Executive review required – New customer engagement – Pricing exception applied – Legal review completed Bullet lists allow approvers to scan … Continue reading Enhancing Power Automate Approval Experiences with Markdown Formatting for a Texas-Based Security Operations Firm →

How We Built a Real-Time Lightweight Financial Statement Reporting Experience Directly Inside Microsoft Dynamics 365 Project Operations Summary Designed and deployed a lightweight, real-time financial statement reporting solution directly inside Microsoft Dynamics 365 Project Operations for a Texas-based Cybersecurity & AI Business Solutions firm. Eliminated dependency on heavy paginated reporting and large-scale Power BI datasets for operational financial visibility. Built an interactive HTML + JavaScript reporting framework embedded natively within Dynamics 365 CRM. Enabled dynamic filtering, instant report rendering, and printable customer-ready statements directly from the CRM interface. Introduced popup-based full-screen report rendering for detailed review and print-ready output without leaving Dynamics 365. Integrated funding balances, allocations, transactions, installment schedules, and financial snapshots into a single operational reporting experience. Reduced reporting development complexity, minimized data transformation overhead, and improved scalability compared to traditional BI-heavy architectures. Created a highly maintainable reporting model that scales efficiently as operational datasets grow without introducing significant Power BI licensing or performance constraints. Table of Contents Introduction The Business Problem The Solution Architecture Real-Time CRM-Native Reporting Lightweight Front-End Reporting Framework Popup-Based Printable Report Experience Data Model and Reporting Components Design Principles Business Impact Why This Approach Worked FAQs Conclusion 1. Introduction As organizations scale, operational reporting often becomes increasingly difficult to maintain. For a Texas-based Cybersecurity & AI Business Solutions firm operating on Microsoft Dynamics 365 Project Operations, this challenge became especially visible in financial agreement tracking and customer funding visibility. The business already had access to reporting platforms such as Power BI and paginated reports. However, these approaches introduced several operational problems: Long development cycles Heavy data-cleaning requirements Complex transformation pipelines Delayed visibility into operational data Increasing licensing costs as datasets expanded Slow report rendering for operational users Dependency on external reporting infrastructure Instead of another external BI layer, the organization wanted a lightweight operational reporting experience directly inside Dynamics 365 CRM itself. The Goal: Build a real-time, CRM-native financial reporting experience that renders instantly, supports dynamic filtering, enables printing, and scales without heavy BI infrastructure. 2. The Business Problem The organization manages multiple long-running service agreements, funding allocations, installment schedules, and customer financial balances across cybersecurity services, managed services, and AI solution engagements. Operational users needed a consolidated statement experience that could answer questions such as: What is the customer’s current available balance? Which transactions impacted the balance during a selected period? Which allocations are currently active? How much funding has been consumed vs allocated? Which installments are pending, paid, or overdue? What does the latest funding snapshot look like? Can the report be reviewed and printed directly from CRM? Paginated Reporting Limitations Increasing query complexity Performance degradation with larger datasets Heavy formatting maintenance Limited interactivity Rigid deployment cycles Power BI Challenges Significant Power Query transformations Data-cleaning pipelines Incremental refresh considerations Dataset refresh latency Licensing growth with scale Overengineering for transactional operational reporting 3. The Solution Architecture The reporting framework was designed as a native Dynamics 365 embedded reporting experience using: HTML Web Resources JavaScript Dynamics 365 Web API Native CRM navigation APIs Real-time entity retrieval Popup-based print rendering Embedded Operational Report Apply filters Select funding records Choose reporting periods Generate statements instantly Navigate operational financial data Popup Print Report Detailed review Executive presentation Customer-facing statements Printing and PDF generation 4. Real-Time CRM-Native Reporting One of the most important architectural decisions was avoiding external data replication entirely. Instead of pushing transactional data into a separate reporting warehouse, the report retrieved data directly from Dynamics 365 using the native Web API. Real-time visibility Zero synchronization lag Reduced infrastructure complexity Lower maintenance overhead Faster deployment cycles Everything rendered on demand inside the CRM session itself. 5. Lightweight Front-End Reporting Framework The reporting experience was intentionally designed to behave more like a modern application than a traditional report. Dynamic Filter Bar Users could dynamically filter reports using: This Month Last Month This Quarter Current Year Custom Date Ranges Funding Status Funding Selection The report regenerated instantly without page reloads. Responsive Report Rendering The reporting layout dynamically populated: Account Summary Transaction Details Allocation Summary Installment Details Detailed Account Summary Each section rendered independently based on live API responses. Intelligent Empty-State Handling Instead of showing blank tables or errors, the framework displayed contextual empty-state messaging such as: “No transactions during this statement period” “No active allocations” “No installment details available” This significantly improved usability for operational teams. 6. Popup-Based Printable Report Experience A major requirement was enabling users to thoroughly review and print reports directly from CRM. To solve this, the solution introduced a dedicated popup rendering architecture. Users could click: “Expand Report” This launched a fullscreen popup using Dynamics 365 navigation APIs with: Large-format rendering Print-optimized layout Full customer statement formatting Multi-page support Consistent branding Printable tables Customer reference guides The popup approach delivered several advantages: Better readability Cleaner print formatting Improved executive review experience Isolation from CRM form clutter Easier PDF generation Most importantly, the popup still worked entirely against live CRM data. 7. Data Model and Reporting Components The report consolidated multiple operational areas into a single experience. Account Summary Provided a high-level balance overview including: Balance Forward Total Credits Total Debits Closing Balance This gave immediate visibility into customer financial standing. Transaction Details Displayed detailed running balance activity including: Document date Transaction description Service type Credits Debits Running balance Transactions dynamically recalculated balances during rendering. Allocation Summary Tracked funding allocation activity including: Allocated funds Consumed funds Remaining balance Allocation status Returned allocations were handled separately with custom date logic. Installment Tracking Displayed installment lifecycle visibility including: Invoice dates Due dates Payment dates Payment terms Installment status The report intelligently handled future-dated payments and pending statuses. Detailed Funding Snapshot Displayed operational funding metrics including: Starting Balance Contracted Funds Total Budgeted Funds Collected Funds Used Funding Available Funds Allocated Funds Unallocated Funds This created a complete operational funding overview within a single screen. 8. Design Principles Several architectural principles guided the solution. Real-Time Over Batch Processing Operational reporting should reflect current business activity immediately. The solution avoided overnight refresh cycles entirely. Lightweight Over Heavy BI Not … Continue reading How We Built a Real-Time Lightweight Financial Statement Reporting Experience Directly Inside D365 PO for a Texas-Based Cybersecurity Firm →