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 →

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 →

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 →

Summary This article explores how Emirates Consortium LLC expanded its use of Microsoft Dynamics 365 Business Central beyond finance to establish a more structured procurement process. Previously, budgets were managed manually through Excel and some procurement activities were performed outside the ERP. The implemented solution introduced a customized Purchase Request-to-Purchase Order process covering the initial requirement, approval, vendor and item selection, Purchase Quotes, Purchase Orders, and budget validation. The process also carries important procurement information such as Department, Category, Subcategory, Location, and Dimensions throughout the purchasing cycle, creating greater visibility, control, and traceability. Table of Contents Introduction From Finance-Only Usage to Broader Business Central Adoption Starting Procurement with a Purchase Request Keeping Supporting Documents with the Request Approval Before Procurement Moves Forward Turning an Approved Request into Purchase Quotes One Purchase Request Can Become Multiple Purchase Quotes Carrying Information Forward From Purchase Quote to Purchase Order Bringing Budget Visibility into the Purchase Order The Bigger Picture Conclusion 1. Introduction For many organizations, procurement doesn’t begin with a Purchase Order. It begins much earlier—with a business user identifying a requirement, requesting approval, obtaining quotations, selecting suppliers, and ensuring that the purchase is properly categorized and authorized. When these steps happen outside the ERP, organizations can end up relying on spreadsheets, emails, manual approvals, and disconnected procurement activities. This makes it difficult to maintain a consistent process and creates additional effort for both procurement and finance teams. This was the challenge addressed for Emirates Consortium LLC. Emirates Consortium had been a long-standing client and had primarily been using the Finance capabilities of Microsoft Dynamics 365 Business Central. As part of its next stage of ERP adoption, the organization wanted to expand its use of Business Central and bring more of its procurement activities into the system. One of the key areas was procurement and budget control. Previously, budgets were being managed manually through Excel, while some procurement activities were being performed outside the ERP. The objective was therefore not simply to introduce Purchase Orders into Business Central, but to establish a more structured procurement process—from the initial purchase requirement through approval, supplier selection, quotation, and Purchase Order creation. The Implemented Solution The resulting solution introduced a customized Purchase Request-to-Purchase Order process within Business Central, with approval controls and budget information carried throughout the purchasing cycle. 2. From Finance-Only Usage to Broader Business Central Adoption Emirates Consortium’s journey is an example of how an organization can progressively expand its use of Business Central. Rather than limiting Business Central to financial transactions, the implementation extends the platform into operational procurement. The process starts with a Purchase Request, which becomes the starting point for the procurement lifecycle. Procurement Process Flow Purchase Request → Approval → Vendor & Item Selection → Purchase Quote → Purchase Order → Budget Validation → PO Approval This approach brings the procurement process into the same ERP environment that already supports the organization’s financial operations. The implementation specifically carries important procurement classification information—such as Department, Category, Subcategory, Location, and Dimensions—through the process so that it can subsequently participate in budget validation. 3. Starting Procurement with a Purchase Request The first step in the process is the creation of a Purchase Request. Instead of starting directly with a Purchase Order, the requester first communicates what the business needs. The Purchase Request captures information such as: Department Category Subcategory Location Item or service required Quantity Unit of Measure Remarks Supporting documents For item-based requests, users can also check Item Availability before determining the quantity that needs to be purchased. A Clear Separation of Responsibilities The process creates an important separation between: “What does the business need?” and “Which supplier should we purchase it from?” That distinction is particularly useful in organizations where a requester may not be responsible for supplier selection. 4. Keeping Supporting Documents with the Request Procurement requests often require supporting information. For example, a requester may need to provide specifications, internal documentation, requirement details, or other reference material. The implemented process provides an Attachments option on the Purchase Request. Importantly, these attachments remain associated with the individual Purchase Request. They are not automatically transferred to the subsequent Purchase Quote or Purchase Order. Two Types of Supporting Information Documents supporting the original request. Documents supporting later purchasing or budget decisions. This distinction becomes particularly important in the over-budget scenario discussed in Part 2. 5. Approval Before Procurement Moves Forward Once the Purchase Request has been created, it cannot simply move directly into purchasing. The requester submits it using Send Approval Request. A dedicated Purchase Request approval workflow was configured for the process. The workflow supports: Approval Rejection Cancellation Delegation Approval notifications The Purchase Request progresses through statuses such as: Approval Status Flow Open → Pending Approval → Approved / Rejected Only after the required approval is completed can the request proceed to the quotation stage. This provides a controlled starting point for procurement. The organization doesn’t simply record what was purchased; it also records who requested it and who approved the requirement. 6. Turning an Approved Request into Purchase Quotes Once the Purchase Request has been approved, the next step is supplier sourcing. The implementation allows users to create a Purchase Quote directly from the approved Purchase Request. When the user selects Create Purchase Quote, Business Central opens a Vendor and Item Selection page based on the Purchase Request lines. This is particularly useful when a single request contains multiple items that may be sourced from different vendors. 7. One Purchase Request Can Become Multiple Purchase Quotes Consider a simple example. Purchase Request Line Selected Vendor Result Item A Vendor 1 Purchase Quote – Vendor 1 Item B Vendor 1 Purchase Quote – Vendor 1 Item C Vendor 2 Purchase Quote – Vendor 2 Item D Vendor 3 Purchase Quote – Vendor 3 Instead of forcing all four items into one quotation, the system groups the lines based on the selected vendors. The Result Purchase Quote 1 → Vendor 1 Purchase Quote 2 → Vendor 2 Purchase Quote 3 → … Continue reading How an Abu Dhabi-Based Diversified Holding Company Built a Budget-Controlled Procurement Process in 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 This blog explores how the Payables Agent in Microsoft Dynamics 365 Business Central (2025 Release Wave 1) transforms traditional Accounts Payable (AP) processes by leveraging AI to automate invoice processing for a Netherlands-based non-profit organization. Traditionally, finance teams spend considerable time manually entering invoice information, validating vendors, creating purchase invoices, and ensuring document accuracy. As invoice volumes grow, these repetitive tasks become increasingly time-consuming and susceptible to human error. The Payables Agent introduces an AI-assisted approach that automatically monitors a designated mailbox, extracts invoice information from PDF documents, identifies vendors, creates draft purchase invoices, and routes them for supervisor review before posting. This blog explains: The challenges associated with traditional Accounts Payable processing. How the Payables Agent works in Business Central. The configuration steps required to activate the agent. The end-to-end AI-powered invoice processing workflow. The business impact of automating Accounts Payable. Table of Contents Customer Scenario Business Challenges Solution Overview Solution Architecture Configuring the Payables Agent AI-Powered Invoice Processing Workflow Supervisor Review Process Business Impact Disclaimer FAQs Conclusion 1. Customer Scenario A finance department within a Netherlands-based non-profit organization processing hundreds of vendor invoices each month was experiencing increasing pressure to improve efficiency while maintaining financial accuracy and compliance. Invoice processing relied heavily on manual data entry. Finance users were responsible for opening incoming emails, downloading invoice PDFs, entering purchase invoice information into Business Central, validating vendors, and ensuring data accuracy before posting transactions. As invoice volumes continued to increase, the organization needed a smarter and more scalable solution capable of reducing repetitive work without compromising financial controls. The organization decided to leverage the new AI-powered Payables Agent introduced in Microsoft Dynamics 365 Business Central 2025 Release Wave 1. 2. Business Challenges The existing Accounts Payable process presented several operational challenges. 1. Manual Invoice Entry Finance users manually entered invoice information into Business Central, increasing processing time and effort. 2. Vendor Validation Each invoice required verification against existing vendor records before processing could continue. 3. Repetitive Administrative Work Processing hundreds of invoices each month resulted in significant administrative overhead and reduced productivity. 4. Human Errors Manual entry increased the likelihood of incorrect invoice values, vendor selection mistakes, and duplicate invoice processing. 5. Delayed Invoice Processing Large invoice volumes often delayed purchase invoice creation and subsequent payment processing. Business Need The organization required an intelligent solution capable of automating repetitive Accounts Payable activities while allowing finance teams to retain complete control over invoice validation and final approvals. 3. Solution Overview Microsoft introduced the Payables Agent as part of the AI capabilities available in Microsoft Dynamics 365 Business Central 2025 Release Wave 1. The agent is designed to streamline Accounts Payable operations by automating repetitive invoice processing tasks while maintaining financial controls. The Payables Agent continuously monitors a configured mailbox for incoming vendor invoice PDFs. Once a new invoice is detected, it automatically analyzes the document, extracts key information using AI, identifies the appropriate vendor, and prepares a draft purchase invoice for review. Once an invoice is received, the Payables Agent automatically performs the following tasks: Reads invoice information from the PDF document. Identifies the corresponding vendor. Extracts invoice header and line details. Creates a draft Purchase Invoice in Business Central. Notifies supervisors that a draft invoice is ready for review. Allows users to validate, finalize, and post the purchase invoice. Key Benefit: Rather than replacing finance professionals, the Payables Agent acts as an intelligent assistant that automates repetitive Accounts Payable activities while preserving financial governance, approval controls, and auditability. 4. Solution Architecture The Payables Agent follows a streamlined AI-assisted workflow that automates the processing of vendor invoices while ensuring finance teams retain full control over validation and posting. From receiving an invoice to creating a draft purchase invoice, each stage is designed to reduce manual effort and improve processing efficiency. Process Flow Vendor emails the invoice PDF to the designated mailbox. The invoice is received in the configured mailbox. The Payables Agent continuously monitors the mailbox for new invoices. AI Document Intelligence extracts the invoice information. The system matches the invoice with an existing vendor. A draft Purchase Invoice is automatically created. A supervisor reviews and validates the extracted information. The Purchase Invoice is finalized and posted into Business Central. Architecture Overview: The Payables Agent combines AI-powered document processing, automated vendor matching, and draft purchase invoice creation with human review to deliver a faster, more accurate, and well-governed Accounts Payable process. Core Components The following components work together to automate the invoice processing lifecycle while ensuring appropriate financial controls and governance. Component Purpose Vendor Email Sends vendor invoice PDFs to the designated mailbox. Configured Mailbox Receives incoming vendor invoices for processing. Payables Agent Monitors the mailbox and orchestrates the AI-driven invoice processing workflow. AI Document Intelligence Extracts invoice details such as vendor information, invoice number, dates, amounts, and line items. Vendor Matching Engine Matches extracted invoice data with existing vendor records in Business Central. Draft Purchase Invoice Automatically creates a draft purchase invoice using the extracted invoice information. Supervisor Review Allows finance users to validate the extracted information before posting. Purchase Posting Finalizes and posts the approved purchase invoice into Business Central. Key Takeaway: By combining AI-powered document intelligence with Business Central’s standard purchasing process, the Payables Agent minimizes manual data entry while ensuring every invoice is reviewed and validated before posting. 5. Configuring the Payables Agent Step 1 – Open the Payables Agent From the top-right corner of Microsoft Dynamics 365 Business Central, select the AP (Accounts Payable) icon to access the Payables Agent. Step 2 – Activate the Agent Enable the Payables Agent to begin AI-assisted invoice processing. Once activated, the agent becomes available to monitor incoming invoices and assist with the automatic creation of purchase invoices. Step 3 – Connect the Mailbox Configure the mailbox that will receive vendor invoice PDFs. The Payables Agent continuously monitors this mailbox and automatically imports incoming invoice documents as they arrive. After successful processing, the invoices are archived for future reference within Business Central. Step 4 – Vendor Matching … Continue reading Transforming Accounts Payable with AI: Configuring the Payables Agent in Microsoft Dynamics 365 Business Central for the Cradle to Cradle Products Innovation Institute (C2CPII) →

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.

As businesses scale, payroll complexity grows bringing challenges around employee data, attendance, compensation structures, and compliance. Manual processes not only consume valuable time but also increase the risk of costly errors. The Zoho People-FNO integration transforms payroll into a streamlined, automated process, ensuring accurate salary calculations, seamless data synchronization, and complete transparency across HR and finance operations. We recently implemented this solution for a global manufacturing hardware enterprise, enabling them to automate payroll workflows, eliminate manual data reconciliation, improve payroll accuracy, and reduce administrative overhead. The integration provided a scalable foundation for managing a growing workforce while maintaining compliance and enhancing the employee experience through faster, more transparent payroll processing. For organizations focused on operational efficiency and sustainable growth, this integration delivers measurable business value from day one. Understanding the Architecture of Zoho and FNO Integration The integration between Zoho People and FNO involves a clear, structured workflow. Below is an overview of the steps involved: This architecture ensures a smooth flow of data between Zoho and FNO, simplifying payroll management for businesses of all sizes. Key Advantages of Zoho and FNO Integration The integration between Zoho People and FNO streamlines payroll management, providing several key benefits: Effortless Payroll Management for Growing Businesses To conclude, efficient payroll management is essential for any growing business. By integrating Zoho People with FNO, businesses can automate payroll processes, ensure accurate calculations, and provide employees with easy access to their payslips. The seamless data flow, real-time updates, and reduced manual intervention significantly improve operational efficiency and transparency. If you’re ready to optimize your payroll system, now is the time to take action. Embrace the Zoho and FNO integration to simplify your processes, reduce errors, and create a transparent payroll system that benefits both your employees and your organization. Contact us today to learn how this integration can simplify your payroll management process. Reach out at transform@cloudfronts.com.

Summary 1. Identified the operational and strategic costs of fragmented Procure-to-Pay (P2P) processes across procurement and finance functions.2. Highlighted how manual, siloed workflows lead to approval bottlenecks, data inconsistencies, and invoice disputes.3. Explained how ERP integration eliminates manual handoffs by connecting procurement and finance into a unified, data-consistent system.4. Demonstrated the business value of real-time visibility across spending, commitments, and vendor payment status.5. Positioned a strong P2P process as a direct driver of cost efficiency, financial control, and business agility. Table of Contents 1. Introduction2. The Problem3. What Changes with Integration4. What Businesses Gain5. Conclusion Introduction We implemented this solution for a leading North American commercial vehicle manufacturer with complex multi-entity operations, where disconnected procurement and finance processes had a significant impact on business performance. Procurement and finance are central to business performance, yet in many organisations they continue to operate in silos. Each function manages its own data, workflows, and priorities, creating gaps that undermine efficiency, accuracy, and leadership visibility across the organisation. This disconnect is not merely an internal inconvenience. Over time, it leads to missed deadlines, strained vendor relationships, and financial reporting that lags the pace at which business decisions need to be made. For organisations looking to scale or compete in demanding markets, these gaps represent a genuine strategic risk. The Procure-to-Pay (P2P) cycle sits at the centre of this challenge. Spanning everything from raising a purchase request to issuing final payment, it is where delays and mismatches are most visible, and where the cost of inefficiency is most directly felt by both operational teams and leadership. The Problem Figure 1: Procure-to-Pay Cycle Problems Without Integration vs. Outcomes with ERP Integration Despite advances in enterprise technology, many organisations still rely on fragmented, manual approaches to procurement and finance. Email-based approval chains, spreadsheet-driven tracking, and disconnected systems remain common each introducing friction that slows the P2P cycle and reduces data reliability. Approval bottlenecks cause purchase orders to stall, disrupting timelines and delaying downstream activities. Duplicate data entry creates inconsistencies that consume significant time to identify and correct. Invoice mismatches between what was ordered, received, and billed result in payment disputes that erode vendor trust and divert finance team effort away from higher-value work. Beyond day-to-day operational impact, the absence of real-time visibility creates a deeper structural problem. Leadership is left making spending decisions based on stale or incomplete data, budget adherence is difficult to monitor, and bottlenecks go undetected until they have already caused delays. The organisation becomes reactive responding to problems rather than preventing them. How the Integration Works Figure 2: ERP Integration Architecture Source Systems, Azure Logic Apps Middleware, and Target D365 Modules The integration follows an event-driven model a design approach in which processes are triggered by specific business events rather than scheduled batch runs or manual interventions. This shift has significant implications for speed, accuracy, and responsiveness throughout the P2P cycle. When a purchase request is created, a vendor record is updated, or an invoice is submitted, the integration layer responds immediately. Data is extracted through secure, authenticated APIs, validated against predefined rules, transformed into the format required by the target system, and pushed into the ERP without human intervention and typically within seconds. This real-time responsiveness eliminates the latency inherent in batch-based integrations, where data may be hours out of date by the time it reaches the systems that need it. For procurement and finance teams working to tight timelines, that difference is material and directly impacts how quickly decisions can be made and acted upon. What Changes with Integration ERP integration addresses these challenges by connecting procurement and finance into a unified, data-consistent system. Rather than information being passed manually between teams or re-entered across platforms, it flows automatically triggered by real business events and governed by standardised rules applied consistently across the organisation. When a purchase request is raised, all relevant data is immediately available to every stakeholder in the approval chain without manual handoffs or follow-up emails. Approvals are routed automatically based on predefined rules, timelines are enforced, and exceptions are flagged in real time rather than discovered days later during reconciliation. Standardisation is another significant benefit. With all users working from the same data and the same process definitions, the inconsistencies that arise from team-specific workarounds are eliminated. Audit trails are complete and reliable, compliance becomes easier to demonstrate, and the system can adapt as the organisation evolves without requiring constant manual adjustment. What Businesses Gain The benefits of a well-integrated P2P system extend across every level of the organisation. Procurement teams process requests and approvals faster, with significantly less administrative burden. Finance teams reconcile invoices more efficiently and gain clearer visibility into outstanding commitments and cash flow. Vendors receive timely, accurate payments improving commercial relationships and, over time, creating opportunities for preferential terms and stronger partnerships. At the leadership level, integration delivers something particularly valuable: reliable, real-time insight. Executives can monitor procurement activity, track budget adherence, and assess financial performance without waiting for manually compiled reports. This enables faster course correction, more confident planning, and better alignment between procurement strategy and broader business objectives. Organisations in high-volume, multi-entity environments such as Daimler Truck North America, a leading North American commercial vehicle manufacturer operating brands including Freightliner, Western Star, and Thomas Built Buses across complex, multi-geography supply chains benefit most significantly. In industries where operational precision and cost control are non-negotiable, the ability to manage procurement and payments with full visibility and minimal friction is a genuine competitive differentiator. To conclude, a well-designed integration does more than automate existing steps it transforms the Procure-to-Pay cycle into a fast, reliable, and transparent process that serves operational teams, finance leadership, and the wider business alike. The principles outlined in this article event-driven architecture, modular parent-child orchestration, delta processing, and comprehensive logging form the foundation of an integration that can scale with the business and adapt to evolving requirements. For organisations operating in complex, high-volume environments, this is not a technical upgrade. It is a strategic enabler. Ready to modernize … Continue reading From Approval Bottlenecks to Real-Time Visibility: Transforming Procure-to-Pay Through ERP Integration for a Leading North American Commercial Vehicle Manufacturer →