Who, when, from what, to what
Every governed change is one event per field, with the old and new value and the company it applied in.
Products / Ballast / Configuration audit
configuration auditKnow who changed every setting, when, and what it was before.
An append-only configuration audit trail records every draft edit, activation, publish and restore field by field, and catches changes made outside the governed path, by imports, OData or code, with a business event.
Field level
old and new value, who, which company, when
Append only
no user can edit or delete an event
7 years
of history kept by default
3
business events for alerting
The problem
When an auditor asks who changed a posting parameter before the close, and what it was set to before, standard Finance & Operations rarely has an answer. Parameter pages keep no history, and the database log has to be switched on table by table in advance. And an integration or a data import can write straight to a parameter table without anyone noticing, which leaves the control on paper only.
How Ballast answers it
Every step of a change is recorded: a version created or imported, each field edited in a draft, the activation, every table published in every company, a restore, and a temporary version lapsing. Each event carries who, when, which company, which table and field, and the old and new values, so the trail answers the auditor's question directly rather than by reconstruction.
The trail is append-only. Editing or deleting an event is refused for every user; only the retention task removes events, by default after 2555 days (about seven years), and the purge records an event of its own. The value before a change is not rebuilt after the fact either: it is the previous version, still in the list and unchanged.
Changes made around the governed path are caught. When a data import, an OData client or custom code writes straight to a governed table, Ballast records each changed field with the source Direct, records inserted and deleted rows on list tables, and raises a business event you can route to Power Automate, Teams or a monitoring tool. The write itself is never blocked, because failing an integration halfway through is worse than recording it.
Reading it is part of the job, not a project. The Configuration audit inquiry lists every event newest first and filters like any other page; its Field history tab shows one field's whole timeline; the Configuration audit button on a version opens just that version's events; and the trail is a data entity, so an audit pack can be pulled over OData or into Excel.
Staging and taking a change live are separate privileges, so a preparer can stage and compare without being able to activate or publish, and an auditor can read the trail without being able to change anything. The trail records who created and who activated each version.
What you get
Evidence an auditor can use.
What is in the box
What the trail records, and who can see it.
Every event records its source: Governed through the version path, Direct around it, or System for Ballast's own housekeeping.
Event types 10
- Version created
- Imported
- Draft edited
- Activated
- Published
- Restored
- Expired
- Direct changed
- Retention cleaned
- Snapshot repaired
Business events 3
- Ballast direct (ungoverned) change detected
- Ballast version published
- Ballast version window ended
Security roles 3
- Ballast administrator: stage, activate, publish, restore and audit
- Ballast auditor: read the audit trail, change nothing
- Ballast integration: the service operations only, for service accounts
Where you read it 4
- The Configuration audit inquiry, newest first
- The Field history tab, one field's whole timeline
- A version's own events, from its Configuration audit button
- The Ballast audit events data entity, over OData or in Excel
Questions
What buyers ask.
Can an administrator delete audit history?
No. Editing or deleting an audit event is refused for every user. Only the retention task removes events older than its window, which defaults to 2555 days, and the purge records that it ran.
Does Ballast block an integration that writes to a parameter table?
No. Blocking an integration in the middle of its transaction would do more harm than the change. The write goes through, and Ballast records each changed field as a Direct change and raises a business event, so it never goes unseen. Force republish puts the governed values back.
Does it record who viewed a setting?
No. The trail covers the configuration Ballast governs: its changes, publishes, restores and imports. It does not record page views or reads, or changes to records Ballast does not govern; for that, pair it with an activity audit such as Warden.
Can we keep history longer than seven years?
Yes. The purge runs only when you run or schedule it, and its dialog takes a retention period that overrides the default for that run. Set it before the purge runs, because purged events do not come back.
Can the person who staged a change also take it live?
Only if you grant them both. Staging and taking live are separate privileges, so you can give preparers the first and reviewers the second. An administrator holds both, so Ballast records who created and who activated every version for you to check.
Try it
See it in your own sandbox.
Ballast is one package: every capability on these pages comes with it. Run it free in any non-production environment for as long as you like, and subscribe only when it goes to production.