At a Glance A client in Abu Dhabi discovered more than 400 posted G/L entries with incorrect dimension values. Using Dimension Correction in Microsoft Dynamics 365 Business Central, the finance team was able to correct the dimension values in bulk without creating reversal or adjustment entries. The corrections could be validated, audited, reviewed, and undone, providing a controlled approach to fixing posted transactions. However, it is important to note that Dimension Correction applies to G/L entries only; related sub-ledger entries retain their original dimensions. Table of Contents Introduction Why Dimension Errors Happen in the First Place What Dimension Correction Actually Does Setting Up Before the First Correction Step 1: Starting the Correction from the Ledger Step 2: Selecting Entries in Bulk Step 3: Defining the Dimension Changes Step 4: Validating Before You Run Step 5: Running the Correction Step 6: Reviewing, Undoing and Auditing A Note on Cost Accounting The Outcome Best Practices We Recommend Conclusion Frequently Asked Questions About the Author Introduction Dimensions are what turn a general ledger from a list of numbers into something management can actually use. A single expense posting tells you how much was spent; the dimensions on that posting tell you which department spent it, on which project, at which location. When dimensions are right, reports by cost centre, business unit or project take seconds to produce. When they are wrong, every one of those reports quietly becomes unreliable. That was the situation one of our clients in Abu Dhabi found themselves in. During routine month-end review, their finance team noticed that a large group of posted transactions carried the wrong dimension values. Some entries were tagged to the wrong department, others to the wrong project, and a few had no value at all where one was expected. By the time the pattern was traced, more than 400 general ledger entries were affected. Reversing and re-posting each transaction was not an option. It would have doubled the number of entries in the ledger, cluttered the audit trail and taken days of effort. Editing entries one at a time was equally impractical. Instead, we used the Dimension Correction feature in Microsoft Dynamics 365 Business Central to fix all of them in a controlled, bulk operation, without touching the amounts or the accounts. This blog walks through how the feature works, how we applied it for this client, and what to keep in mind before you run a correction in your own environment. Why Dimension Errors Happen in the First Place In our experience, incorrect dimensions rarely come from a single cause. For this client, the errors came from a mix of everyday situations that most finance teams will recognize: 1. Default dimensions not updated after an internal restructuring, so new transactions kept inheriting the old department code. 2. Manual journal entries where users picked a similar-looking value from the lookup list. 3. Recurring journals that were copied forward month after month with an outdated project code. 4. Imported data from a spreadsheet where the dimension column was shifted by one row. None of these errors affected the trial balance. The debits and credits were correct and the accounts were correct. What was wrong was the analytical layer on top, which meant that department-wise P&L and project cost reports no longer matched reality. What Dimension Correction Actually Does Dimension Correction lets an authorized user change the dimension values on general ledger entries that have already been posted. It does this without creating new journal lines, reversals or adjustment postings. The amounts, dates, document numbers and G/L accounts stay exactly as they were; only the dimension set linked to each entry is updated. Every correction is recorded as its own document with a description, a status and a list of the entries it touched. That means auditors and finance managers can always see what was changed, when, and why. Important limitation The correction applies to G/L entries only. Related sub-ledger entries, such as customer, vendor, item or fixed asset ledger entries, keep their original dimensions. Since the purpose of the feature is accurate financial reporting, this is by design, but it is worth communicating to anyone who reports from sub-ledgers. Setting Up Before the First Correction Before our client’s finance team ran anything, we put two controls in place. 1. Decide who can correct dimensions Access to the feature is governed by the D365 DIM CORRECTION permission set. We assigned it only to the finance controller and one senior accountant. Users with this permission can create, run and undo corrections, so it should not be handed out broadly. 2. Protect dimensions that should never change On the Dimension Correction Settings page, you can list dimensions that are blocked from correction. For this client, we blocked the dimension used for statutory entity reporting, since any change there needed a formal adjustment rather than a re-tag. Step 1: Starting the Correction from the Ledger A correction can be started from two places: 1. General Ledger Entries page, using the Correct Dimensions action. This is the most flexible starting point when the affected entries are spread across many postings. 2. G/L Registers page, by selecting a register and choosing Correct Dimensions. This pre-loads all entries from that register and is useful when a single batch posting went wrong. Because the client’s 400+ entries came from different journals and dates, we started from the General Ledger Entries page. The first thing we filled in was the Description field, with a note explaining the reason for the change and a reference to the internal approval. It takes ten seconds and saves a lot of questions six months later. General Ledger Entries page showing the Correct Dimensions action. Step 2: Selecting Entries in Bulk This is where the feature really earns its place. Instead of picking entries one by one, the Selected Ledger Entries FastTab offers several ways to build the list: Option How we used it Add by Filter Filtered on G/L account range and posting date range to pull … Continue reading How an Abu Dhabi-Based Diversified Holding Company Corrected Mis-Tagged Ledger Entries in Dynamics 365 Business Central →

Summary This solution is being implemented initially for the Chart of Accounts of an Emirates-based firm , where significant updates are required across the existing G/L Account master. The objective is to provide Finance users with a simpler and more familiar way to review and maintain supported records through Excel, reducing the dependency on technical users for routine maintenance activities. Although the current implementation focuses on the Chart of Accounts, the approach is not limited to G/L Accounts and can be extended to other supported master data, such as Customers, Vendors, Items, and similar records. By providing an Excel-based alternative for suitable maintenance scenarios, the solution reduces the need to use Configuration Packages for every routine update while allowing technical teams to focus on complex development, integrations, automation, and customization activities. Table of Contents Introduction Understanding the Business Requirement The Traditional Approach The Business Problem The Excel-Based Solution Using Excel Integration Selecting the Required G/L Accounts Reviewing Existing Data Updating Supported Fields Publishing Changes Verifying the Changes Implementation Approach Moving Bulk Maintenance Toward Functional Users Business Impact Important Considerations Frequently Asked Questions Conclusion Introduction The Chart of Accounts is one of the core components of financial management in Microsoft Dynamics 365 Business Central. As part of the current implementation for an Emirates-based firm, significant updates are required to the existing Chart of Accounts to align the financial structure with the organization’s evolving reporting, accounting, and operational requirements. Since the required changes involve a large number of G/L Accounts, updating each account individually within Business Central would be repetitive and time-consuming. The volume of changes creates a requirement for a more efficient approach that allows multiple existing records to be reviewed and updated in a structured manner. Traditionally, Configuration Packages can be used to perform bulk data updates in Business Central. While this provides a powerful mechanism for data migration and bulk maintenance, routine updates may still require technical involvement and additional configuration steps. For the current Chart of Accounts requirement, the objective is to provide Finance users with a simpler and more familiar method for making supported bulk changes. The Key Question: Can Finance users efficiently review and update a large number of G/L Accounts through a familiar Excel-based interface, while reducing the need for technical assistance for routine bulk maintenance activities? To address this requirement, the proposed approach uses the Microsoft Dynamics 365 Business Central Excel integration for supported bulk maintenance activities. Although the initial implementation is focused on the Chart of Accounts due to the significant updates required for the Emirates-based firm, the same approach can also be applied to other supported master data, such as Customers, Vendors, Items, and other relevant records, where similar bulk maintenance requirements arise. Understanding the Business Requirement During the implementation, the consultant was faced with a practical challenge: the Finance team needed to make a significant number of changes to the existing Chart of Accounts, but updating each G/L Account individually in Business Central would require considerable manual effort. The consultant also needed a solution that Finance users could work with directly, without having to depend on the technical team for every routine change. The Excel integration provided a way to address this issue by allowing the consultant to work with the relevant G/L Account data in a familiar spreadsheet environment. Instead of opening and modifying accounts one by one, the required records could be brought into Excel, reviewed together, and the necessary values could be prepared or updated in bulk. This made the large-scale Chart of Accounts maintenance activity more manageable and significantly reduced repetitive manual work. How the Requirement Was Resolved: The consultant can use the Business Central Excel integration to provide Finance users with a structured way to work with supported G/L Account data in bulk. This allows multiple records to be reviewed and updated through Excel rather than requiring individual changes within Business Central for every account. This approach also addressed the dependency between the Finance and technical teams. Finance users can handle suitable routine master-data maintenance themselves, while the technical team remains available for activities that genuinely require technical expertise, such as complex customizations, integrations, automation, troubleshooting, and development. Although the immediate problem was related to the Chart of Accounts, the solution is not limited to G/L Accounts. The same concept can be applied wherever Business Central supports the relevant Excel-based maintenance capability, including other master data such as Customers, Vendors, Items, and similar records. This makes the approach useful beyond the immediate implementation and provides a repeatable method for handling future bulk maintenance requirements. The Traditional Approach Before considering the Excel-based approach, the consultant could use Configuration Packages to perform bulk updates to the Chart of Accounts. Configuration Packages are a standard and powerful Business Central capability for importing, exporting, and managing data across Business Central tables and remain particularly useful for data migration, initial configuration, and structured data-import scenarios. However, for the current requirement, the Finance team needed to make a significant number of changes to existing G/L Accounts. Using a Configuration Package for every such change could require additional preparation and involvement from a technical or experienced Business Central user. This created an additional dependency for what was essentially a routine master-data maintenance activity. The consultant therefore had to consider not only how the data could be updated in bulk, but also how the process could be made easier for the Finance team while maintaining appropriate control over the data. Finance Identifies Changes → Prepare Update Data → Technical Assistance → Configure Package → Import & Validate → Finance Verification This approach works well when there is a genuine requirement for structured data migration or when multiple related tables and fields need to be handled together. However, for repetitive updates to existing master records, it can result in additional steps that are not always necessary for the Finance user’s immediate requirement. The objective, therefore, was not to replace Configuration Packages altogether. Instead, the consultant identified an opportunity to use the Business Central Excel … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Master Data Maintenance in Dynamics 365 Business Central Using Excel →

Summary A home loan bank in the Maldives came to us needing legal, customer-facing reports for loan statements and overdue notices that had to reflect exact facility figures while matching the bank’s letterhead and legal wording. Traditional RDLC-based report development would have created significant IT dependency and delay for a document like this. Instead, our team used Word-based report layouts in Microsoft Dynamics 365 Business Central, which let us design the legal notice in a familiar document tool while Business Central handled populating it with live facility and customer data. We mapped the bank’s Business Central fields into a Word template, tested it against real facility scenarios, and delivered a working legal report in approximately two days, which is a turnaround that would traditionally take weeks with RDLC. This article walks through how we approached the build, using a sanitized sample report in place of the client’s confidential documents, and explains when we’d recommend Word over RDLC for a bank’s reporting needs. Table of Contents Introduction The Problem: IT Bottlenecks and Delayed Customer Documents The Word-Based Reporting Solution 3.1 How the Word-Based Approach Works 3.2 Creating the Word Template 3.3 Mapping Business Central Fields 3.4 Testing and Delivering the Report Sample Walkthrough: The Legal Report We Built Word Report vs. RDLC Report Time and Effort Comparison Why Banking Teams Benefit from Word Reports What Types of Banking Documents Work Best? Business Benefits When RDLC Is Still the Better Choice FAQs Conclusion About the Author Introduction Legal, customer-facing documents are one of the most sensitive parts of any lending business. A home loan bank in the Maldives came to us needing exactly this kind of document: a legal report covering a loan statement and overdue notice, which had to reflect exact facility figures, carry the correct legal clauses, and match the bank’s letterhead, all while pulling live data straight out of Business Central. Producing a document like this inside Microsoft Dynamics 365 Business Central can easily turn into a multi-week project if it’s built the traditional way. RDLC-based reporting usually means a developer has to build and maintain the report layout, write or modify code, configure data sources, and run several rounds of testing before the document is ready to go out to a customer. For a fairly standard legal document, like a loan statement or overdue notice, that kind of timeline is hard to justify. So instead of taking the client down the RDLC route, we proposed another option: Word-based report layouts. Word templates let us design the layout of the legal report in a tool the bank’s own team could later maintain, while Business Central handled populating it with the correct facility and customer data. The key idea: We designed the legal report’s layout and wording in Word, and let Business Central handle pulling in the correct facility data, so the client wasn’t locked into a developer for every future change. This article walks through how we built it, using a sanitized sample report in place of the client’s confidential documents, and explains how a report that would traditionally take weeks of RDLC development was designed, mapped, and delivered in approximately two days using a Word-based approach. The Problem: IT Bottlenecks and Delayed Customer Documents When the client first came to us, their existing experience with reporting was the same one many banks run into: a dependency between operations teams and technical teams that turns a simple document request into a long wait. The kind of request that used to happen internally looked something like this: “Hey, can we get a loan statement that shows the customer’s outstanding EMI, fines, and facility balance in one clean document?” “Sure, I’ll put in a ticket with IT.” [Two weeks later…] “The statement is almost done. It should be ready in another couple of weeks.” [Four weeks later…] “It’s finally here. Wait… the layout doesn’t match our branch letterhead format.” This kind of situation can happen when a relatively standard customer document becomes dependent on development resources. Why Do These Delays Happen? RDLC report layouts can require specialized development knowledge. Developers need time to configure data sources and implement the required reporting logic. Testing and troubleshooting can add additional development cycles. Small formatting changes such as a different overdue clause or a revised disclaimer may require technical assistance. Future modifications can place the document back into the development queue. Branch or collections staff may resort to manual, Word- or Excel-based workarounds while waiting for the official document. The result is a disconnect between the people who understand exactly what a legal notice or statement needs to say and the people responsible for implementing it in the system. The question we asked the client: What if your own operations or collections team could design and maintain these legal documents, using a tool they already know instead of relying on a developer for every change? The Word-Based Reporting Solution Microsoft Word was already familiar to the bank’s operations staff, so we proposed taking advantage of that. Business Central supports using Word templates directly as report layouts, which meant we didn’t need to build the legal report’s presentation through RDLC at all. Instead of developing the entire document presentation through RDLC, we designed the layout directly in Word and mapped Business Central’s available facility and customer data to the appropriate fields within that template. The solution: We used Word for the legal report’s presentation and Business Central for the facility data behind it. This separated document design from complex layout development and gave the client’s operations team greater control over formatting, tone, and compliance wording going forward. How We Approached the Build Our overall process was straightforward: Design the legal report layout using Microsoft Word. Add the required data fields to the Word template. Map those fields to the appropriate Business Central data. Run the report and let Business Central populate the template. Review the generated document with the client and adjust the layout where needed. The important distinction is that the document’s visual … Continue reading How We Built Legal Reports in Word on Business Central for a Home Loan Bank in the Maldives →

Summary In Business Central, users may need to view relevant purchase invoice details directly from General Ledger Entries for better transaction visibility and traceability. This enhancement was implemented based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution in the Maldives. The solution enables purchase invoice details to be automatically captured against relevant General Ledger Entries for new transactions, while also providing an option to update previously posted entries. This helps finance users quickly identify the related invoice information without having to navigate through multiple pages or documents. Related Case Studies: Emirates Consortium – Customer Success HDFC PLC – D365 Business Central Integrated with Loan Management Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard G/L Entry Descriptions Displaying vs. Storing the Description Designing the Solution Updating Historical G/L Entries Maintaining the Description for New Entries Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction In day-to-day financial operations, users often need to trace General Ledger Entries back to the original purchase transactions for verification, reconciliation, and reporting purposes. However, the standard General Ledger view may not always provide enough contextual information to quickly identify the details of the related purchase invoice. Based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution operating in the Maldives, an enhancement was introduced to make relevant purchase invoice details available directly within General Ledger Entries. The enhancement improves transaction visibility by capturing the relevant purchase invoice description against the General Ledger Entry. For newly posted transactions, the information can be populated automatically, while previously posted entries can be updated through a dedicated action. This approach reduces the need for users to navigate between General Ledger Entries and posted purchase invoices, making financial review and transaction tracing more convenient and efficient. Understanding the Business Requirement From a Finance user’s perspective, the requirement was straightforward: When a user reviews a G/L Entry, the Description should provide meaningful information about the transaction. The requirement needed to work for both existing historical entries and transactions posted after the customization was introduced. 1. Historical G/L Entries Business Central may already contain a significant number of posted G/L Entries. These historical records also needed to have the enhanced description populated. Updating these entries individually would not be practical. Therefore, the solution needed to provide a controlled way to update existing G/L Entries in bulk. 2. New G/L Entries For future transactions, the description should be populated automatically during the posting process so that users do not have to manually update the G/L Entry after posting. This resulted in two key requirements: Provide a mechanism to populate descriptions for historical G/L Entries. Automatically maintain the description for newly created G/L Entries. The Challenge with Standard G/L Entry Descriptions The first question during the design was whether the required description could simply be calculated when the G/L Entry page was opened. At the page level, a value can be calculated dynamically based on related information. This approach can be useful when the requirement is simply to display additional information to the user. However, there is an important distinction between displaying a calculated value and storing that value in the underlying G/L Entry record. A page-level calculated value does not automatically become part of the underlying G/L Entry data. Therefore, although a user may see the expected description on the page, the value may not be available in the same way for other processes that directly consume the G/L Entry data. Key Design Consideration The requirement was not only to display a meaningful description. The description needed to be persisted against the G/L Entry record. Displaying vs. Storing the Description This distinction became an important part of the solution design. 1. Page-Level Calculation A page-level calculation is useful when the requirement is simply: “Show this information to the user.” The value can be generated when the page is opened without modifying the underlying G/L Entry record. 2. Persisted G/L Entry Description For this requirement, the description needed to become part of the actual G/L Entry data. The solution therefore stores the generated description directly against the G/L Entry. G/L Entry → Determine Transaction Information → Generate Description → Store in G/L Entry This approach ensures that the description remains available after the page is closed and can be consumed by other Business Central processes that use the G/L Entry record. Designing the Solution The solution was designed around two scenarios: historical G/L Entries and newly created G/L Entries. 1. Historical G/L Entries A dedicated action is provided to populate the enhanced description for existing G/L Entries. This allows Finance users or authorized administrators to update historical records without having to process each entry individually. 2. Newly Created G/L Entries For newly posted transactions, the description is maintained as part of the G/L Entry creation process. This means that the enhancement does not depend on users remembering to manually update the description after every posting. Two-Part Approach Existing Entries: One-time controlled update. New Entries: Automatic description population during the posting process. Updating Historical G/L Entries Since the system may already contain historical G/L Entries, simply implementing the logic for future postings would leave existing records without the enhanced description. To address this, we introduced a one-time action that allows the required description to be generated and stored for historical entries. The process can be represented as: Existing G/L Entries → Run Update Action → Determine Required Information → Generate Description → Update G/L Entry This approach provides a practical way to bring historical records into the same structure used for newly posted transactions. Maintaining the Description for New Entries Updating historical records solves only one part of the requirement. The same description logic also needs to be applied to future G/L Entries. Therefore, the solution ensures that the description is generated and stored when the relevant G/L Entry is created. This avoids a situation where historical records have the … Continue reading Enhancing General Ledger Visibility with Purchase Invoice Details in Dynamics 365 Business Central for a Maldives Financial Institution and an Abu Dhabi-Based Diversified Holding Company →

Summary As part of our implementation for HDFC Maldives, we encountered a complex payment approval requirement in Microsoft Dynamics 365 Business Central involving multiple approval stages, any-one-user approval behavior, Checked By validation, actual approver tracking, and Internet Banking approval. Instead of replacing the standard Business Central workflow framework, we extended it only where the required business behavior differed from the standard process. This approach allowed us to retain Workflow User Groups, Approval Entries, workflow progression, and standard approval capabilities while introducing custom controls for Checked By processing, Sequence 2 approval handling, actual approver logging, and final payment voucher traceability. Table of Contents Introduction Understanding the Business Requirement What Worked with Standard Business Central? The Challenge at the Second Approval Sequence Finding the Right Approach The Second Challenge: Who Actually Approved? Introducing the Actual Approver Log Why Checked By Was Kept Separate Automatic Transition to Standard Approval Improving Payment Voucher Traceability Final Solution Architecture Preview Video Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows often look straightforward when they are first discussed: one person submits a transaction, the required approvers review it, and the process continues once approval is completed. In practice, the requirements can become much more complex when different stages need different approval behaviors. During a loan management implementation for a Maldives-based financial services organization, we encountered exactly this situation while designing the approval process for Payment Journals in Microsoft Dynamics 365 Business Central. The business did not want a simple sequential approval process. Some stages required any one authorized user to complete the approval, another stage required a separate pre-check before the standard workflow could begin, and the final payment process required two Internet Banking approvals. The challenge was therefore not simply to configure a workflow. It was to determine how much of the standard Business Central approval framework could be retained, where customization was genuinely required, and how to maintain an accurate audit trail of the users who actually performed each approval action. The Design Principle Rather than replacing Business Central’s standard workflow framework, we decided to keep the standard approval engine wherever possible and customize only the areas where the required business behavior differed from the standard process. Understanding the Business Requirement The Payment Journal required several approval stages, with different rules at each level. Stage Approvers Required Behavior Checked By Multiple Checkers Any one authorized checker Sequence 1 2 Approvers Any one approver Sequence 2 4 Approvers Any one approver Internet Banking 2 Approvers Two-level validation The intended business process was: Payment Journal → Checked By – Any One → Sequence 1 – Any One of 2 → Sequence 2 – Any One of 4 → Posting → Internet Banking Approval At first glance, the standard Workflow User Group functionality appeared capable of handling most of this requirement. However, testing revealed an important difference between the expected business behavior and the approval behavior encountered at the later approval sequence. Fig: Payment approval workflow configured for the multi-stage payment process. What Worked with Standard Business Central? Workflow User Groups were the natural starting point because they already provide a structured way to maintain approvers without hardcoding individual users in custom development. For the first approval sequence, two approvers were configured and the required behavior worked as expected. Sequence 1 Approver A + Approver B → Any one approver completes the stage → Workflow continues This initially suggested that the standard approval configuration would be sufficient for the entire process. The benefit of continuing with standard Business Central was significant because the platform was already managing Workflow User Groups, Approval Entries, statuses, approval requests, cancellations, notifications, and workflow progression. The Challenge at the Second Approval Sequence The main challenge appeared when the transaction progressed to the second approval sequence. Four approvers were configured at this level, but the business requirement remained the same: any one of the four authorized approvers should be able to complete the stage. Expected Behavior Approver C / Approver D / Approver E / Approver F → Any one approves → Approval stage completes However, the workflow behavior encountered at this subsequent sequence did not allow the stage to complete in the required manner after only one user approved. The transaction remained pending because the approval requests associated with the sequence were still active. This created the central mismatch between the standard workflow behavior encountered during testing and the customer’s required approval model. Finding the Right Approach One option would have been to replace the approval process entirely with a custom approval engine. We deliberately avoided that approach. Business Central was already successfully handling several important parts of the process: Workflow User Groups Approval Entries Approval statuses Sending approval requests Cancelling approval requests Workflow progression Rebuilding all of this would have introduced unnecessary complexity and additional maintenance. The Approach Keep the standard Business Central workflow and customize only the approval behavior that did not meet the business requirement. For the second approval sequence, we introduced a custom Approve Approval Request action that allows one authorized approver to complete the required stage while preserving the surrounding standard workflow framework. :contentReference[oaicite:4]{index=4} The Second Challenge: Who Actually Approved? Solving the approval progression created another important requirement. When one user completed the customized approval stage, the related standard Approval Entries could ultimately reflect an Approved status for the eligible approvers. Consider four users: Approver C Approver D ← Actually clicked Approve Approver E Approver F If the final Approval Entries are reviewed only by status, they may not clearly identify that Approver D was the person who physically performed the approval action. This became especially important because the Payment Voucher needed to answer a very simple audit question: Who actually clicked Approve? The standard Approval Entry status alone was therefore not sufficient for the reporting requirement. :contentReference[oaicite:5]{index=5} Introducing the Actual Approver Log To preserve the identity of the person who actually performed the approval, we introduced a separate Actual Approver Log. At the moment the user performs the approval action, the solution captures: User ID … Continue reading How a Maldives-Based Loan Firm Streamlined Multi-Level Payment Approvals with Microsoft Dynamics 365 Business Central →

Executive Summary In Part 1, we explored how Emirates Consortium LLC expanded its use of Microsoft Dynamics 365 Business Central from primarily finance operations into a structured procurement process. The journey begins with a Purchase Request, moves through approval and supplier selection, continues through Purchase Quotes, and ultimately reaches the Purchase Order stage. For Emirates Consortium, however, creating a Purchase Order is not simply the final step in procurement. It is also an important financial control point. The implemented solution evaluates the Purchase Order against the applicable departmental budget and provides visibility into the available budget, any budget shortfall, and whether a budget revision is required. This creates a connected process in which procurement decisions and financial controls are managed within the same ERP environment. Table of Contents Introduction Why Budget Control Matters Budget Validation at the Purchase Order Stage Understanding Budget Information on the Purchase Order What Happens When the Budget Is Exceeded? Finance and Budget Revision Supporting Documentation for Budget Decisions Budget Consumption and Financial Visibility Final Approval Control End-to-End Budget-Control Process Key Benefits Frequently Asked Questions Conclusion Introduction In a procurement process, approving a business requirement and selecting the right supplier are only part of the decision-making process. Organizations also need to determine whether the planned expenditure is aligned with the approved budget. For Emirates Consortium, budgets were previously managed manually through Excel, while certain procurement activities were performed outside Business Central. As part of the broader procurement implementation, the objective was to bring budget visibility directly into the purchasing process and establish a structured mechanism for determining whether planned expenditure could proceed. The customized solution therefore evaluates the Purchase Order against the applicable departmental budget. How Is the Applicable Budget Determined? The budget is identified using a combination of: Department + Budget Year + Budget Month + Category + Subcategory The Purchase Order amount is then compared against the applicable budget to determine whether sufficient budget is available. This provides the foundation for the organization’s over-budget control process. Why Budget Control Matters Without budget visibility, procurement and finance can easily become two disconnected processes. The procurement team may know that a particular purchase is required to support the business, while Finance may know that the relevant department has a defined financial limit. However, without connecting these two perspectives, it can be difficult to determine whether the planned expenditure is within the approved budget. The implemented process brings these perspectives together at the Purchase Order stage. The Purchase Order is therefore more than a document used to communicate an order to a vendor. It becomes a financial control point where planned expenditure can be evaluated against the applicable budget. Budget Validation at the Purchase Order Stage Once a Purchase Quote has been reviewed and finalized, it can be released and converted into a Purchase Order using Make Order. There is no separate approval workflow at the Purchase Quote stage in the implemented process. The primary budget control is applied when the transaction reaches the Purchase Order stage. At this point, the system determines the applicable budget based on: Department Budget Year Budget Month Category Subcategory The Purchase Order amount is then evaluated against the applicable departmental budget. This allows the organization to determine whether the planned purchase is supported by the available budget before the expenditure proceeds further through the procurement lifecycle. Understanding Budget Information on the Purchase Order The customized Purchase Order provides users with visibility into several budget-related fields. Budget Information Purpose Budget Year Identifies the applicable financial year for the budget evaluation. Budget Month Identifies the applicable budget period. PO Budget Amount Shows the budget amount considered for the Purchase Order. Available Budget Amount Shows the amount of budget available for the purchase. Budget Exceeded Amount Shows the amount by which the Purchase Order exceeds the available budget. Budget Available Indicates whether sufficient budget is available. Budget Exceeded Identifies whether the Purchase Order exceeds the applicable budget. Budget Checked Indicates whether the budget validation has been performed. Budget Checked By Identifies the user who performed the budget check. Budget Checked Date/Time Records when the budget validation was performed. Budget Revision Required Identifies whether additional budget consideration is required. These fields provide procurement and finance teams with a common view of the financial position associated with the purchase. Key Questions Answered at the Purchase Order Stage How much budget is applicable to the purchase? How much budget is currently available? Is the Purchase Order within the available budget? If the budget is exceeded, by how much? Is a budget revision required? Who performed the budget check and when? What Happens When the Budget Is Exceeded? The key control comes into play when the Purchase Order amount is greater than the available budget. Rather than treating the Purchase Order as an ordinary purchasing transaction, the system identifies that the planned expenditure requires additional financial consideration. The Purchase Order provides visibility into: Budget Exceeded Budget Exceeded Amount Budget Revision Required This establishes a clear distinction between a Purchase Order that falls within the available budget and one that requires further financial action. The over-budget scenario therefore becomes an explicit part of the procurement process rather than something Finance needs to identify separately after the purchase has already progressed. Budget control visibility when a Purchase Order exceeds the available budget. Why This Matters When budget exceptions are identified directly within the purchasing process, users have greater visibility into the financial implications of a purchase before it proceeds through the final control process. Finance and Budget Revision An over-budget Purchase Order requires a different level of financial consideration from a Purchase Order that falls within the available budget. The implementation establishes the foundation for Finance to handle the budget revision process and ensures that an expenditure requiring additional budget consideration is not treated in the same way as a transaction that already has sufficient budget available. The budget-control framework therefore connects: Purchase Order → Budget Evaluation → Budget Revision, if Required → Final Approval The Purchase Order provides … Continue reading How an Abu Dhabi-Based Diversified Holding Company Built a Budget-Controlled Procurement Process in Dynamics 365 Business Central – Part 2 →

Predicting the Demand: Automating Demand Forecasting in Dynamics 365 Business Central Using Azure Logic Apps, Data Lake, and Databricks Summary Knowing how many products to keep in warehouses is tough for manufacturers and distributors. During busy seasons, customer orders can jump 10 times higher than normal. When teams rely on manual spreadsheets, they often run out of products or buy too much and run out of storage space. This article explains a simple, automated solution built with Microsoft Dynamics 365 Business Central, Microsoft Azure, and Azure Databricks. Table of Contents The Problem: Swings in Customer Demand The 5-Step Solution Overview How Data is Collected and Cleaned (Medallion) How the Prophet Forecasting Model Works Clear Decision-Making with Forecasted Metrics Real Benefits for Businesses Frequently Asked Questions What You Will Learn Why manual spreadsheets and static inventory numbers fail when demand spikes. How Azure Logic Apps fetches data from Business Central automatically by using scheduled triggers. How raw records are organized into Bronze, Silver, and Gold layers. How the Prophet model forecasts demand using yearly trends and weekly patterns. How dynamic safety stock gives purchasing teams clear replenishment recommendations. 1. The Problem: Swings in Customer Demand Most manufacturers and distributors face a big challenge: customer demand is not steady throughout the year. Some months are quiet, while other months bring huge surges in orders. Season Months Demand Level What Happens Peak Busy Season June – August 8x – 10x Surge Huge spike in customer orders. Suppliers take longer to deliver, risking major stockouts. Mid-Year Rush January 3x – 4x Normal Quick wave of replacement orders and new account setups. Spring Planning March – May 2x Normal Customers use annual budgets to place advance orders for summer projects. Regular Season Off-Peak Months 1x Baseline Standard, steady daily orders. Why Traditional Methods Fail: Static Rules: Standard ERP rules use fixed inventory numbers all year. These are too small for busy seasons (causing stockouts) and too large for slow seasons (wasting money). Longer Supplier Delays: When everyone orders at once during peak seasons, suppliers take weeks longer to deliver parts. Full Warehouses: Storing large boxes during slow months takes up valuable warehouse space and ties up cash. Manual Spreadsheet Errors: Planning teams spend hours copying and pasting data into Excel spreadsheets without automated forecasting tools. “You don’t need to replace your ERP system. By adding automated cloud forecasting with Azure and Databricks to Dynamics 365 Business Central, past sales history turns into clear, actionable purchasing foresight.” 2. The 5-Step Solution Overview To solve this, we created an automated pipeline that connects daily ERP transactions to cloud forecasting and delivers clear inventory planning targets. How the Automated Flow Works 1 Dynamics 365 Business Central Holds daily sales, purchases, items, and warehouse records. ↓ 2 Azure Logic Apps (Scheduled Ingestion) Fetches data from Business Central automatically by using scheduled triggers without slowing down the ERP system. ↓ 3 Azure Data Lake (Cloud Storage) Stores all historical files securely in one central place. ↓ 4 Azure Databricks (Prophet Model) Cleans the data, runs Prophet forecasting models, and calculates the forecasted buffer stock needed for every item. ↓ 5 Visual Reports in Power BI Forecasted demand and recommended safety stock are displayed in Power BI reports for clear decision-making. 3. How Data is Cleaned & Organized (Bronze, Silver, Gold) In Azure Databricks, data moves through three simple stages known as the Medallion Architecture: Bronze Layer Raw Data Stores exact copies of daily files directly from Business Central (sales, purchases, items, warehouses). Keeps a complete, untouched history so nothing is ever lost. Silver Layer Cleaned Data Fixes missing dates, removes duplicates, and standardizes item numbers across all warehouses. Separates real customer orders from internal warehouse transfers. Gold Layer Forecasting Results Combines daily sales into clear trends and calculates forecasted stock targets for each product. Ready to feed interactive Power BI reports for planners and stakeholders. 4. How the Prophet Forecasting Model Works The Prophet forecasting model analyzes four key factors from past sales: The 3 Things the Model Learns: Overall Growth: Is customer demand growing year over year? Yearly Seasons: Which months have huge order spikes, and which months are quiet? Weekly Patterns: Do customers place most orders on weekdays compared to weekends? By combining these patterns, the system calculates the recommended safety stock for every item and warehouse: Forecasted Safety Stock: The recommended buffer quantity to keep on hand to protect against unexpected surges or supplier delivery delays. 5. Clear Decision-Making with Forecasted Metrics Instead of relying on guesswork in disconnected spreadsheets, supply chain planners have clear, data-driven targets calculated by Azure Databricks. These forecasted metrics give purchasing and warehouse managers actionable recommendations: Projected Demand: Forward-looking estimates of how many units customers will need in upcoming months. Early Order Timing: Clear signals on when to order from suppliers before peak seasons begin. Warehouse Stock Balancing: Guidance on how much inventory to position across regional warehouse hubs. 6. Real Benefits for Manufacturers Order 6–8 Weeks Ahead Purchasing teams get early warnings before big busy seasons, allowing them to book orders before supplier queues fill up. Balanced Warehouses Items are placed in the right regional warehouses closest to where customers will buy them. More Warehouse Space Bulky products arrive only when needed, keeping aisles clear and reducing expensive storage costs. Data-Driven Planning No more spending days building complicated formulas in Excel. Machine learning provides reliable demand curves and inventory targets. 7. Frequently Asked Questions (FAQ) 1 Will this slow down Business Central for daily users? No. Data is copied automatically during quiet nighttime hours into Azure. All calculations happen in the cloud, so Business Central stays fast and responsive for everyday business. 2 Why use the Prophet model instead of standard ERP reorder rules? Standard ERP rules use one fixed number for the entire year. The Prophet model automatically adapts to upcoming seasons, supplier lead times, and sales trends. 3 How do planning teams use these calculated metrics? Planning and purchasing teams access these forecasted metrics directly through interactive Power … Continue reading Predicting the Demand: Automating Demand Forecasting in Dynamics 365 Business Central Using Azure Logic Apps, Data Lake, and Databricks →

Summary 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 →

This article demonstrates how to build a reusable Generic Data Deletion Utility in Microsoft Dynamics 365 Business Central that allows administrators and developers to safely delete individual records from any table using primary key values. Instead of creating separate utilities for different tables, this generic solution leverages RecordRef, FieldRef, and KeyRef to dynamically access Business Central tables at runtime. Summary Developed a generic data deletion utility for Microsoft Dynamics 365 Business Central. Enabled administrators to delete records from supported Business Central tables without creating table-specific code. Used RecordRef, FieldRef, and KeyRef to dynamically identify primary keys at runtime. Provided lookup functionality for selecting Business Central tables through the standard Object List. Added confirmation prompts before deletion to reduce accidental data loss. Designed the solution as a Processing Only report for administrative maintenance activities. Created a reusable framework that can be extended for future data maintenance utilities. Table of Contents 1. Introduction 2. The Business Problem 3. The Solution 3.1 Selecting the Business Central Table 3.2 Providing the Primary Key Values 3.3 Dynamically Identifying the Record 3.4 Confirming and Deleting the Record 3.5 Security and Permissions 4. Implementation 5. Business Impact 6. Frequently Asked Questions 7. Conclusion 1. Introduction Organizations in the pharmaceutical manufacturing industry frequently perform data cleanup activities during implementation, testing, data migration, and ongoing production support. Deleting specific records from Microsoft Dynamics 365 Business Central tables often requires custom-built utilities or direct database interventions, making the process time-consuming, less flexible, and difficult to maintain. To address this requirement, a Generic Data Deletion Utility was developed for a leading pharmaceutical manufacturing organization using Microsoft Dynamics 365 Business Central. By leveraging RecordRef, FieldRef, and KeyRef, the solution enables authorized users to dynamically locate and delete records from any Business Central table using primary key values without requiring table-specific deletion logic. This article explains the architecture of the solution, the AL programming concepts used, and how the framework provides a reusable and controlled approach for administrative data maintenance across standard and custom Business Central tables. 2. The Business Problem During implementation, testing, data migration, and production support activities, the organization frequently required the deletion of specific records from various Microsoft Dynamics 365 Business Central tables. Since each table has its own structure, fields, and primary key definitions, performing these deletions typically required custom-built utilities or temporary development efforts. This table-specific approach increased development effort, reduced operational efficiency, and made routine data maintenance activities more complex. The organization required a single reusable framework that could dynamically work with multiple Business Central tables without requiring separate deletion logic for each table. The Objective: Develop a generic data deletion utility that enables authorized users to safely identify and delete records from any Business Central table using primary key values while maintaining control and minimizing the risk of accidental data loss. 3. The Solution To simplify administrative data maintenance, a Generic Data Deletion Utility was developed in Microsoft Dynamics 365 Business Central. The solution provides a centralized utility that enables users to delete records from multiple tables without requiring separate deletion programs for each table. The tool allows authorized users to select a Business Central table, provide the required primary key values, locate the corresponding record dynamically, and delete it after user confirmation. The design supports both standard and custom Business Central tables while providing a flexible and reusable approach for controlled data management. The following sections describe the key components of the solution and explain how each feature contributes to making the tool dynamic, secure, and easy to maintain. 3.1 Selecting the Business Central Table The first step in the deletion process is selecting the Business Central table that contains the record to be removed. The request page provides fields for the Table Number and Table Name, allowing the user to identify the required standard or custom table. Instead of requiring users to manually remember table numbers, the Table No. field provides a drill-down option. This opens the standard All Objects with Caption page and filters the available objects to display only Business Central tables. TableObjects.SetRange( “Object Type”, TableObjects.”Object Type”::Table); if PAGE.RunModal( PAGE::”All Objects with Caption”, TableObjects) = Action::LookupOK then begin TableId := TableObjects.”Object ID”; TableCaption := TableObjects.”Object Caption”; end; Once a table is selected, the solution stores its object ID in the Table No. field and automatically displays the corresponding table name. This helps users verify that the correct table has been selected before providing the primary key values. The Table Name field is kept non-editable because its value is automatically retrieved from the selected Business Central table. Figure 1: Filtered Data Deletion request page for selecting the table and entering primary key values 3.2 Providing the Primary Key Values After selecting the required table, the user must provide the primary key values that uniquely identify the record to be deleted. Since each Business Central table has its own primary key structure, the solution supports primary key. The first key value is entered in the Primary Key field, while the Key 2 and Key 3 fields are available for tables that use multiple fields as part of their primary key. This enables the tool to locate records accurately regardless of the table structure. For example, a Customer record requires only the Customer No., whereas a Sales Line record requires multiple values such as the Document Type, Document No., and Line No. By supporting multiple key fields, the same utility can work across a wide range of standard and custom Business Central tables. Figure 2: Entering the primary key values required to uniquely identify a Business Central record. 3.3 Dynamically Identifying the Record Unlike conventional deletion utilities that are developed for a single table, this solution dynamically identifies records irrespective of the selected Business Central table. It uses the RecordRef, KeyRef, and FieldRef data types to work with table metadata at runtime, making the solution completely generic. After the user selects a table and enters the primary key values, the tool opens the selected table dynamically, retrieves its primary key definition, and applies … Continue reading Simplifying Record Management in Microsoft Dynamics 365 Business Central with a Generic Data Deletion Utility for Titan Labs →

Summary Approval workflows in Microsoft Dynamics 365 Business Central provide a structured mechanism for multi-level document approvals. However, the standard approval email often lacks sufficient business context, making it difficult for approvers to take quick and informed decisions. In this implementation, for a Maldives-based loan and financial services organization, instead of modifying the core approval engine, we enhanced only the notification layer using Business Central’s event-driven architecture. The solution intercepts standard approval notifications and replaces them with a custom HTML email containing payment details and direct navigation links to the Payment Journal. This approach ensures the standard workflow remains fully intact while significantly improving the approval experience through richer and more actionable communication. Standard Business Central approval workflow remains unchanged. Custom HTML email notification introduced via an event-driven extension. Direct navigation to the Payment Journal enabled from the email. Faster and more informed approval decisions. Table of Contents Introduction Business Requirement Solution Overview Implementation Preview Video Business Impact Conclusion 1. Introduction Microsoft Dynamics 365 Business Central includes a powerful approval workflow engine that automates document approvals, supports multi-level approval chains, and automatically notifies approvers through email. Although the standard approval process works exceptionally well, the default email notification is intentionally simple. Approvers typically receive limited information and often need to open Business Central to locate the payment journal before they can review or approve the request. For organizations processing large volumes of financial transactions in a Maldives-based loan and financial services environment, this additional navigation slows down approvals and creates unnecessary effort. During one of our recent implementations in a Maldives-based lending and financial operations setup, the client wanted to improve the approval experience without changing Microsoft’s standard approval workflow. The objective was to retain every aspect of the existing workflow while enhancing only the email notification layer by introducing a modern, information-rich HTML email format. 2. Business Requirement The client wanted to achieve the following objectives: Preserve the standard Microsoft Dynamics 365 Business Central approval workflow. Keep all approval entries and workflow responses unchanged. Replace the standard approval email with a professional HTML email. Display important payment information directly inside the email body. Allow approvers to open the Payment Journal with a single click. Improve the overall approval experience without modifying Microsoft’s workflow engine. The primary goal was to enhance usability while maintaining full compatibility with the standard Business Central approval framework. 5. Preview Video The preview video section has been removed as per updated requirement. 6. Business Impact Implementing customized approval email notifications delivered several operational benefits while keeping Microsoft’s standard workflow engine fully intact. Improved User Experience Approvers receive all important payment information directly within the email, reducing the need to navigate through Business Central before reviewing requests. Faster Approval Decisions Direct navigation to the Payment Journal enables approvers to review and process approvals much more quickly. Better Visibility Payment amount, vendor information, posting date, and approval sequence are immediately visible, making approvals easier and reducing the chance of overlooking important details. Easier Document Verification Supporting invoice attachments can be reviewed directly from the Payment Journal before approving payments. Upgrade-Friendly Solution Because the implementation relies entirely on standard Microsoft Dynamics 365 Business Central events, no modifications are made to the core approval engine, ensuring future upgrades remain smooth and low-risk. 7. Conclusion Microsoft Dynamics 365 Business Central’s event-driven extensibility model allows developers to significantly enhance the user experience without modifying standard application logic. By leveraging the OnBeforeCreateApprovalEntryNotification event, we replaced the default approval email with a professional HTML notification while preserving the complete standard approval workflow. Approvers now receive richer payment information, can navigate directly to the Payment Journal, and have quick access to supporting documents—all without altering Microsoft’s workflow engine. This implementation demonstrates how targeted customizations can greatly improve productivity and usability while remaining fully aligned with Microsoft’s recommended extension development practices. Ready to modernize your Business Central approval experience? Standard approval emails often lack context, forcing approvers to open Business Central repeatedly just to review basic payment details. With event-driven customization, you can transform these notifications into rich, structured HTML emails that improve decision-making speed and user experience. CloudFronts helps organizations extend Microsoft Dynamics 365 Business Central with smart, upgrade-safe customizations, workflow enhancements, and finance automation solutions. For more information, reach out at transform@cloudfronts.com.