As promised we’re going to begin sharing the ongoing enhancements and features that are coming as a result of the 2022 release wave 1. For our first update we take a look at a little gem of new functionality for auditing, we thought it might be useful to highlight this and also review auditing functionality more generally, to help those less familiair with this function. This article is relevant to system administrators and data managers.
What is Auditing functionality in Dynamics 365?
Auditing allows your users to see changes that any other user has made to the values of most columns from any row in most tables. The logs of these changes are stored in a separate table to your data and files in your Dataverse environment.
Obviously, being able to see the history of changes to any record can be incredibly useful but left unchecked the amount of storage space used by these log records can soon build up requiring you to spend more on storage. In the past the only mechanism to delete old logs was a very manual process but there’s now a new automated mechanism. There’s also a tool out there to help you restore accidentally deleted records if you have auditing switched on.
How to view Audit Logs
There are two places you can see the audit logs:
To see audit logs for a specific row, you can click on the “Related“ tab and then “Audit History” on any form for that row. This allows you to see who made what change to what column.
To see all audit logs, go to Advanced Settings | System | Auditing | Audit Summary View. Here you can use the filter icon to help you search for changes made by a certain user, a date range, what they did (using the Event or Operation columns, particularly useful for looking for deletes). However, you can’t see which columns were edited without looking in the individual audit log.
Be aware of some limitations of audit logs:
- You can’t search log records using out-of-the-box functionality, this data is stored in a very different way to your actual data. Whilst theoretically it would be possible to search this data it would require specialist skills that are rarely going to be a worthwhile investment.
- You can’t export the audit logs.
- You can’t turn on auditing retrospectively, it needs to be switched on to track changes.
- You can’t differentiate between “important” changes and “minor” ones. Every log is given equal weight.
- Changes made in one go are stored as one log, so multiple rows may be covered by one log entry.
- Whilst deletions of rows are logged the details of what that row was (definitely past tense) is not stored. What would you store it against? It’s deleted. There is a useful tool that comes into play with audited deletions though, see the section below on the “Recycle Bin” Tool.
Audit Log Storage
Each environment comes with 2GB of data purely for storing your audit logs and plugin trace logs. If you want to check how much space your current logs are using up you can go to the Power Platform Admin Center [sic] (if you have appropriate admin rights, these are controlled by your M365 Global Admin), go to Resources, then Capacity and you’ll see all of your storage usage for your whole environment. You can get more detail about specific environments if you want to by clicking on the Dataverse tab and then click on the little graph icon .
Whilst you can always purchase extra storage space, it’s worth considering some other ways to reduce your audit log usage:
- Do you really need to keep details on changes to every table? Perhaps it’s only specific tables that are important enough to need to know exactly what changes have been made.
- At a more granular scale do you need to know the details of changes to every field? Some fields are clearly more important than others but be warned it’s an onerous task to do this selectively. Microsoft have been kind enough to turn this off for fields that can’t be changed by users anyway (e.g. created on date).
- Rather than investigating changes you didn’t want to happen after they have happened, consider other ways to lock down your data:
- Column (field) level security so only people with certain security roles can view and edit certain columns
- Make columns read-only on forms
- adjust and deploy custom security roles so that only some users can delete rows for certain tables (or maybe only give them the rights to delete their own rows).
- There are mechanisms (North52 is our preference) that allow you to show or hide tabs in certain situations, hiding all the columns on that tab unless needed
- Use business rules to enforce data validation and to lock or hide columns on forms when they shouldn’t be edited
- If you need to enforce data validation rules that involve other tables you can look at synchronous workflows (workflows that could potentially stop a row from being saved if certain criteria aren’t met)
- The big question! How long do you really need to keep audit logs for?
Finding the Auditing function
The auditing for any table/entity is set on the General tab for each table in the Default Solution.
Once Auditing is switched on for a table then auditing is switched on for all columns in that table (and for any new columns you add to that table). Whilst it’s good practice to only switch this on for columns you actively want to audit it’s a painful experience to go through all the columns you don’t want to turn auditing for. Most organisations don’t bother.
The “Recycle Bin” Tool
There is a nice tool available in XRM Toolbox developed by Deepak Battini which makes use of Audit Logs to make it possible to restore deleted records. It has a few limitations:
- The date range selection doesn’t really work, regardless of the dates used it lists a limited sub-set of deletions.
- If you select “All users” you will often find that there should be more items returned than the tool seems to be able to handle so you may not find what you are looking for. It’s better to isolate which user made the deletions using the Global Audit Summary View.
- The deletion times shown in the tool are UTC so they will match the times shown in Dynamics in the UK during the winter but will be out by an hour during British Summer time.
- You can only restore one “Entity” type at a time and when that record is restored it is restored as a new record. This means that all child records and activities and notes whilst you can find them (and that might be all you need to get the details you need to recreate what’s missing) can’t be restored as the parent record, strictly speaking, no longer exists.
It’s worth repeating: this tool only works for tables and columns for which auditing is enabled.
Deleting Audit Logs
Now we come to good the stuff. It used to be that to delete old logs you had to manually go to the Audit Log Management section and manually delete one-by-one separate 3-month packages of audit logs.
Now you can, if you have access the Power Platform Admin Center [sic], set a retention policy for your logs. There are some common choices but there is also a custom setting. Unfortunately, you still can’t distinguish between logs for different types of records (we understand, it’s not unthinkable you would want to keep logs for Order records for far longer than you might want to keep logs for Leads). That said, if you need to free up additional space you can now use the Delete Logs option and delete logs for:
- Specific tables
- All logs older than a certain date
- All access logs
This concludes 2022 Release Wave 1 Auditing and our first update in the Release Wave 1 series. Hopefuly, this has been of use. If you have any comments, suggestions or questions feel free to contact us.
About Rocket CRM
Rocket CRM is a Microsoft Dynamics 365 and a platinum ClickDimensions accredited partner, helping small to medium-sized businesses and charities harness the power of scalable CRM technology. Our mission is to make powerful CRM software simple with custom-built, user-focused solutions.