Dax365FO

Business requirement

One of the bases of a solid and secure system is the possibility of tracing the changes, and the other is the segregation of accessibility. So, during the implementation, it’s natural to have the request to trace “when”, “what”, and “who” made the changeset on the system. However, the object potentially involved in the changes can have a different nature, like configuration, master data, order, or transaction posting. The monitoring of all those objects isn’t always so easy. Furthermore, consider the general rule: the more tracking we implement on the system, the more resources and space we consume. So, for a successful implementation, it’s important to escape the logic to trace everything without distinction and start to dress a list of the significant data for monitoring.

Solution Architect

As mentioned, the tracking of the changes consumes resources and space. Before making a list of what monitory, we should understand there are two families of technological solutions:

• Statistic: In the table involved, we can insert the name of “who” created the record and “when”. Furthermore, we can add the data of “when” the last modification was made and “who” did it. It’s the lighter and the most common solution adopted when we create a table. But we lose the historical details of the modification.
• Dynamics: Track all the modification’s history concerning the table’s record on a separate table. This solution can be more complete, but the risk is consuming many resources and space to trace information the user rarely looks into.

Which logic can we use to choose if we implement a statistic or the dynamics solution? There isn’t an absolute solution; it depends on the risk management policy. Generally speaking:

• The static solution is sufficient for the transaction tables where a record cannot be modified but only created. For example, we cannot delete or adjust an invoice posted on the customer transaction. So, it’s enough to have the user who created the record and when.
• For the other cases, like master data, order, journal, and configuration, the situation is more complex. We need to evaluate the risk based on multiple factors like:
  • Accessibility: The more people have access to a table, the more probable the request is to understand who did what.Sensibility: Also, if few people can access some points of the system but a modification can potentially have a loud consequence for the rest of the business process, the request for tracking becomes more probable (for example, inventory posting profile)
  • Volatility: The more significant variability a record can have for the business process, the more probable the request to have tracking (for example, we can have different kinds of sales orders)

The great absentee of the factors listed upper quoted is the “volume”. Why? Because I consider that the volume is not a separate factor but a factor in the background. Based on the business process design, the volume can have a different impact on accessibility, sensibility, and volatility. : attenuating or saving the risk factor. So, the factor should be evaluated as a posterior KPI of evaluation of the business process applied to the real live volume. In other words, will the system continue to be safe if we apply this volume?

At last, typically during the implementation, the points where the dynamics tracing is more frequently activated are:

• sales order header,
• sales order line,
• purchase order header,
• purchase order line,
• customer,
• vendor,
• items master data
• Posting profile table.

MD365FO solution

The system offers a multiple pallet of tools to trace the changes on the system. Not all of them can be used; it depends on the object of interest.

Database tracker

This technique is based on consulting how/when the modification was made on the database. The tools you can use are:

• Details information: statistic technique to see how/when the data was created and how/when the last modification. This solution is powerful in combination of the transaction table (like customer master data). For more details, see the article: https://daxmsdynamics365.wordpress.com/2023/10/22/view-all-fields-value/

• Data log: Ask the system to trace a specific table and field. It’s a high-consuming solution because all modifications will be stored on a specific data log table. For more details, see the article: https://daxmsdynamics365.wordpress.com/2023/11/07/data-log/

Audit trail

The finance departments can use the audit trail to obtain a report of how was done the voucher transaction. For more details, see the article: https://daxmsdynamics365.wordpress.com/2023/10/22/audit-trial/