Resources  /  Governance

Who changed that parameter? Auditing configuration in Dynamics 365 F&O


A single parameter can change how a whole company posts, prices or collects, and when an auditor asks who changed it and what it was before, Finance & Operations rarely has an answer. Here's what a configuration audit trail needs.

The question comes after the change

Configuration questions are always asked late. A margin moved, an invoice posted to the wrong account, a credit check stopped firing, and someone asks whether a setting changed before the close. Answering means knowing who changed which field, in which company, when, and what it was before. In standard Finance & Operations the parameters pages keep none of that: the new value simply replaces the old one.

Why the usual tools fall short

The database log can record changes, but only on tables and fields someone chose to log in advance, so the setting that matters is usually the one nobody turned it on for. Its record is table by table, with no idea of which changes were meant to go together or why. And an integration, a data import or a piece of custom code can write straight to a parameter table, which is exactly the change nobody thinks to look for.

What a configuration audit trail needs

It has to record every change at the level of a field, with the old and new value, the person and the company. It has to be append-only, so the record cannot be quietly corrected afterwards, and its retention has to be long enough for your audit horizon, with the purge itself leaving a record. The value before a change should not be reconstructed from fragments; it should be the previous version of the configuration, still there and unchanged. And it has to notice changes that bypass the process, not only the ones that follow it.

From a log to a control

A trail becomes a control when it sits on a process: changes staged as versions, reviewed through a field-by-field compare, taken live by someone other than the person who prepared them, and recorded at every step. That is how Ballast works for the parameters it governs. Every draft edit, activation, publish and restore is recorded per field in an append-only trail, direct writes from imports, OData or code are recorded and raise a business event, and the compare and the publish run are the evidence an auditor asks for.


Related product

Ballast. Version, schedule, and roll back F&O configuration: no risky live edits.

An unhandled error has occurred. Reload 🗙

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.