Dynamics 365 audit logging is one of those features that nobody cares about until the day somebody asks "who changed that?" and nobody can answer. I have been on the receiving end of that question more than once, usually from a finance director who has just noticed a number that does not match last week. By then it is too late to switch it on.
Here is how I approach auditing on real projects, what I turn on, what I leave off, and the storage bill that catches people out.
Why You Should Enable Auditing Before Go Live
Auditing is not retrospective. If you turn it on after the problem happens, you get nothing for the period you actually care about. So the decision has to be made during build, not after a user complaint.
The good news is that it is cheap to decide properly. It takes about an hour in a workshop to agree which tables matter, and that hour saves a lot of awkward conversations later. I put it on the same checklist as the items in my Dynamics 365 go live guide.
The Three Levels You Need to Switch On
Auditing in Dynamics 365 works at three levels, and all three have to be on for anything to be recorded. First, auditing has to be enabled for the environment. Second, it has to be enabled on the table. Third, it has to be enabled on the individual columns.
People often do the first and assume the rest follows. It does not. I have seen a whole project go live with environment level auditing on and nothing actually being captured, because nobody had touched the tables.
What to Audit in Dynamics 365
The temptation is to audit everything. Resist it. A log full of noise is as useless as no log at all, and you will pay for it in storage.
My rule is simple. Audit anything that has money, ownership, status or personal data attached to it. Skip anything that changes constantly for boring reasons.
Good Candidates for Auditing
These are the ones I nearly always switch on.
Owner and status on accounts, contacts, opportunities and cases. Price, quantity and discount fields on quotes and orders. Credit limits, payment terms and bank details on accounts. Security role assignments and user changes. Anything that falls under GDPR, such as email, phone and address on contacts.
Things I Leave Alone
Columns that integrations update every few minutes, such as sync timestamps and calculated rollups, will flood the log for no benefit. The same goes for last activity dates and anything a plugin rewrites constantly. If a field changes a thousand times a day, auditing it will not tell you anything useful.
Audit Logs and Storage Costs
This is the bit that surprises people. Audit data lives in Dataverse log storage, and Microsoft counts it against your capacity. On a busy system with lots of integration traffic, the audit table can quietly become one of the biggest things in the tenant.
I have seen an environment where audit data was larger than all the actual business data put together. Nobody noticed until the capacity warning arrived. It is worth checking the numbers in the admin centre every few months, particularly after a data migration, which is where most of the bloat comes from. I covered that side in my post on Dynamics 365 data migration.
Turn Auditing Off During Migrations
If you are loading a hundred thousand records, you do not want a hundred thousand create entries sitting in the log forever. Switch auditing off for the load, then switch it back on straight afterwards. Write it in the cutover plan so nobody forgets the second half.
Set a Retention Policy
You can delete audit data in bulk by date, and you should. Decide how long you genuinely need it. For most businesses that is somewhere between one and seven years, depending on regulation, and a lot of teams keep everything forever simply because nobody made a decision.
Reading the Audit History Without Losing Your Mind
The audit summary view in the admin area is functional but clunky. For a single record, the audit history tab on the form is much quicker, and it is what I show end users.
For anything broader, such as "show me every change to credit limit last quarter", the built in view is painful. That is where exporting to Power BI or querying the audit table through the API earns its keep. If you have already built reporting, the approach in my Power BI integration post works well for an audit dashboard.
Who Should Be Able to See It
Audit data is sensitive in its own right. It shows what people changed, and sometimes what the old value was, which can include things they should not see. Lock the audit view privilege down to a small group, and review it alongside your security roles.
Auditing Versus Other Options
Standard auditing is not the answer to everything. If you need to track why something changed, not just what changed, you need a notes field or a proper approval process. The log tells you "status changed from Open to Closed by Sam at 4:12pm". It does not tell you that Sam did it because the customer rang and cancelled.
Likewise, if you need a tamper proof record for a regulator, talk to your compliance people before assuming the standard log is enough. It is a good tool, but it is not a legal archive.
A Simple Setup Checklist
Here is what I do on every new Dynamics 365 build. Enable environment level auditing on day one. Agree the list of tables and columns in a short workshop, and write it down. Check that audit data is actually appearing after the first test change. Add a monthly storage check to the admin routine. Set a retention period and put the delete job in the diary.
None of that is difficult, but all of it gets skipped when a project is behind schedule. If you would like a second opinion on how your own system is set up, that is part of what I do through my Dynamics 365 services.
