Efficient use of the change log in Dynamics NAV

For many of our customers Dynamics NAV contains invaluable information. With the change log you can log any change in any NAV-table. By default only authorizations and the configuration of the change log are logged, even if the change log is disabled. You need to enable logging for any other table yourself. Configuration can be done under Departments/Administration/IT Administration/General/Change Log Setup and then in the ribbon Actions > Tables. This is also the place to activate logging. Logging can be configured for both some fields and for all fields in a table.

Audit trail

Why use logging? If you see any incorrect data in the system you can simply ask your colleagues. To give reasonable assurance about the integrity of the information processing in NAV an audit trail is essential. An audit trail is a history of changes, with who modified what, when and how. If configured properly, the change log in NAV is a perfect tool for this.

With a sound setup you can demonstrate the segregation of duties works: e.g. were articles only released by people who are allowed to do so? Detecting fraud is another important motivation, with logging of customer and vendor bank account numbers as example. In case of a process disruption it is also important to be able to review any modification of setup, master data or critical process data (e.g. status changes of a project). Therefore we advise to log these kind of tables. But isn't it easier to simply log everything in NAV?

Change log Dynamics NAV

The change log of NAV creates an entry per modification (insert, modify or delete). If all fields in the table are logged, creating a new customer with 25 fields filled by default yields 25 lines in the log. This may result in performance issues in NAV and using the log is like searching for a needle in a haystack. Furthermore, log entries are stored in the database which might grow to many gigabytes. The backup size grows accordingly. Fortunately, logging everything is not necessary for effective use. Many of our customers are intensive users of the change log, but have no performance issues or unmanageable growth at all.

They really thought over what they want to log. Control and the business need to answer the question: what are really critical master data, setup and process information? General ledger entries and document approval entries are a log itself and therefore don't need logging. Transaction-related tables (e.g. sales and purchase header and line) have limited significance as they contain no definitive information. However, for setup and critical master data (e.g. number series, names, posting and application setup) we strongly recommend logging.

Our advice: start with the setup and plan regular reviews, especially at the start. Any setup is better than no setup. With iterative optimizations you build a valuable tool answering to priorities from your organization.