Automating Finance Approval Workflows with Microsoft Power Automate: A Malaysian Example

How-to guide

The cost of manual finance approvals

Many Malaysian finance teams still route purchase requisitions, payment releases and expense claims through email threads, printed forms or messaging apps. An approver may be travelling, in back-to-back meetings or simply not checking a particular inbox, and the request waits. When someone finally does check that request, there is often no consistent record of who approved what, under which authority limit, or when — which becomes a problem the moment an auditor, a bank, or a tax authority asks for evidence.

Common symptoms of a manual approval process include:

Inconsistent application of approval thresholds — a junior finance executive occasionally approving a payment that should have gone to a director.
No formal cover when an approver is on leave, resulting in either stalled approvals or informal, undocumented sign-offs by someone else.
Approval evidence scattered across email, chat messages and paper forms, making it slow to reconstruct a decision trail during an audit or internal review.
Manual re-keying of approved amounts into the accounting system, introducing transcription risk.

None of this means the underlying controls are wrong — a documented monetary-threshold policy and a named approver hierarchy are sound practice. The gap is usually in how consistently the process is followed day to day, not in the policy itself. Workflow automation can help close that gap without changing who is accountable for the decision.

What Microsoft Power Automate does for approvals

Microsoft Power Automate is part of the Microsoft Power Platform. It is a low-code automation service that lets an organisation connect triggers (an event, such as a new record or a submitted form) to a sequence of actions (such as routing a request to an approver, updating a record, or sending a notification) without writing custom application code.

For approval scenarios specifically, Power Automate provides a built-in Approvals connector with a "Start and wait for an approval" action. According to Microsoft Learn documentation on getting started with approvals, this connector supports two approval types:

First to respond — the outcome of whichever approver responds first (approve or reject) is treated as final. This suits a single-authority sign-off.
Everyone must approve — every named approver must approve for the request to be considered approved; a single rejection ends the request regardless of the other responses. This suits requests that require agreement from more than one function, such as finance and the requesting department.

The connector also supports reminders that prompt an approver who has not yet responded, and an expiration or deadline after which the organisation can define what happens next, including notifying a different recipient. Depending on the workflow and the approver's email client, approval requests can arrive as actionable messages that let the approver respond with Approve or Reject directly from Outlook, or through the centralised approvals experience in Microsoft Teams and the Power Automate portal.

Power Automate connects to the systems Malaysian finance teams already use for source data and evidence, including:

Dynamics 365 Business Central — Microsoft's own connector documentation, Power Automate integration overview for Business Central, describes triggers such as "When a record is created" and actions that can read or update purchase, sales and general ledger records, so an approval flow can start from a Business Central document and write the outcome back to it.
SharePoint — document libraries can trigger a flow when a supporting file (an invoice scan or a requisition form) is added.
Outlook — approval requests and outcome notifications can be sent and, where actionable messages are supported, responded to directly by email.
Microsoft Teams — approvers can review and respond to pending requests inside the Teams approvals hub, which centralises approvals raised from multiple connected systems.

Power Automate approval flows support a documented sequence and a timestamped record of each response — they support a more consistent process; they do not by themselves make the underlying approval decision correct or compliant. That responsibility remains with the organisation's approval policy and the people who approve.

A worked Malaysian example: purchase-requisition and payment approval

To illustrate how the pieces fit together, consider a Malaysian trading company with a documented approval policy along these lines:

Purchase requisitions under RM5,000 — approved by the department head.
Purchase requisitions from RM5,000 up to RM50,000 — approved by the finance manager.
Purchase requisitions above RM50,000 — approved by the finance manager and then the managing director, in sequence.
Payments released against an approved purchase order follow the same threshold structure, with a separate approval step at the point of release.

A Power Automate flow supporting this policy could be structured as follows:

Trigger — a new purchase requisition is created in Dynamics 365 Business Central (using a Business Central trigger such as "When a record is created"), or a requisition form is submitted through a SharePoint or Microsoft Forms front end for teams not yet working directly in Business Central.
Condition — threshold routing — a condition action checks the requisition amount against the documented thresholds and branches the flow accordingly, rather than sending every request to the same approver regardless of value.
Approval step — for amounts under RM5,000, a single "Start and wait for an approval" action (First to respond) is sent to the relevant department head. For amounts from RM5,000 to RM50,000, the same action is sent to the finance manager. For amounts above RM50,000, two sequential approval actions run — finance manager, then managing director — so the request only reaches the second approver once the first has approved.
Delegation for absence — each approval action can be assigned to more than one recipient where the organisation's policy allows a nominated backup to act during planned leave, and a reminder action can prompt an unanswered request after a defined number of hours. Where an approver is away for an extended period, Power Automate supports reassigning pending approvals in the Approvals portal so cover does not depend on someone remembering to forward an email.
Outcome handling — a condition checks the approver's response. If approved, an update action writes the approval status, approver name and timestamp back to the Business Central record (or the source list), and the requisition proceeds to purchase order creation. If rejected, the requester is notified by Outlook email with the approver's comments, and the record is marked accordingly rather than left in limbo.
Notification — a Microsoft Teams message or Outlook email confirms the outcome to the requester and, for higher-value requests, to the finance team, so status is visible without anyone needing to ask.
Audit trail — Power Automate retains a run history for every execution of the flow, showing each action, its inputs, its outputs and its timing. Combined with the approval status, approver identity and timestamp written back into Business Central, this gives a reconstructable record of who approved what, at what threshold, and when — useful evidence during an internal review or an external audit walkthrough.

The same structure extends to a payment-release flow: instead of triggering from a new purchase requisition, the flow triggers from a payment proposal or a vendor payment batch reaching a "ready for release" status in Business Central, applies the same threshold-based routing, and writes the release approval back to the payment record before the payment run proceeds.

This is one illustrative structure, not a prescribed template. The actual thresholds, approver hierarchy, number of stages and system triggers should be built from the organisation's own documented approval policy and reviewed with its finance leadership before deployment.

Governance and control considerations

Automating an approval process changes how the process runs, not who is accountable for the decisions made within it. Before rolling out a flow like the one above, Malaysian finance teams should work through the following:

Segregation of duties — the person who raises a requisition should not also be able to approve it. This needs to be enforced through Business Central and SharePoint permissions, not only through the flow logic, since a flow can be bypassed if the underlying system does not also restrict who can act.
Approver identity and authority — approval actions should route to named individuals or Microsoft Entra security groups that reflect current signing authority, and this list needs a defined owner responsible for keeping it current as staff join, leave or change roles.
Delegation controls — where a flow allows a backup approver, the delegation arrangement itself should be documented and time-bound, rather than left as a standing, unreviewed exception.
Reconciliation to source records — approval status recorded in Power Automate run history should agree with the approval status recorded in Business Central. Periodic reconciliation between the two, even a simple spot check, helps confirm that the flow is doing what it is expected to do and that no record has been manually overridden outside the flow.
Change control over the flow itself — thresholds and approver assignments are configuration, and changes to that configuration should go through the same kind of approval and documentation as a change to a written policy, since anyone with edit access to the flow could otherwise alter a threshold without visibility.
Exception handling — define what happens when an approval expires unanswered, when an approver leaves the organisation, or when the flow itself fails to run (for example, due to a connector outage), so that a stalled flow does not silently stop payments or, conversely, allow a request to proceed without approval by default.

Automation can support more consistent application of an approval policy and produce a clearer audit trail. It does not remove the need for the organisation's finance leadership to define the policy, review exceptions and periodically test that the controls are operating as designed.

Licensing note

Not every connector used in an approval flow is available on every Power Automate licence. According to Microsoft's Power Automate licensing FAQ, the standard Approvals connector, Outlook and Teams notifications are typically available on standard connector entitlements included with many Microsoft 365 plans. The Dynamics 365 Business Central connector, however, is classified by Microsoft as a premium connector. Microsoft Learn explains that for an automated flow (one triggered by an event rather than run manually), it is the flow owner who needs an appropriate premium licence — such as Power Automate Premium — or the flow needs a Process licence; other users interacting with the completed approval do not automatically need the same licence tier. Organisations planning a Business Central-integrated approval flow should confirm current licensing requirements and costs against Microsoft's own published guidance, or with their Microsoft partner, before scoping a rollout, since licensing terms are updated by Microsoft from time to time.

A practical rollout approach

Introducing approval automation works best as a staged rollout rather than a single switch-over:

Document the current policy — write down the actual thresholds, approver hierarchy and delegation rules currently in force, confirming them with finance leadership, since this documented policy becomes the flow's specification.
Start with one workflow — pick a single, well-understood process such as purchase requisitions, rather than attempting purchase, payment and expense approvals simultaneously.
Build and test in a non-production environment — validate the threshold branches, delegation behaviour and Business Central write-back using representative test data before any live requisition depends on the flow.
Run in parallel — for an initial period, keep the manual process available alongside the automated flow, comparing outcomes to confirm the flow behaves as documented before it becomes the sole route.
Review audit evidence — check that the flow run history and the Business Central approval record together give a reviewer everything needed to reconstruct a decision, before relying on that evidence for an audit period.
Extend deliberately — once the first workflow is stable, extend the same pattern to payment release, expense claims or other approval processes, reusing the threshold and delegation design rather than rebuilding it from scratch each time.

How SCSB helps

SCSB works with Malaysian finance teams to translate a documented approval policy into a working Power Automate flow connected to Dynamics 365 Business Central, SharePoint, Outlook and Microsoft Teams. This can include reviewing the current approval process, mapping thresholds and delegation rules, building and testing the flow in a non-production environment, and configuring the audit trail so approval evidence is reconstructable for internal review or external audit. SCSB configures the technology; the approval policy, authority limits and accounting judgement remain the responsibility of the organisation's own finance leadership.

Request a consultation to discuss your current approval process and where Power Automate could support it.

Last updated: July 2026

Microsoft, Power Automate, Microsoft Power Platform, Dynamics 365 Business Central, Microsoft 365, SharePoint, Outlook and Microsoft Teams are trademarks of the Microsoft group of companies.