Database Logging in D365 F&O

This document gives a detailed rundown of using the Database Logging feature in Dynamics 365 Finance & Operations (F&O).

1. What It Is

 

Database Logging is purely an auditing tool. It's designed to let you track specific changes made to the data in F&O's tables. You can configure it to create a log every time a record in a table is created, updated, or deleted. You can even get as specific as tracking changes to a single field, like the credit limit on a customer account or a vendor's bank details.

The logs are stored in a system table (SysDatabaseLog) right there in the F&O database. An administrator can then view these logs to see exactly what changed, who changed it, and when it was changed. It is fundamentally a feature for compliance, security, and forensic investigation - not for getting data out for any other purpose.

2. Architecture & Data Flow

​

The architecture is simple and, from a performance perspective, quite brutal:

• Setup

  • An administrator uses the "Database log setup" wizard in F&O to choose which tables and fields they want to monitor and for which operations (Inserts, Updates, Deletes).

​

• Transaction Occurs

  • A user or process changes a piece of data that is being tracked (e.g., they update a vendor's bank account number).

​

• Log is Written

  • As part of that same database transaction, the system writes one or more new records to the SysDatabaseLog table. This new log record contains the old value, the new value, who made the change, and the date/time.

​

• Transaction Commits

  • The original change and the new log records are all committed to the database together. If the logging fails, the entire operation fails.

​

• Viewing Logs

  • An administrator can go to the "Database log" form in F&O to view, filter, and search the history of changes.​​​

​

3. Prerequisites

 

• System Administrator Rights

  • Only a user with system administrator privileges can set up or configure database logging.

​

• A Clear Auditing Requirement

  • You need a very specific, compliance-driven reason to turn on logging. This isn't a feature you enable just to "see what happens."

​

​​

4. Pros (The Good Bits)
 

• Detailed Auditing

  • It provides a granular, field-level audit trail. If you need to prove who changed a specific, critical piece of information, this is the tool that does it.

​

• Built-in and Simple to Set Up

  • The wizard-based setup is straightforward. You don't need a developer, and you can have it running in minutes (though you probably shouldn't).

​

• Answers "Who, What, When"

  • It's very effective for its core purpose: answering forensic questions about data changes for security and compliance investigations.

​

5. Cons (The Not-So-Good Bits)
 

• Massive Performance Impact

  • This is the number one, critical takeaway from every single piece of research. Because logging happens within the same transaction as the actual operation, it adds direct overhead. Enabling logging on a high-volume transactional table (like sales order lines) can severely degrade the performance of your entire F&O system.

​

• Rapid Database Growth

  • The SysDatabaseLog table can grow incredibly quickly, consuming a huge amount of database space and further slowing down system performance and backups. This can lead to significant Azure SQL database cost increases.

​

• Not for Analytics

  • The log data is stored in a format that is difficult to use for any kind of analytical reporting. It's designed for viewing one-off changes in a form, not for exporting or aggregating.

​

• "All or Nothing" on Tables

  • While you can select specific fields, logging is enabled for all users and all processes. You can't, for example, only log changes made by a certain user group.

6. Key Implementation 'Gotchas' (Things to Watch Out For)

​​

• Use It Sparingly. No, More Sparingly Than That

  • The universal advice from Microsoft and every expert is to be extremely selective. Only log what you are legally or contractually required to log.

​

• Low-Transaction, High-Value Tables Only

  • The best practice is to only ever enable logging on "setup" tables that don't change often but are critical to your business. Good examples: Vendor Bank Accounts, User Security Roles, Terms of Payment. Bad examples: Sales Lines, Inventory Transactions, General Journal Entries.

​

• Have a Purge Strategy

  • You must have a plan for cleaning out the log data regularly. Don't just turn it on and let it run forever. F&O includes tools to help you clean up the log history.

​

• It's Not a Substitute for Good Security

  • Database logging is for after-the-fact investigation. It doesn't prevent a user from doing something. Proper security role configuration is the primary way to control user actions.

​

​

7. When Should You Use It?

 

• Database Logging should only be used for one thing

  • Targeted Auditing of Sensitive Data: When you have a strict compliance or security requirement to track changes to specific, sensitive, and low-volume data fields.

​

• It should NEVER be used for:

  • Exporting data for analytics or BI.

  • As a general-purpose change tracking mechanism.

  • As a way to feed data to another system.

  • On any table that is involved in frequent, high-volume transactions.

​

Using this feature for anything other than its narrow, intended purpose is one of the fastest ways to cause serious performance problems in your F&O environment.