Filed Level Audit Enabled at Scale

​@anupalone72 

Audit history records field-level changes based on the configuration enabled in the system. Over time, this data can consume additional database space.

To manage this, we can build a custom screen to help clear audit history on a yearly basis, depending on your space usage and retention requirements. We can also include file revision cleanup as part of the process to help maintain database space.

Please let me know if you need our assistance in developing a custom screen to clear audit logs and file revisions.

There are also a couple of ISV solutions.  We use one from Acupower.

@anupalone72 I've been burned by overhead from too much auditing, so I'd look hard at this before production.

Something that isn't obvious from the Audit form: it audits tables, not screens. When you add a screen on SM205510 you're really turning on a list of tables. Anything that writes to those tables gets logged, no matter which screen or process it comes from.

Quick test on my end. I only have Purchase Orders audited, 14 tables. I changed a description on Stock Items and got an audit row for it, because InventoryItem is one of the tables under Purchase Orders.

In that tenant about 15% of the audit rows actually came from Purchase Orders. The rest came from 15 other screens, Release AP Documents and Purchase Receipts among them.

The audit rows get written in the same transaction as the save, so your processing screens pay for it too. Updates are small since only the changed fields are logged. Inserts are the heavy ones. Mine run about 17 times the size of an update.

With 45 screens I'd open each one and turn off the shared tables you don't need for compliance, like InventoryItem and CurrencyInfo, and use UI Fields instead of All Fields. Then query AuditHistory grouped by ScreenID and TableName in a test tenant and you'll see what's really generating the volume. Nothing built in deletes this table, so get one of the purge options above sorted before you go live.