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 →

Light Sepia Dark 01Summary Part 1 covered the data model behind a certification Agreement Manager in Microsoft Dataverse: eleven tables, a strict ownership boundary that leaves signing to Adobe Acrobat Sign and document storage to Azure Blob, and a coverage model whose whole purpose is to let certification logic answer a question with a query instead of a judgement call. This part covers the automation built on top of it, and it is written against the environment rather than the specification. I went back into the development org and checked, because a build note written at two in the morning is not evidence. What is there: six cloud flows, all activated, a validation action with a plugin step behind it, Adobe configured with real workflow identifiers, and eight agreement requests that have genuinely run through the process, four of them to Fully Executed. What is not there: the custom API that creates coverage, which was never built. Nothing else is permitted to write coverage, so the coverage table is empty. The interesting part is that the system already says this about itself. 02In This Blog What is actually deployed, verified against the environment, and what the gap between the specification and the org tells you about handing work over. The Scenario: A finished data model that still needed to send agreements, track them, store evidence, and produce coverage. The Approach: A decision table fixing flow against plugin against custom API for every operation, written before any automation existed. The Action: Six solution aware flows, a validation action with a plugin behind it, and Adobe wired to real template workflow identifiers. The Outcome: A process that runs end to end up to signature, and one clearly identified missing component that the validation data names out loud. A half finished system is safe to inherit when it tells you what is missing. It is dangerous when you have to find out. Table of Contents 01Summary→ 02In This Blog→ 03Where Part 1 Left Off→ 04Flow, Plugin, or Custom API→ 05What Is Built, and What Comes Next→ 06The Coverage Gate→ 07Impact→ 08Conclusion→ 09FAQ→ 10Get in Touch→ 03Where Part 1 Left Off The foundation was eleven Dataverse tables in three layers. A configuration layer holding Agreement Type, Agreement Template Version, Agreement Role Definition and Agreement Requirement Policy. A process layer centred on Agreement Request with four parental children: Agreement Party, Agreement Recipient, Agreement Document and Agreement Validation Issue. An evidence layer of Agreement Coverage and Agreement Coverage Scope. Adobe Acrobat Sign for Microsoft Dynamics 365 owns signature execution. Azure Blob Storage owns the binaries. Dataverse owns the business decision. Eight alternate keys hold the integrity guarantees, the strongest being the one that makes a second active coverage for the same scope impossible. Everything below assumes that foundation, because the specification forbade starting automation until the tables, keys, forms and views were finished and validated. That sequencing held, and it is the reason the automation layer is as small as it is. 04Flow, Plugin, or Custom API Most Power Platform builds decide implementation style per developer preference, which produces a system where nobody can predict where a given behaviour lives. This build used one canonical decision table, written before any automation existed. Operation Preferred implementation Escalate to code when Validate Agreement Request Solution aware flow or command action that clears unresolved issues, writes new ones, and updates the validation summary The gate needs synchronous reuse, in which case it is promoted to a custom API Send for Signature Power Automate using the Adobe connector, only after validation leaves no blocker Multiple callers need one stable callable action Adobe status sync Adobe managed app plus a lightweight sync flow where needed Concurrency or idempotency require server side code Retrieve and store documents Power Automate for small files, Azure Function for large ones Blob SDK, managed identity, hashing or retry handling are awkward in a flow Create Coverage Custom API, mandatory. A pure flow is explicitly not acceptable Always, because supersession must be transaction safe Open final document Flow or Azure Function generating a short lived link Managed identity and key vault access are easier in a function Coverage gate Synchronous plugin or custom API Certificate issuance must be blocked immediately rather than eventually The canonical matrix. Deviating from it required a written justification, not a preference. Why coverage creation cannot be a flow Creating active coverage means superseding the previous active row, clearing its key, linking the supersession, and inserting the replacement. A flow performs those as separate operations, so a failure between them leaves the legal entity with either no coverage or two. A custom API performs them in one transaction, which is why the specification made it mandatory rather than preferred. The three custom APIs Validate Agreement RequestRe runs validation, populates the policy reference date if blank, enforces legal review approval where the agreement type demands it, upserts validation issues by alternate key, and returns a summary with blocker and warning counts. Create Agreement CoverageResolves policy and scope, builds the coverage match key, supersedes the prior active row and inserts the new one in a single transaction, creates the scope rows, and moves the request to Coverage Created. Evaluate Coverage GateGiven an account, legal entity, agreement type code, scope context and reference date, returns pass, block or exception with the reason and the coverage identifier that satisfied it. 05What Is Built, and What Comes Next It is worth being precise here, because a diagram of the full design would overstate what runs. The following is what the environment reports, not what the specification asked for. Figure 1: What is running today, and what is designed and waiting The automation, as deployed Component What it does State in the environment Validate Agreement Request Writes a structured issue row for every problem found on a request Custom action and plugin step, both activated FLW-01 Send for Signature Hands the prepared agreement to Adobe Activated FLW-02 Adobe Status Sync Brings signing progress back onto the request and … Continue reading How a Sustainability Certification Nonprofit Automated Agreement Management with Adobe Acrobat Sign and Power Automate →

Summary This article covers the implementation of the Vendor Collaboration Portal with Request for Quotation (RFQ) in Dynamics 365 Finance & Operations for a North American manufacturing operation. Vendors were enabled for collaboration and given portal access, RFQs were created and dispatched to one or more suppliers, and vendors responded with price, delivery date and comments directly in the portal. Buyers then compared the responses side by side, accepted the winning quote, and generated a purchase order carried at the quoted price — which flowed straight into the PO approval workflow. The result replaced scattered email-based quoting with a single, structured, auditable sourcing process. Table of Contents Introduction The Business Problem The Solution Vendor Setup for Collaboration Portal User Setup The RFQ Process, Step by Step Considerations & Limitations Business Impact FAQs Conclusion 1. Introduction Sourcing decisions are only as good as the quotes behind them. In many procurement teams, requests for pricing go out over email, come back in inconsistent formats, and get compared in a spreadsheet that no one can audit later. Dynamics 365 Finance & Operations addresses this with Vendor Collaboration — a supplier-facing portal — and the Request for Quotation (RFQ) process that runs on top of it. With this in place, a buyer raises an RFQ inside D365, sends it to selected vendors, and those vendors log in to a secure portal to submit their price and delivery commitments. The buyer compares the responses in one place, accepts the best offer, and turns it into a purchase order without re-keying a single line. This article walks through how the capability was configured and operated end to end. Enable vendorfor collaborationCreate &send RFQVendor submitsquote in portalBuyer compares& acceptsCreate POat quoted priceSubmit toapprovalFigure 1. The RFQ journey — from enabling a vendor on the portal to a purchase order in the approval workflow. 2. The Business Problem Before the rollout, collecting quotes was a manual, email-driven exercise. That created several recurring problems: Quotes arrived in different formats, making a fair side-by-side comparison difficult and slow. There was no single record of who was asked, what they offered, and why a supplier was chosen — weak auditability. Re-keying accepted prices into a purchase order introduced errors and delay. Sending the same request to multiple vendors, and tracking their replies, was hard to manage. Supplier onboarding and access were handled ad hoc, with no controlled activation. The Objective: Give suppliers a controlled self-service portal to respond to quotation requests, and give buyers a structured, auditable way to compare offers and convert the winner into a purchase order in a few clicks. 3. The Solution The solution has three parts: enabling the vendor for collaboration, provisioning the portal user, and then running the RFQ cycle itself. Each is described below with the exact navigation used. 3.1 Vendor Setup for Collaboration The vendor record is prepared first so the supplier can be invited to the portal and confirm orders automatically. Navigation : Accounts payable > Vendors > All vendors 1. Enter the vendor Contact name and Email 2. Enable the vendor for Vendor Collaboration 3. Set PO Confirmation = Auto 3.2 Portal User Setup Next, the individual portal user is created and activated through the standard user request workflow, which runs automatically. 1. In All contacts, add the user: Name, Email address, and Vendor details (assign the legal entities) 2. Click Activate 3. Workflow runs automatically: System administration > Workflows > User workflows > User request workflow (platform) 4. Verify activation: Vendor collaboration > Contacts > Vendor collaboration users 3.3 The RFQ Process, Step by Step With the vendor and user in place, the buyer runs the quotation cycle. Prices are intentionally left blank on creation — the vendor supplies them. Navigation : Procurement and sourcing > Request for quotations > All RFQs Step 1 Create RFQ — add Vendor(s) on the header, and Item, Quantity and Delivery date on the lines. Keep Price blank. Step 2 Send — click Send (selected lines) or Send all. The vendor receives the RFQ in the portal. Step 3 Vendor responds — logs into the portal, enters Price, Delivery date and Comments, then clicks Submit. Step 4 Buyer reviews — open the RFQ, view replies, compare Price, Delivery date and Terms. Step 5 Accept — select the winning vendor response and click Accept. Step 6 Create purchase order — the PO is created at the vendor quote price. Step 7 Submit workflow — open the PO and click Workflow > Submit. RFQ cycle — buyer and vendor actions1Create the RFQ (vendor, item, quantity, delivery date; price blank)2Send the RFQ to one or more vendors via the portal3Vendor submits price, delivery date and comments in the portal4Buyer reviews and compares all vendor replies5Accept the winning quote6Create the purchase order at the quoted price7Submit the PO to the approval workflowFigure 2. The seven-step RFQ cycle, from creation to a submitted purchase order. Multiple vendors can be added on a single RFQ header, so the same request goes out to a competitive field and every reply lands back against one record. 4. Considerations & Limitations A few configuration choices shape how the process behaves in practice. Configuration point Setting used What it controls PO Confirmation Auto Purchase orders confirm automatically once created from the accepted quote. Vendor Collaboration flag Enabled Grants the vendor access to the portal to receive and respond to RFQs. Price on RFQ line Left blank Deliberately empty so the vendor supplies the price — the basis for comparison. Multiple vendors on header Supported One RFQ can be sent to several suppliers for competitive quoting. User activation Workflow-driven Portal users are activated through the platform user request workflow, keeping access controlled. Note: The portal experience depends on correct vendor contact and legal-entity assignment. If a user is not activated through the user request workflow, they will not see RFQs in the portal. 5. Business Impact Moving quoting onto the collaboration portal delivered clear operational gains: Faster quote turnaround, because vendors respond directly in … Continue reading Vendor Collaboration in Dynamics 365 Finance & Operations: Running Request-for-Quotation from Portal Invite to Purchase Order →

☼ Light ☶ Sepia ☽ Dark 01Summary Account data in CRM is rarely in one place, with revenue, pipeline, quotes, and years of meeting notes spread across separate records. We built a one-click Account Intelligence Report that runs inside Dynamics 365 and assembles the complete account picture on screen in seconds. With a second click, an AI analyst reviews every appointment note to produce a plain-language engagement history, current status, open commitments on both sides, and talking points for the next meeting. The complete report, combining facts and AI insights, can then be exported as a branded, editable Microsoft Word document with a single click. Everything runs within the signed-in user’s existing Dynamics session, with no new servers or third-party libraries, while inheriting the user’s existing data permissions by design. Table of Contents 01Summary→ 02The 40-Minute Problem→ 03Solution Overview→ 04Technical Approach→ 05Impact→ 06Conclusion→ 07Let’s Talk→ 02The 40-Minute Problem Picture an account manager thirty minutes before a quarterly business review with a customer they have worked with for three years. The relationship is rich. The context, though, is buried. The revenue figure sits on the Account. The live pipeline is spread across a handful of opportunity records. There are a dozen quotes from the last two quarters, most of them not tracked and easy to forget. Then there are the meeting notes. Dozens of appointments, each with its own thread of what was said, promised, and agreed. None of that is missing. It is all in the CRM. The trouble is that it is everywhere at once. To reconstruct the story of an account, someone has to open twenty records, read between them, and hold the whole picture in their head. So they do not bother. They skim the last two meetings, walk in half prepared, and the deeper context stays invisible until it becomes a problem. This is not a data problem in the sense of not capturing enough. It is a synthesis problem. The organisation already holds the intelligence. It simply has no fast, trustworthy way to assemble it into something a human can act on before a meeting begins. ⓘThe real bottleneck The hardest work in account management is rarely finding the information. It is pulling it together. Connecting revenue, pipeline, and history into one coherent, current view, at the exact moment you need it, is where most of the effort actually goes. 03Solution Overview We set out to solve that synthesis problem with the smallest possible footprint, for a U.S.-based manufacturing facility running Dynamics 365 Sales. The result is a single command on the Account form called the Account Intelligence Report. From the account you are already looking at, one click opens a clean, paper-style report inside the application. It is not another tab to manage or another system to log into. It is part of the CRM you already use. The report does three things, in order: It gathers. In seconds it pulls the account’s revenue, its sales-revenue targets, the most relevant quotes, every open opportunity, and all related appointments together with their notes. It reads. A second click sends those meeting notes to an AI model that writes up the account’s engagement history and distils it into clear, decision-ready insights. It delivers. One more click produces a professional, branded Word document, a finished brief you can email, print, or bring into the meeting. The whole experience is built to feel instant. You stay in the flow of your work, and the report comes to you. What the Report Actually Contains The report is organised the way an account manager actually thinks about an account, not the way a database is organised. At the top is a compact dashboard. Revenue, quote totals, open opportunities, and appointment counts sit at a glance. Below that is the structured document itself. Revenue and pipeline at a glance The opening section brings together the numbers that frame the relationship: the customer’s revenue, the potential opportunity, budget and revenue year-to-date, and the estimated revenue outlook. This single block replaces what would otherwise mean cross-referencing the Account record with a separate sales-revenue table. Quotes and open opportunities Next is a focused view of quotes from the last six months, including those not tracked quotes that quietly accumulate and are easy to lose, alongside every open opportunity in the same window, with its stage, originating lead, product segment, and bid date. Totals calculate automatically, so pipeline value is always visible without a manual add-up. Every related appointment, with its notes This is where the report earns its keep. It lists all related appointments and, crucially, lets you expand any meeting to read exactly what was discussed. Attendees are pulled out, and the full substance of each meeting is available inline. For a customer with a long history, this becomes a navigable timeline of the entire relationship, every visit, call, and commitment, in one place. 💡Why appointments are the hard part Meeting history is usually collected through two different paths in CRM. Sometimes a customer is recorded as a participant, sometimes as the subject of the meeting. The report queries both, then merges and de-duplicates the results, so nothing is missed and nothing is doubled. 04Technical Approach The AI Analyst: Years of Notes in One Read Gathering the notes is only half the battle. Someone still has to read them. The "Get AI Insights" action does exactly that. It takes the full set of appointment notes for the account and asks an AI model, Azure OpenAI, to do what a thorough colleague would do before a meeting: read everything, then tell you what matters. The output is deliberately structured, so it slots straight into the report rather than producing a vague paragraph. It returns six things: Engagement history — a single flowing narrative of the relationship from the earliest meeting to the most recent, with dates, attendees, and the key decisions along the way. Current status — a direct read on where things stand and the overall momentum, in two to four points. … Continue reading Dynamics 365 Sales AI: Turn CRM Data into Dynamic Word Reports for Executive Insights →

Light Sepia Dark 01Summary A global product certification institute needed to know one thing reliably before it could issue a certificate: does this legal entity have a valid, executed certification agreement that covers this certification type and standard version, on this date. Answering that meant opening a signing platform, a document store, and a legacy CRM, then trusting somebody’s judgement. We built an Agreement Manager in Microsoft Dataverse that answers it with a query. The design decision that shaped everything else was refusing to rebuild what already worked. Adobe Acrobat Sign for Microsoft Dynamics 365 remains the signing engine. Azure Blob Storage remains the evidence store. The custom Dataverse layer exists only where the institute needs business control that neither provides: requirement rules, signer preparation, legal party snapshots, structured validation, and above all a machine readable record of what an executed agreement actually covers. This first part covers the foundation: eleven tables, the ownership boundary between Dataverse and Adobe, the coverage model that makes certification gating possible, and the alternate key strategy that prevents two active coverages from ever existing for the same scope. Part 2 covers the automation built on top, and is honest about the one piece that is missing. 02In This Blog A practitioner view of designing the data layer for certification agreement execution on Dataverse, where the output is not a signed PDF but a queryable statement of coverage. The Scenario: Certification decisions were being made without a reliable way to confirm that a valid agreement covered the applicant, the certification type, and the standard version in question. The Approach: Keep Adobe as the signing engine and Azure Blob as the document store. Build custom tables only where business control is genuinely missing. The Action: Eleven tables across a configuration layer, a process layer, and an evidence layer, with parental relationships on every snapshot child and eight alternate keys. The Outcome: Certification logic checks one thing, Agreement Coverage, and never inspects Adobe status or the existence of a PDF. The deliverable of a contract system is not the signed document. It is the ability to prove, in a query, that the document applies. Table of Contents 01Summary→ 02In This Blog→ 03Business Challenges→ 04The Build Boundary→ 05The Data Model→ 06Lifecycle and Duplicate Prevention→ 07Impact→ 08Conclusion→ 09FAQ→ 10Get in Touch→ 03Business Challenges The institute certifies products against a published standard. Before a certificate can be issued, the applicant’s legal entity must have signed the applicable certification agreement, and the agreement that applies depends on region, country, certification type, standard version, and the date the requirement became mandatory. Coverage was a human judgement. Confirming that a signed agreement actually applied to a given application meant reading a PDF and deciding. Two reviewers could reasonably reach different conclusions. Evidence was spread across systems. Executed agreements existed in a legacy CRM, in Adobe outputs, in a document generation tool, and in a manual register. No system held all of them. Requirement rules lived in people’s heads. Which template version became mandatory for which region and certification type, and from what date, was tribal knowledge rather than configuration. Duplicate active agreements were possible. Nothing prevented two concurrent active agreements for the same legal entity and scope, which makes the question of which one governs unanswerable. Manual and wet signature cases had no controlled path. Exceptions were handled by email and stored wherever the handler chose. The recurring failure is not that signing was hard. Adobe already did signing well. The failure was that nothing downstream could consume the result of signing as data. The trap we avoided The obvious move is to build a full contract lifecycle management suite: clause libraries, redlining, negotiation workspaces, a generic multi provider signing framework. All of that was explicitly ruled out of scope. None of it would have answered the coverage question, and each piece would have duplicated something Adobe or Dataverse already provides. 04The Build Boundary Before a single table was created, the specification fixed which system owns what. This is the decision that kept the build lean, and it is worth stating explicitly because it is the one most projects get wrong. Figure 1: The ownership boundary. Seven tables that a generic contract design would have created were deliberately not built. The rule applied throughout was simple. If a requirement can be met by supported Adobe managed functionality without losing business traceability, use the Adobe functionality. Custom tables exist only where the institute needs control that no product provides. Reuse before you extend The environment already contained reference tables for legal entity, region, subregion, country, certification type, standard version, and certification standard scope. Every one of those is referenced by lookup rather than recreated as a local choice. A choice column for country in a certification system is a data quality incident waiting for a rename. 05The Data Model Eleven tables were built in a strict order, and they fall into three layers with different ownership models. Configuration tables are organization owned because they are administered centrally. Process tables are user or team owned because they carry work. Evidence tables are organization owned because coverage is a fact about the institute, not about a user. Figure 2: The eleven table model in three layers, with the reference tables that were reused rather than recreated # Table Purpose Ownership 1 Agreement Type Reusable agreement categories Organization 2 Agreement Template Version Approved legal template and its Adobe workflow reference Organization 3 Agreement Role Definition Signer, reviewer and counter signer roles per template version Organization 4 Agreement Requirement Policy Configurable rule for when an agreement is required Organization 5 Agreement Request Central process record for preparation and lifecycle User or Team 6 Agreement Party Legal parties bound by the agreement, held as snapshots Parented to Request 7 Agreement Recipient Actual signers and their status snapshots Parented to Request 8 Agreement Document Metadata and control record for Blob stored files Parented to Request 9 Agreement Coverage Machine readable evidence that an executed agreement applies Organization 10 Agreement … Continue reading How a Sustainability Certification Nonprofit Automated Certification Agreements in Microsoft Dataverse with Full Audit History →

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

☼ Light ☶ Sepia ☽ Dark 01Summary During a recent Dynamics 365 implementation for a customer in the manufacturing industry, we came across a simple but important user experience requirement: when the Target Margin exceeded 45%, users needed to know about it and have an easy way to correct it. Rather than interrupting the user with a hard error or adding another button to the form, we used the native field recommendation control to provide guidance directly where the decision was being made. With a single click, the user can set the Target Margin back to 45%, trigger the field’s existing logic, and receive confirmation that the change was made. 02In This Blog This blog explores a simple but useful way to make Dynamics 365 forms more interactive using field recommendations. The Scenario: A Target Margin above 45% needs attention, but we don’t want to interrupt the user with a hard error. The Approach: Use the native Dynamics 365 field recommendation to place the guidance right where the user needs it. The Action: Give the user a one-click option to set the Target Margin back to 45%. The Outcome: Update the field, trigger its existing logic, and show a simple confirmation all without adding a new button, plugin, or complex customization. A small recommendation, a single click, and a much smoother user experience. Table of Contents 01Summary→ 02In This Blog→ 03Business Challenges→ 04Solution Overview→ 05Technical Approach→ 06Impact→ 07Conclusion→ 08FAQ→ 09Get in Touch→ 03Business Challenges Most teams that want to nudge a user on a specific field end up reaching for something heavier than the problem needs. A business rule can show an error or a warning, but it only fires on save or on change, and it cannot run a custom action when clicked. A ribbon button can call a script, but it sits at the top of the form, disconnected from the field it actually relates to. A form notification banner can carry a message, but it does not support a click handler, so it cannot open a dialog or call an action. None of these give a user a visual cue on the field itself that also does something when clicked, which is what teams ask for when they say ‘can we show a hint here and let them act on it’. The field recommendation control already exists in the platform for exactly this gap, but it is easy to miss because Microsoft’s own documentation covers the property, not the click through pattern most teams actually want. 04Solution Overview Dynamics 365 already ships a feature called field recommendations, the small lightbulb icon that can appear next to a field when the platform or a customization wants to draw attention to it. We set a recommendation on a field with a short message and a clickable action. When a user clicks the icon, the form runs a JavaScript function we registered against it. Here that function opens an alert, in a live rollout it can just as easily open a business process step, set a related field, or launch a quick create form. Why not a business rule or a ribbon button A business rule stops the user after they try to save or change the field. A ribbon button sits away from the field it concerns. The recommendation icon shows up on the field itself, before the user moves on, and it is the only one of the three that supports a click through action out of the box. 05Technical Approach Register the OnLoad handler (or trigger on any event)Add the JavaScript web resource to the form and bind a function to OnLoad, passing the execution context. Get the field controlInside the handler, call formContext.getControl on the target field. Attach the recommendationCall addNotification on that control with notificationLevel set to RECOMMENDATION, a message, a uniqueId, and an actions array pointing at the click handler. Handle the clickThe action function fires when the user clicks the icon. In this build it opens an alert dialog, nothing more. Clear it when resolvedOn the field’s OnChange event, check the condition and call removeNotification with the same uniqueId once it no longer applies. new_recommendation.jsjavascript function onLoad(executionContext) { var formContext = executionContext.getFormContext(); var attribute = formContext.getAttribute("cf_targetmargin"); if (!attribute) { console.error("cf_targetmargin attribute not found."); return; } attribute.controls.forEach(function (control) { control.addNotification({ messages: [ "The Target Margin must be below or equal to 45%, would you like to set the Target Margin accordingly?" ], notificationLevel: "RECOMMENDATION", uniqueId: "targetMarginRecommendation", actions: [ { message: "Set Target Margin to 45%", actions: [ function () { attribute.setValue(45); attribute.fireOnChange(); Xrm.Navigation.openAlertDialog({ text: "You have successfully changed the Target Margin to 45%.", title: "Target Margin Updated" }); console.log("Target Margin successfully set to 45%."); } ] } ] }); console.log("Recommendation added to: " + control.getName()); }); } Setting Value Event OnLoad and Field OnChange Library new_recommendation.js Functions onLoad, onDiscountChange Pass execution context Yes Field discountpercentage Form event registration ⚠Recommendations do not clear themselves addNotification puts the icon on the field and leaves it there until removeNotification is called with the same uniqueId. If a user fixes the value and moves on without an OnChange handler removing it, the lightbulb stays lit. We missed this in the first pass and had testers reporting a stuck icon that never went away. You can use multiple recommendations by linking them with unique IDs. This will help to handle multiple calls else there would be issue in adding, removing and calling functions. How this looks on the form. The bulb icon next to the field. Once user clicks to accept recommendation. Action is fired and makes the desirable changes. 06Impact 1web resource deployed 0plugins or workflows added 1 clickfrom field icon to custom action 40 linesof JavaScript in the handler The recommendation fires while the user is still on the field, not after they try to save. One JavaScript file replaced what would otherwise be a business rule, a ribbon button, and a separate form notification. 07Conclusion Field recommendations are a small, easy to miss control in … Continue reading How to Connect Dynamics 365 Field Recommendations to Custom Logic with One Click →

Summary A centralized New Product Development (NPD) process was created in Microsoft Dynamics 365 for SIP Industries, a manufacturing organization, replacing disconnected spreadsheets, emails, meeting notes, and verbal follow-ups with a single Dataverse-backed record. A lightweight Simple Intake form enables users to create requests quickly, while a detailed Information form supports cross-functional execution. A configurable business process flow guides each request through Market Analysis, Feasibility Analysis, Drawing Approval, Pattern/Sample, First Article Inspection, Customer Approval, and Production. Power Automate manages feasibility and development approval handoffs, including notifications, outcomes, and comments. Together, these capabilities improve visibility into ownership, current stage, pending decisions, aging, and production readiness. Introduction SIP Industries (SIP) manufactures, imports, and distributes Municipal Casting, Utility Fittings, Joint Restraints, and OEM Castings. Based in Houston, Texas, with facilities in the United States, India, and China, SIP was one of the first innovators to globally source municipal castings and utility fittings in the United States. CloudFronts previously partnered with SIP on a Dynamics 365 Sales implementation, and this NPD initiative builds on that same Dynamics 365 foundation. For SIP’s manufacturing team, the question “Where is this new product request, and what is holding it up?” should be easy to answer. In reality, finding the answer can mean checking several spreadsheets, searching email threads, reviewing meeting notes, and following up with different departments. A request may start with Sales or Customer Service, move to Engineering for feasibility, go through drawing and sample reviews, return to the customer for approval, and finally reach Production. Every team has a valid part to play, but without one shared process the complete journey is difficult to see. To solve this, a unified NPD process was configured for SIP Industries using Microsoft Dynamics 365, Microsoft Dataverse, a model-driven application, a business process flow, and Power Automate. The aim was simple: capture the request once, collect the right information at the right time, route decisions automatically, and keep the full history together. The Business Problem New Product Development is not owned by a single department. Commercial teams assess demand, customer value, competitor information, expected usage, and market potential. Engineering reviews specifications, materials, weight, capacity, design constraints, and technical risk. Quality and Operations manage patterns, samples, inspections, feedback, and readiness for production. Leadership needs to know which requests deserve investment and where action is delayed. When this information is scattered across different tools, four recurring problems appear: Repeated data entry: The same customer, product, and requirement details are typed into multiple trackers. Unclear ownership: Teams know that a request exists but cannot easily see who must act next. Untraceable decisions: Approval outcomes and comments remain buried in email, making it hard to understand why a request moved forward or stopped. Weak management visibility: Status reports are prepared manually and may already be out of date when they are shared. The Solution The solution was designed around one core idea: every new product request should have one record, one visible lifecycle, and one decision history. Dataverse stores the information, the model-driven app presents the forms and views, the business process flow guides users through the stages, and Power Automate manages approvals and notifications. The following sections explain how each part of the solution addressed a gap in the earlier email-and-spreadsheet-driven process. A Fast Intake Experience Without Process Overload The process starts with a Simple Intake form. It contains only the information needed to register an idea, such as the product name, requester, customer, location, weight, OEM indicator, casting type, and requested completion date. The timeline and business process flow are intentionally hidden at this point so that raising a request feels quick and straightforward. After the record is saved for the first time, it opens in the full Information form. The detailed tabs, timeline, business process flow, review fields, and related records then become available to the teams responsible for assessment and execution. The Requested By value remains visible and is locked after creation so the origin of the request is preserved. Figure 1: Simple Intake form showing the essential fields required to create an NPD request. One Shared Record for Commercial, Technical, and Operational Context The complete NPD form acts as the shared workspace for the initiative. Information is arranged into clear areas such as Market Analysis, Feasibility, and Production so that each team can focus on its part of the process without losing the context entered earlier. Market Analysis can capture the customer need, competitor part code, annual usage, expected market value, strategic importance, and customer feedback. Feasibility can hold specifications, location, weight, OEM status, casting type, foundry, capacity considerations, target cost, and technical risks. Later stages record drawing decisions, pattern or sample findings, inspection results, customer approval, and production-readiness information. This structure removes the need for each department to create its own version of the request. The same record becomes richer as it moves forward, while the original business context stays intact. Full Information form showing the business process flow, timeline, and Market Analysis, Feasibility, and Production sections. A Stage-Driven Business Process Flow A business process flow gives users a visible path from initial assessment to production. Each stage presents the information needed for the next decision, helping users understand where the request is today, what must be completed, and what outcome is expected before it can move ahead. Table 1: Representative NPD stages. Optional stages can be retained or bypassed according to product type and governance requirements. NPD stage Decision supported Information captured Market Analysis Confirm that the opportunity is commercially worth exploring. Customer need, competitor part code, annual usage, market context, expected value, strategic fit, and customer feedback. Feasibility Analysis Decide whether the product can be developed responsibly. Specifications, weight, location, OEM indicator, casting type, foundry, capacity, cost considerations, dependencies, and technical risk. Drawing Approval Validate the proposed design when a formal drawing review is required. Drawing status, revisions, comments, corrections, and approval outcome. Pattern / Sample Prepare and evaluate a representative pattern or sample where applicable. Build status, sample dates, findings, feedback, and corrective … Continue reading How a Houston-Based Manufacturer Streamlined New Product Development with Dynamics 365 →

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

Summary For Emirates Consortium, we designed a customized Department Budget Management solution in Microsoft Dynamics 365 Business Central to bring greater control and visibility to departmental budgeting. The solution enables Finance teams to maintain budgets by Department, Budget Year, Budget Month, Category, and Subcategory while separately tracking Original Budget, Additional Budget, Effective Budget, Consumed Amount, and Available Budget. It also introduces controlled budget revisions, Purchase Order validation, Finance-only access, revision history, and consumption tracking based on posted purchasing transactions. Table of Contents Introduction The Business Requirement Designing the Department Budget Structure What Finance Can See on the Department Budget Setup Separating Original, Additional and Effective Budget Protecting the Original Budget Controlled Budget Revision Why the Revision Is Linked to a Purchase Order Purchase Order Must Be Open Before Budget Revision Restricting Budget Revision to Finance Maintaining Budget Revision History How We Calculate the Available Budget Calculating the Consumed Amount from Posted Transactions How Partial Invoicing Is Handled Putting It All Together Business Benefits Conclusion Introduction As part of our implementation for Emirates Consortium, we designed a customized Department Budget Management solution in Microsoft Dynamics 365 Business Central to strengthen budget control and provide Finance teams with greater visibility into departmental expenditure. The solution enables budgets to be maintained using a structured combination of Department, Budget Year, Budget Month, Category, and Subcategory. It also provides separate visibility into the Original Budget, Additional Budget, Effective Budget, Consumed Amount, and Available Budget, along with controlled budget revisions, Purchase Order validation, Finance-specific access, revision history, and consumption tracking based on posted purchasing transactions. This approach was designed to help Finance teams answer important budget-control questions such as: What was the original approved budget? How much additional budget was provided later? How much has already been consumed? How much budget is currently available? Who revised the budget and when? Why was additional budget required? For one of our Business Central implementations, we addressed this requirement by developing a dedicated Department Budget Management solution. The objective was to keep the process simple for Finance users while providing the controls and auditability expected from an ERP system. The Business Requirement Previously, departmental budgets were maintained outside Business Central, making it difficult to validate purchasing transactions against the latest available budget. Another challenge was that a department could have several different budgets. Department Year Month Category Subcategory Original Budget ADMIN 2026 August OPEX Fuel Cost 5,000 ADMIN 2026 August OPEX Engine 5,000 ADMIN 2026 August CAPEX Boat 50,000 Therefore, maintaining only a single budget amount against a department was not sufficient. We needed a structure that could identify the exact budget applicable to a particular expenditure. Designing the Department Budget Structure We created a dedicated Department Budget Setup page in Business Central. Each budget is uniquely identified using the following combination: Department + Budget Year + Budget Month + Category + Subcategory For example: ADMIN → 2026 → August → OPEX → Fuel Cost This structure allows Finance to maintain separate budgets for different expense areas within the same department and month. From a technical perspective, the same combination is used as the primary key of the Department Budget Setup table: key(PK; “Department Code”, “Budget Year”, “Budget Month”, Category, Subcategory) { Clustered = true; } This ensures that duplicate budget records cannot be created for the same combination. What Finance Can See on the Department Budget Setup The Department Budget Setup page was designed to give Finance a quick view of the complete budget position. Field Purpose Department Code Department for which the budget is maintained Purchase Order No. Related Purchase Order, where applicable Budget Year Budget year Budget Month Month for which the budget is maintained Category Expense classification, such as OPEX or CAPEX Subcategory Detailed expense classification Original Budget Amount Initial budget allocated by Finance Additional Budget Amount Additional budget provided through revisions Effective Budget Amount Total approved budget after revisions Consumed Amount Budget already utilized Available Budget Amount Remaining budget available for utilization Last Revised By User who last revised the budget Last Revised Date Time Date and time of the latest revision This gives Finance a consolidated view without having to calculate the current budget manually. Example Original Budget Amount: 5,000 Additional Budget Amount: 10,000 Effective Budget Amount: 15,000 Consumed Amount: 5,400 Available Budget Amount: 9,600 From a single page, Finance can immediately understand the complete position of that budget. Separating Original, Additional and Effective Budget One of the most important decisions in this solution was not allowing the original budget to be overwritten whenever additional funds were approved. Consider an original budget of: AED 10,000 Later, Finance approves an additional: AED 5,000 Simply changing the original budget from 10,000 to 15,000 would remove the history of what was initially approved. Instead, we maintain these amounts separately: Budget Component Amount Original Budget 10,000 Additional Budget 5,000 Effective Budget 15,000 The calculation is: Effective Budget = Original Budget + Additional Budget “Effective Budget Amount” := “Budget Amount” + “Revised Budget Amount”; Although the calculation itself is straightforward, keeping these values separate provides much better financial visibility and auditability. Protecting the Original Budget Once a Department Budget is created, the original budget and its identifying information should not be casually changed. For this reason, we added validations to protect fields such as: Department Budget Year Budget Month Category Subcategory Original Budget Amount if “Budget Amount” <> xRec.”Budget Amount” then Error( ‘The original budget amount cannot be changed after the budget is created. Use the Revise Budget action instead.’); Therefore, instead of allowing: Create Budget → Manually Edit Budget → Edit Again the controlled process becomes: Create Original Budget → Lock Original Amount → Use Revise Budget for Additional Allocation This preserves the integrity of the original budget. Controlled Budget Revision Budgets naturally change during the year, so preventing all changes would not be practical. To handle this requirement, we introduced a dedicated Revise Budget action. When additional budget is required, the Finance user provides: Purchase Order No. Revision Amount Revision Reason Description Amount Original Budget … Continue reading How an Abu Dhabi-Based Diversified Holding Company Built Department-Wise Budget Control in Microsoft Dynamics 365 Business Central →