Change settings without the risk
Controllers and operations managers whose posting, pricing, collections and procurement depend on parameters, who need a change reviewed before it lands and undone cleanly if it is wrong.
Who it's for
Built for the people who own the settings.
Run configuration as releases
System administrators and centers of excellence who want staged, dated changes, a record of every run, and one place to change each setting instead of many pages.
Evidence on request
Internal audit and SOX teams who need to show who changed a setting, when, what it was before, and who took it live, from a record nobody can edit.
One way to change every client
Implementation partners and managed service providers who prove configuration in a sandbox, promote it to production and roll it out company by company.
Use cases
Everyday change control
◆A routine parameter change, reviewed
Instead of typing over a live setting, an administrator stages the change in a new version of the module, runs Compare to see every field it would change, and activates it. Publish now takes it live, and the publish run lists each table it wrote, with row counts.
Parameter versioningPublishing and rollback
◆Maker-checker sign-off
Preparers hold a role that can stage and compare but not activate or publish. A reviewer with the Ballast administrator role reads the compare, activates the version and publishes it. The trail records who created the version and who activated it.
Parameter versioningConfiguration audit
◆Change a list setting
Which customer and vendor fields need approval, the default order holds, the project stages: rows are added, changed or removed in a draft like any other value, and publishing replaces the list in each company that has rows for it.
Parameter versioningPublishing and rollback
Use cases
Timing and recovery
◆A policy change for the first of the month
The change is staged and activated today with a From date of the 1st. The version that applies now keeps applying until then, and the scheduled publish engine takes the new one live on its first run on the 1st, in every company that has it, with nobody logging in.
Parameter versioningPublishing and rollback
◆A temporary setting that reverts itself
A seasonal setting is staged as a version with a To date, on top of the open-ended version underneath. When the date passes, the engine reverts each company to the open-ended version, with a warning and a business event, so nobody has to remember to put it back.
Publishing and rollback
◆Undo a change that caused a problem
Restore this version copies the last good version into a new draft, linked to its source. Compare confirms it reverses only what was intended, and activating and publishing it puts the old values back. The faulty version stays in history beside the fix.
Publishing and rollbackConfiguration audit
◆An emergency change with the evidence intact
Even under pressure the change goes through a version named for the incident: a quick Compare to make sure the fix changes nothing else, activate from today, Publish now. The incident can be reconstructed afterwards from the version, the run and the trail.
Parameter versioningPublishing and rollbackConfiguration audit
Use cases
Audit and control
◆Who changed that setting, and when
The Configuration audit inquiry answers it directly: every draft edit, activation and publish, with who, when, which company and the old and new value. The Field history tab shows one setting's whole timeline, and nobody can edit or delete an event.
Configuration audit
◆Catch a change made around the process
A data import or an integration that writes straight to a governed table is recorded as a Direct change and raises a business event, routed to the owner in Teams. A weekly review filters the trail on Direct changes, and Force republish puts the governed values back where needed.
Configuration auditPublishing and rollback
◆A period-end change with an audit pack
The version is named for the change request, its compare is kept as pre-change evidence, and it is activated for the cutover date. Afterwards the run, its lines and the version's audit events make the pack, and the trail can be extracted over OData for the auditor.
Configuration auditEnvironments and integration
Use cases
Environments and rollout
◆Promote configuration from sandbox to production
A version proven in the sandbox is exported through Data management and imported into production, where it arrives as a draft. Production's administrator compares it with production's live values, activates it and publishes it. Nothing is re-keyed and nothing skips review.
Environments and integrationParameter versioning
◆Roll a change out company by company
Each company gets its own version of the change, staged and compared there. One engine run publishes them all and lists a line for every table in every company, and a company nobody staged a change for is left exactly as it was.
Parameter versioningPublishing and rollback
◆Check governance after an update or a refresh
After a platform update or a copy from production, an administrator confirms the publish engine is still scheduled and runs it once. No changes is the healthy answer; a large Success shows where live configuration and the versions had drifted apart, before anyone stages a change.
Publishing and rollback
◆Configuration changes from your own tools
A release pipeline or an internal tool creates a version, stages values, compares it with live, activates and publishes it through Ballast's service operations, under a service account with the Ballast integration role. Every call follows the same rules and leaves the same audit trail as the pages.
Environments and integration
Try it
Prove your use case in a sandbox.
Every use case on this page runs on the one Ballast package. Install it free in any non-production environment, wire up the connection you care about first, and subscribe only when it goes to production.