NAV Tour: Change Log

One of the things I’m frequently asked about is how to see if or when someone changed something mission critical. Microsoft Dynamics NAV has a built-in system for tracking changes to any part of the system, but you have to know how to configure it and how to read the results.

Summary:

1. Activate the Change Log
2. Setup which tables, fields, and change types to track
3. Analyze the results

 

Turning on the Change Log

To enable the Change Log, we’ll need to go into the Departments area, under Administration -> IT Administration, and select the Change Log Setup task.

This will open a small form with only the one notable option:

That checkbox turns the whole Change Log engine on and off.

 

Setting up what to track

There’s a Relation Information action bar button hiding on that form (which you can see easily if you resize):

That menu will send you to the Change Log Setup (Table) List (it will take a couple of moments to open, as it is scanning your system for all known tables and fields):

 

In this case, the client wants to track anytime someone changes the Payment Terms on their Customers. We’ll select Some Fields under Log Modification:

Here’s a nice bit of confusing: Try to determine how you set the fields you want. In Classic, we could have both an AssistEdit button and a DropDown arrow, like so:

However, the RTC does not support that, nor were any Action buttons added to the Change Log Setup (Table) List to open it up. But, in the RTC, if you press Shift+F4 where you have selected the Some Fields option, it will open up the Change Log Setup (Field) List:

We’ll go ahead and resize that, then locate our Payment Terms Code field using the Quick Filter in the upper-right:

Check off the Payment Terms Code. Now when anyone alters the Payment Terms for any of the Customers, it will be logged who did it and when, as well as the before and after.

 

Reviewing Log Entries

Back on the Administration department, we have an option under Lists for the Change Log:

When you open that the first time, you’ll see a host of entries, even before anyone changed anything on Customers:

The Change Log records changes to settings to the Change Log itself, so if someone tries to circumvent any logging by altering the settings, the circumvention attempt will be logged.

In our example, we’re watching the Customer table, so we can filter our results to that Table Name (image split in two to show the whole list):

We can see:

• The exact date and time of any change
• Which user caused it
• What table number & name was involved
• Which record was involved (in our case, Customer 01121212)
• Which field number and name (Payment Terms Code)
• What kind of change (Insert, Delete, or Modification)
• What the Old Value was
• What the New Value is

 

As you can imagine, it’s very easy to set these to monitor critical elements of data. It is a very good idea to set these up on critical setup tables or critical financial components (like the Chart of Accounts). For some forms of auditing, such as Sarbanes-Oxley, you can likely consider this mandatory.

But, something to be careful of – this data can grow very quickly if you set it up on the wrong fields. For example, if you set this up to record every insert, modify, and delete on a Sales Order table, every time people are going about their normal work, they’ll fill this table with hundreds or tens of thousands of records.