Approval of changes to master data

A changed bank account on a vendor or a higher credit limit for a customer can cost money if nobody notices. Business Central can send master data changes for approval in standard, but it requires setup field by field. This article shows what Microsoft Learn describes, how a workflow is built, and where you run into limitations. You also get an idea of how to keep the setup manageable.

What standard can do

Microsoft Learn mentions approval of new master data such as G/L accounts, customers, vendors and items, and of changes to sensitive fields, for example the vendor's bank account number and the customer's credit limit. Changes to item prices and new users are also mentioned. According to Learn, ready-made workflows exist for the customer card and the item card.

This means you do not have to start from zero. Open the Workflow Templates page, find the ones Microsoft has made, and copy one as a starting point. The templates have the code prefix MS-, and you can always return to Microsoft's version with the action that resets the templates.

How to build a workflow for a field change

Learn shows an example where the name of a vendor is changed. The principle can be used on other fields.

Steps: choose the event 'a vendor is changed', add a condition that a specific field has changed, and choose a response that sets the field back to the old value. Then add a response that creates an approval request, and one that sends it. When the approver approves, the new value is applied. If the approver rejects, the new values are discarded.

Limitations to know about

Test each workflow with both an approval and a rejection. Check that the old value comes back on rejection, and that the approver gets a clear message about what has changed.

The condition is chosen per field. If you want to control credit limit, payment terms and bank account, each needs its own condition or its own workflow.
The field change can be set to trigger on a changed, increased or decreased value. This suits credit limit well.
The responses and events are system-defined. If an event is missing for the table you want to monitor, it requires development, Power Automate or an app from AppSource.
All approvers must approve before the workflow moves on. This needs to be factored in when estimating how long a change takes.

Vendor bank accounts

The vendor's bank account is a separate record linked to the vendor. Microsoft itself has plans for approval of vendor bank accounts. Check Microsoft's roadmap for how far it has got before you build something of your own.

Whatever the case, a bank account change should also be checked by a call to a known number at the vendor. The system's approval moves responsibility to a person, but it does not verify that the change is genuine.

Which fields you should monitor

Start small. Choose the few fields where a wrong change can cost money: the vendor's bank account, the customer's credit limit, payment terms and possibly VAT setup. Make one workflow per field or group, and describe them clearly, so the codes make sense when someone has to maintain them a year from now.

Use naming that says what the workflow does, for example Vendor bank account and Customer credit limit. Export the workflows so you have a copy, and so they can be moved to another company or a test environment. Learn describes that workflows can be exported and imported.

Other controls

Combine the approval with permissions, so only a few users can change the sensitive fields. Use the change log to see who changed what and when.

We have Master Data Approval on our list of possible apps, as a combined model for approving master data. It is an idea we are considering, and not something you can download or buy.

Also consider a periodic review: a list of customers and vendors changed in the last month, looked at by someone other than those who maintain master data.