The request to track everything a user assigned the SysAdmin role is something I see quite often; the problem is that this request is not feasible in the way that it is in other ERPs. Let’s explain where this request normally comes from, why it not feasible, and what we can do to address this.

Where This Request Comes From

Normally this type of request comes from an internal/external auditor that has experience in another enterprise ERP system (SAP, Oracle, etc). In these other systems, there is an internal audit trail controlled by the ERP that tracks every transaction in the system. Because of this, you can query this audit trail and get every transaction a user performed. This means reporting on every transaction a user performs is a valid request in these systems.

Why This is Not a Valid Request in D365FO

Change tracking in D365FO is not built into the transaction themselves and is done at the table level, not the user level. This means that the only way to track everything a user assigned the SysAdmin role does would be to track every table in the application. If you have worked with the Database Log (or any other tracking system in D365FO) you know this is not possible because of the performance impact this would have as well as the storage/reporting requirements that would come out of this type of tracking.

Can’t We Use Telemetry Data?

Telemetry data within D365FO is an incredibly powerful feature within D365FO and can be used to help determine which forms a user is navigating to, but this feature cannot natively show changes a user performs. I will say that you could potentially use custom telemetry events to help with view auditing (and this could be extended to also look at changes a user is making).

What Can We Do to Address This?

There are a couple different options when you get a request like this:

  • Reduce the number of users assigned SysAdmin in your environment – this is straight forward but by reducing the number of users assigned this role you limit the amount of time and effort you have to exert to track down what these users are doing. Ask questions like:
    • Does this user really need this elevated access to perform their day-to-day operations?
    • Can this access be temporary instead of permanent?
  • Have a review/sign off process for the assignment of the SysAdmin role to a user – assigning this role should not be something that can be done without multiple reviews and approvals. This will also help when it comes time for audit reviews as you now have a record of when this role was assigned.
  • Take a ‘risk-based approach’ to what you are tracking – while we cannot track everything a user does; we can place tracking around high-risk areas that we care about and/or would have a financial impact if a change was made undetected. An example of this is you may not care if a user changes a vendor’s birthday, but you would care if they changed a vendor’s bank account information.
  • Do not use the D365FO Database Log as a change tracking audit tool– if you have used this tool in the past you recognize the many shortcomings of the tool. In this case, having a tool like Fastpath Change Tracking that is built from the ground up to be an audit change tracking tool with a separate tracking methodology, built in reports, and data management capabilities means you can precisely track the changes you want to report on.
  • If this request is coming from an internal/external auditor, talk with them and explain why this request is not valid/feasible within D365FO. You can also show them what steps you are taking to address this situation.