No change log? A risk to your business.

Imagine the following situation: An employee reports an unexpected data change in the system. Perhaps a customer’s credit limit is suddenly incorrect, or a bank account number has been updated. Immediately, key questions come to mind: Who made the change? When did it take place? And what exactly was changed?

This is exactly where the change log in Microsoft Dynamics 365 Business Central comes in. It provides precise answers to your questions, making it an indispensable tool for compliance, transparency, and internal control. In an era of increasing regulatory requirements and growing sensitivity to data security, comprehensive change monitoring is no longer a luxury—it’s a necessity.

Basic Setup of the Change Log

The change log is configured on the " Change Log Configuration" page .

Essentially, the goal is to determine which data sets are to be logged and to what extent this should be done.

The following steps are crucial in this process:

1. Select a table

First, determine which tables should be monitored. Typical examples include the “Customers” table (Table 18) or the “Items” table (Table 27). Your selection should always be based on relevance to your business. Particularly sensitive or business-critical master data are the top candidates here.

2. Enable field monitoring

In the next step, you define whether all fields in a table or only selected, particularly critical fields should be logged.

Targeted monitoring is especially recommended for sensitive information—such as a customer’s credit limit or prices. While it is possible to log all fields, this generates a significantly larger volume of data. Consequently, this will cost you significantly more in terms of system performance than if you opt for limited monitoring.

3. Define Actions

For each selected table, specify which actions should be logged. The available options are:

Insert
Modify (Edit)
Delete
Field Changes

This decision has a significant impact on the scope and usefulness of your change log.

In the following, we'll take a closer look at each of these settings.

The Differences Between the Individual Settings

Depending on how it is configured, the change log records different types of data movements.

Insert

This setting logs the creation of new records. For example, if a new customer is created in the system, you can later determine when the record was created and which user created it.

Edit (Modify)

Changes to existing records are logged here. A classic example: A customer’s credit limit is increased from €10,000 to €15,000. The change log stores both the old and new values and shows you the user who made the change and the time it was made.

Delete

This option tracks the removal of data records. For example, if an item is removed from the product lineup and deleted, this process remains transparent and traceable.

Field Changes – Targeted Monitoring

Field monitoring offers a particularly high level of granularity. Here, you can precisely define which individual fields should be logged.

Best practice is to enable only truly critical fields, such as prices, payment terms, or addresses. This reduces the volume of data generated and keeps performance stable.

Another important aspect is avoiding redundant logging. For example, address data is constantly and automatically synchronized between customers, vendors, and contacts. It is therefore sufficient to monitor this information in one central location rather than logging it multiple times.

Two brief practical examples

1. Financial Compliance

Your customer's bank account information is being changed. Without a change log, it would be difficult to determine who made this change and whether it was authorized.

With logging enabled, however, you can verify exactly when the change occurred and which user made it. This transparency is essential, particularly in the financial sector, to minimize risks and comply with regulatory requirements.

2. Updated Address Information

One of your employees accidentally overwrites the address in the customer master, even though a different shipping address should have been entered only in the sales order.

The change log clearly shows you when the change was made and by whom. This not only allows you to quickly identify the error, but also to determine specifically whether there is a need for training or whether existing access rights can be optimized.

Important Note on Posted Tables:
For posted tables such as invoice headers, invoice lines, or delivery note lines, it is necessary to log insertions or all field changes.

The reason is simple: Posted items can no longer be modified or deleted. In this case, the standard logging of the posting itself is sufficient, since subsequent manipulations are impossible.

Best Practices for Production Use

A well-designed change log provides transparency without placing an unnecessary burden on system resources. The following approaches have proven effective:

Enable logging only for relevant tables and fields. This will help preserve performance and save storage space.
Review the logs regularly and develop a clear archiving strategy to keep the volume of data manageable over the long term.
Check at least once a year to ensure that your logging settings still meet current requirements. Business processes change, so your monitoring strategy should change as well.
Document your organization carefully. Clear documentation makes audits much easier and strengthens your internal control mechanisms.

Our conclusion

The change log is not just a “nice-to-have,” but a key tool for companies that prioritize transparency, security, and compliance. It brings clarity to day-to-day operations, protects against undetected tampering, and supports both internal and external audits.

The key question, then, is: Have you already set up your change log in the best possible way?

For more tips and tricks about BC, subscribe to our PROTAKT blog!

About the author

MARTIN BENZIN · Senior Functional Consultant

Over 28 years of professional experience in application development and project management in more than 30 countries.

My extensive experience in the BC and NAV environment has served as strong professional and technical support for several large and small medium-sized companies throughout my career. In the process, I have become familiar with many industries, such as mechanical engineering, special machine construction, the automotive industry, and power tool manufacturing. There, I supervised several projects involving the introduction and upgrade of ERP solutions.

These experiences have given me in-depth expertise in complex solution environments and large projects.