How a Maldives-Based Loan Firm Streamlined Multi-Level Payment Approvals with Microsoft Dynamics 365 Business Central

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.

Understanding the Business Requirement

The Payment Journal required several approval stages, with different rules at each level.

The intended business process was:

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.

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.

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:

1. Workflow User Groups
2. Approval Entries
3. Approval statuses
4. Sending approval requests
5. Cancelling approval requests
6. Workflow progression

Rebuilding all of this would have introduced unnecessary complexity and additional maintenance.

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:

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:

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:

1. User ID
2. Approval sequence
3. Document or record reference
4. Approval date and time

If Approver D performs the action, the log retains Approver D as the actual approver even if the surrounding workflow entries are subsequently updated during completion of the stage.

For reporting purposes, the Payment Voucher can therefore use this log instead of assuming that every Approval Entry with an Approved status represents the user who actually performed the approval.

Fig: Actual Approver Log capturing the user who performed the approval action

Why Checked By Was Kept Separate

The first stage of the process had a slightly different purpose from the formal approval workflow.

Before a payment could enter the standard approval process, it needed to be reviewed and checked by one authorized user.

Rather than forcing this activity into another standard workflow sequence, we implemented a separate Checked By process.

Authorization is still controlled through a Workflow User Group such as CHECKEDBY, which means administrators can decide who is allowed to perform the check without hardcoding individual user accounts.

This provides full control over the any-one-user behavior while continuing to use Business Central setup to manage authorized users.

Fig: Custom Checked By process before the standard approval workflow begins.

Automatic Transition to Standard Approval

An important usability decision was to avoid requiring the Finance user to perform another manual Send for Approval action after the Checked By stage was completed.

Once Checked By is approved, the system automatically triggers the standard approval request.

From the user’s perspective, the entire process therefore feels like one continuous approval journey even though it combines custom and standard approval components. :contentReference[oaicite:8]{index=8}

Improving Payment Voucher Traceability

The custom logs became particularly valuable when preparing the final Payment Voucher.

The business needed the voucher to show the actual users involved at each stage rather than simply displaying generic approval statuses.

This provides a much clearer audit trail than relying entirely on the standard Approval Entry table. :contentReference[oaicite:9]{index=9}

Fig: Payment Voucher showing the actual users involved in the approval process.

Final Solution Architecture

The final design combines custom pre-checking, the standard Business Central workflow engine, targeted approval customization, and separate Internet Banking validation.

This architecture allowed us to extend the standard approval framework rather than replace it. Workflow User Groups continued to control authorized users, while custom logs provided the flexibility and auditability required by the business.

Preview Video

The following video provides a quick walkthrough of the multi-level payment approval process implemented in Microsoft Dynamics 365 Business Central, including the Checked By stage, workflow approvals, actual approver tracking, and the overall approval flow.

Business Impact

1. Controlled Payment Processing: Payments cannot bypass the required Checked By and approval stages.
2. Flexible Any-One Approval: Authorized users can complete approval stages without requiring unnecessary approvals from every user in the group.
3. Better Auditability: The solution records the actual user who performs each important approval action.
4. Reduced Manual Steps: Approval automatically moves from Checked By into the standard workflow without requiring another submission action.
5. Centralized User Management: Workflow User Groups continue to manage authorized users without hardcoding user IDs.
6. Improved Payment Voucher Reporting: The final voucher can identify the actual users involved across Checked By, workflow approval, and Internet Banking approval.

Frequently Asked Questions

Conclusion

The most important lesson from this implementation was that complex approval requirements do not always require replacing the standard Business Central workflow engine.

For this Maldives-based loan firm, the right approach was to keep the standard approval framework wherever it already met the business requirement and introduce targeted customizations only where additional control was needed.

Workflow User Groups continued to manage authorized users, standard workflow functionality continued to control approval progression, while custom Checked By and Actual Approver logs provided the flexibility and auditability required by the payment process.