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 →

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 →

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

Summary A Houston-based cybersecurity firm eliminated report failures (~65%) by replacing SSRS with an Azure Function App pipeline. Dynamics 365 bound action ensured authentication stayed internal, bypassing Defender-related token failures. Integrated Power Pages, Power Automate, Dynamics 365, and Azure Functions for real-time PDF generation. Report generation time reduced from 3–8 minutes to under 15 seconds with zero infrastructure overhead. Table of Contents 1. About the Customer 2. The Challenge 3. The Solution 4. Technical Implementation 5. Business Impact 6. FAQs 7. Conclusion 1. About the Customer The client is a technology consulting and cybersecurity services firm based in Houston, Texas. They manage multiple concurrent client engagements using Dynamics 365 Project Operations as their core platform. Project managers and clients access live project data through a customer-facing portal built on Microsoft Power Pages. 2. The Challenge The organization needed one-click downloadable Project Status Reports from their Power Pages portal covering risks, issues, logs, and timelines. Their SSRS-based solution failed frequently due to authentication breakdowns caused by Microsoft Defender for Cloud Apps across multiple service boundaries. Key pain points: Silent authentication failures with no clear errors Retry delays of 60–90 seconds per attempt Separate SSRS infrastructure dependency Slow report customization cycle Project managers avoided generating reports during live meetings due to reliability concerns. 3. The Solution At Cloudfronts, while working on this project, I replaced the SSRS pipeline entirely with a synchronous, serverless architecture that keeps the authentication context inside the Dynamics 365 service layer. Technologies Used: Dynamics 365 Project Operations Power Pages Power Automate Plugins Azure Function Apps The solution generates fully formatted PDFs in real time using structured JSON payloads. This eliminated authentication failures while significantly improving speed and reliability. 4. Technical Implementation 1] Power Pages Button triggers Flow A “Download Report” button captures the project GUID and triggers a Power Automate flow with real-time progress feedback. 2] Dynamics 365 Plugin prepares JSON payload A bound action plugin retrieves all project data and converts it into a clean JSON payload for PDF generation. 3] Azure Function generates PDF The Azure Function processes the JSON and generates a formatted PDF, returning it as a Base64 string. 4] SharePoint Integration The generated PDF is automatically stored in the associated SharePoint document location linked to the project. This ensures centralized document management, version control, and easy access for stakeholders directly within the project workspace. 5] Portal PDF Preview The Base64 PDF is rendered directly in the portal using an iframe, allowing instant preview and download. Video: End-to-end implementation of real-time PDF report generation. 5. Business Impact 100% success rate — zero failures post deployment Under 15 seconds report generation time No infrastructure — fully serverless Zero authentication failures Faster iteration for report updates Project managers can now confidently generate reports during live client meetings. 6. FAQs Why not fix the SSRS authentication issue instead of replacing SSRS entirely? The authentication failures were a structural consequence of traversing multiple service boundaries in an environment with strict Defender for Cloud Apps session policies. Fixing them would have required either relaxing those policies — which the client’s security posture did not permit — or re-architecting the data retrieval to stay inside the platform, which is exactly what the bound action approach achieves. Replacing SSRS also removed a separate infrastructure dependency and gave the client full control over report formatting in code. Can this pattern be reused for other document types in Dynamics 365? Yes. The Azure Function App’s renderer is data-driven — it consumes a JSON payload and builds tables from whatever keys are present. The Dynamics 365 plugin can be adapted to query any entity and produce an equivalent payload. CloudFronts has applied the same pattern to inspection records, summary reports, and client-facing status documents across Professional Services and Manufacturing implementations. Does this work for environments without Microsoft Defender for Cloud Apps? Yes. The architectural benefits — synchronous generation, serverless PDF rendering, no SSRS infrastructure, and in-browser preview — apply regardless of the security layer on the environment. 7. Conclusion Replacing SSRS with an Azure Function App-based PDF renderer resolved both the reliability and authentication problems in a single architectural shift, delivering instant, professional-quality Project Status Reports from a Microsoft Power Pages portal with no legacy reporting infrastructure to maintain. The key lesson from this project is that keeping authentication within the Dynamics 365 service layer — rather than bridging to external systems — eliminates an entire category of environment-specific failures that are otherwise very difficult to diagnose and fix. By keeping authentication within Dynamics 365 and leveraging serverless architecture, the solution delivers instant, high-quality reports without infrastructure overhead. This approach demonstrates how modern cloud-native patterns can eliminate entire classes of system failures while improving user experience dramatically. Ready to modernise document generation in your Dynamics 365 environment?CloudFronts builds scalable Power Platform and Dynamics 365 solutions that replace legacy reporting infrastructure and automate document workflows. Reach out at transform@cloudfronts.com. Shashank Keny Associate Consultant · CloudFronts Shashank Keny is an Associate Consultant at CloudFronts with 1.5+ years of experience in cloud, data, and business applications. He specializes in building scalable, API-driven architectures and integrating enterprise systems across the Microsoft ecosystem. He is a Certified Databricks Data Engineer with hands-on experience in Dynamics 365 Project Operations and Dynamics 365 Sales, along with delivering business intelligence solutions using Power BI. His expertise also extends to modern AI solutions, including building custom copilots and implementing intelligent applications using Azure AI Foundry. Passionate about solving real-world business challenges through data and AI, he focuses on delivering efficient, scalable, and production-ready solutions. Experience: 1.5+ years Certification: Databricks Certified Data Engineer Specialization: Dynamics 365 Project Operations, Power BI, Azure Integrations, AI Solutions View LinkedIn Profile

Dynamics 365 plugins run inside an event-driven execution pipeline where business rules and data validation must be enforced before database operations complete. As systems evolve, plugin code often degrades into heavy defensive programming filled with null checks, type casting, and nested exception handling. Over time, exception handling begins to overshadow the actual business logic. This article introduces a DTO + Validation Layer pattern that restructures plugin design into a clean, testable, and scalable architecture. What Is “Try-Catch Hell” in Plugins? Typical Causes Symptoms Issue Impact Deep nested try-catch blocks Hard-to-read code Repeated attribute checks Code duplication Business logic hidden in error handling Difficult debugging Validation spread across plugins Inconsistent rules Result:Plugins behave like procedural error-handling scripts instead of structured business components. Architectural Shift: Entity-Centric → DTO-Centric Traditional plugins manipulate the CRM Entity directly. Problem:The Entity object is: This makes failures more likely. Proposed Flow This separates: DTO: A Strongly-Typed Contract DTOs act as a safe bridge between CRM data and business logic. Without DTO With DTO Dynamic attributes Strong typing Runtime failures Compile-time safety SDK-dependent logic Business-layer independenc Mapping Layer: Controlled Data Extraction All CRM attribute handling is isolated in one place. Benefits Validation Layer: Centralized Rule Logic Traditional DTO Validation Model Validation inside plugin Dedicated validator class Hard to reuse Reusable Hard to test Unit-test friendly The Clean Plugin Pattern Now the plugin: Reduction of Exception Noise Before: Exceptions for missing fields, null references, casting issues, and validation errors. After: Only meaningful business validation exceptions remain. The architecture shifts from reactive error handling to structured validation. Generative Design Advantages Capability Benefit New fields Update DTO + Mapper only New rules Extend validator Shared logic Reuse across plugins Automated testing No CRM dependency Testability Improvement No CRM context required. Performance Considerations To conclude, the DTO + Validation pattern is not just a coding improvement- it changes the way plugins are built. In many Dynamics 365 projects, plugins slowly become difficult to read because developers keep adding null checks, type conversions, and try-catch blocks. Over time, the actual business logic gets lost inside error handling. Using DTOs and a Validation layer fixes this problem in a structured way. Instead of working directly with the CRM Entity object everywhere, we first convert data into a clean, strongly typed DTO. This removes repeated attribute checks and reduces runtime errors. The code becomes clearer because we work with proper properties instead of dictionary-style field access. Then, all business rules are moved into a Validator class. This means: Now the plugin only performs four simple steps: Get data → Convert to DTO → Validate → Run business logic Because of this: Developers can understand the purpose of the plugin faster, instead of trying to follow complex nested try-catch blocks. If your Dynamics 365 environment is evolving in complexity, reach out to CloudFronts, transform@cloudfronts.com, specialists regularly design and implement structured plugin architectures that improve performance, maintainability, and long-term scalability.

In an ideal Dynamics 365 (Dataverse) project, plugin source code lives safely in a version-controlled repository, flows cleanly through Azure DevOps pipelines, and is always recoverable. In reality, many of us inherit environments where that discipline didn’t exist. I recently worked with a customer where: This created a common but uncomfortable challenge in the Dynamics 365 world:How do you maintain, debug, or enhance plugins when the source code is lost? Rewriting everything from scratch was risky and time-consuming. Guessing behavior based on runtime results wasn’t reliable. Fortunately, Dynamics 365 and the .NET ecosystem give us a practical and effective alternative. Using XrmToolBox and JetBrains dotPeek, it is possible to recover readable C# plugin code directly from the deployed assembly. (Though the C# Class code recovered won’t be 100% exact, as the variable names would be different and generic; it is only suitable for close logic, structure & functional recovery) The Practical Solution The approach consists of two main steps: This does not magically restore comments or original formatting, but it does give a working, understandable code that closely reflects the original plugin logic. Tools Used Step 1: Extract the Plugin Assembly from Dataverse 1. Connect to the Environment 2. Load the Assembly Recovery Tool 3. Download the DLL At this point, you have successfully recovered the compiled plugin assembly exactly as it exists in the environment. Step 2: Decompile the DLL Using JetBrains dotPeek 1. Open dotPeek 2. Explore the Decompiled Code dotPeek will: One can now browse through: This is usually more than enough to understand how the plugin works. 3. Export to a Visual Studio Project (Optional but Recommended) One of dotPeek’s most powerful features is Export to Project: This gives you a proper .csproj with class files that you can open, build, and extend. Possibilities with the Recovered Code Once you have the decompiled C# code, several options open up: 1. Rebuild the Plugin Assembly 2. Re-register the Plugin 3. Maintain or Enhance Functionality Important Considerations Key Takeaway Losing plugin source code does not mean losing control of your Dynamics 365 solution. With XrmToolBox’s Assembly Recovery Tool and JetBrains dotPeek, you can: There are chances while working in Dynamics 365 technologies, that a developer might face this situation. Knowing this technique can save days-or weeks-of effort and give your customer confidence that their system remains fully supportable. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In complex business processes, like calculating commissions or validating data across multiple records, applying the same logic repeatedly in a Power Automate flow can quickly become inefficient and difficult to maintain. A more scalable approach is to encapsulate the logic in a Dataverse plugin, expose it as a bound action, and then call this action from a flow. This method centralizes business rules, reduces redundancy, and improves maintainability. In this post, we’ll walk through the steps to implement this approach and examine its advantages over applying the same logic directly within a flow for each individual record. We’ll illustrate this with a practical example from a Houston-based technology consulting and cybersecurity services firm that specializes in modern digital transformation and enterprise security solutions. Flow Diagram Step 1: Create the PluginThe first step is to write a plugin that contains the logic you want to apply to each record. Example: DuplicateCommissionsCounter Step 2: Expose the Plugin as a Bound ActionInstead of running plugin logic manually for each record, you can register it as a bound action in Dataverse. Procedure: E.g. 2. Attach your plugin to this action. Outcome: This exposes your plugin logic as a reusable, callable bound action. Any process or flow can now invoke it for a specific invoice record. Step 3: Use Power Automate to Call the Bound ActionOnce the plugin is exposed, you can loop through multiple records in a flow and call the action. Procedure in Power Automate: This approach ensures that all complex logic resides in the plugin, while the flow orchestrates which records need processing. Advantages Over Logic Directly in the Flow To conclude, exposing plugins as bound actions is a robust, maintainable way to apply complex logic across multiple records in Dataverse. It allows Power Automate flows to focus on orchestration rather than logic execution, leading to cleaner, faster, and easier-to-manage solutions. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com