Monitor each click and changes made in AX for users having SysAdminRights

Hi Everyone,

Could you please help me out with the below?

Scenario: The moment any user receive SysAdminRights. Post that - The clicks to form or changes made to any data or importing file to AX - All these events must be recorded somewhere so that we can monitor at one place what a particular user did when he/she received admin rights on AX.

Environment: AX 2012 R3

Detailed Requirement:

  1. So if a user with Admin rights clicks on PO Form - Then the it shud record that the user opened PO form

  2. If user makes any changes in a PO, then it should record the PO number and what changes were made to which field

  3. If posting was done, and it should record the event where we can see that the user utilized posting event by clicking on button post

and so on…

Can anyone please help me out here?

Thanks in advance !

Logging of activity on forms should be doable with Client Access Log.

Data could be handled by database logging, but logging everything would have significant impact on performance, therefore it’s not really something you should do.

Hi Martin - I agree with you but if I have to do so without much hindering the performance. Could you suggest me something that I can do please?

I don’t believe there is much you can do, therefore I think you should look again at the actual business problem and consider other ways how to solve it.

Hi Maartin,

So the business came back with the answer that they are ok if it hinders teh performance but they need the scenario implemented. Then what can I do next or how should i go abt implementing it? Ideas?

I don’t believe your clients understand the consequence and it’s your work to prevent them from shooting to the leg. The idea is simply wrong and shouldn’t be done. It would harm the client, in my opinion.

If you want to do it anyway, you must refuse the idea of logging everything. For example, just trying to log all changes in a single table, InventSum, would cause huge performance problems, while logging it (most likely) doesn’t add any value.Or do you really want to log changes in tables used by report data providers? Would it make sense to log changes in the log itself? And so on…


This is a request I get quite often as I work in the security, audit, and compliance space within the Dynamics ecosystem. I also am the lead developer on our own Audit Trail solution at Fastpath, so I have unique knowledge surrounding this area. This request normally comes from someone with a background in either Oracle/SAP where this type of report is feasible. This is because those systems track all transactions by default and it is built into the system design whereas AX does not have this.

If you try and achieve this you would have to place tracking around every ‘user’ table within the system (there are some system tables that you probably wouldn’t want to track). In this case, every transaction in the system from every user would be tracked. As Martin said this would cause massive performance issues if the application would even work at all. You would also have to deal with trying to write a usable report for this data and maintaining the resulting audit data in some way.

In lieu of trying to capture everything a user does in the environment (which requires tracking every table), the option I normally tell end users and internal/external auditors is to take a ‘risk-based’ approach to what you are tracking. By that I mean that you should determine which parts of the system are at a higher risk and you want to be sure you report on those changes and place tracking around those areas.

As an example, from your requirements above you would want to track changes to the PurchTable and PurchLines tables. As a side note though, there are certain areas within AX that already have built in history tracking. Purchase Orders happens to be one of those areas (with the PurchTableHistory and PurchLineHistory tables) ledger journals and workflows happen to be other areas that this occurs.

Also there really isn’t a way to do ‘view auditing’ as just SELECT-ing a record does not invoke a change to the data that you can capture with change tracking. I actually did a POC trying to achieve this by hooking into the FormRun method which gets called as part of the init process for all forms tied to a menu item display but found that under any amount of real load in the system this starting causing performance issues.

If you have any questions about this please let me know, also if you would like to discuss this more I would be happy to set up a time to chat!