2. RE: D365FO - Database Logging on shared tables

1) The Database Log within AX/D365FO was not designed as an auditing tool, it was designed as a debugging tool. The reason this is important is that it is not designed to be turned on and left on for long periods of time, there is very limited reporting around the data that is tracked, and there is no data maintenance capabilities (archiving/purging of audited data).2) For any tracking you want to take a 'risked based approach' to what you are tracking. That means tracking only the highest risk table and field combinations that have an audit requirement, this will help limit the impact of performance issues and make reporting on the audited data easier.3) You want to be careful of turning the Database Log on any transaction table, tracking too many table/fields of this type this is a guaranteed way to have performance issues within AX/D365FO. Master data and parameter tables are much more lenient on what you are tracking as the number of changes going to those tables is smaller.