Stage without risk
A draft is a full copy of the module's settings that touches nothing live, so a change can be prepared, reviewed and corrected at any pace.
Products / Ballast / Parameter versioning
parameter versioningChange parameters as a reviewed release, not a live edit.
Ballast puts 66 standard parameter tables across 12 modules behind dated versions: stage a change in a draft, compare it field by field with what is live, and activate it for the day it should apply.
66
standard parameter tables, versioned
12
modules, one bundle each
Field by field
compare against live before you activate
Read-only
on every standard page that edits a governed setting
The problem
In standard Finance & Operations a parameter is changed by typing over it on the live page. The new value applies the moment it is saved, nobody reviews it first, and the old value is gone. One checkbox can change how a whole company posts, prices or collects, and when something goes wrong afterwards there is no record of what the setting used to be, no way to see everything that changed together, and nothing to put back.
How Ballast answers it
Ballast groups the parameter tables of each module into a bundle and versions the bundle as a whole. A version is a dated snapshot of every table in it. A new version starts as a copy of what applies today, so you only touch what you mean to change, and while it is a draft it is completely inert: nothing reaches the live parameters until it is published.
Before a version goes anywhere, Compare shows what it would actually change: every table and field where the staged value differs from the value live today, side by side. That is the step a second person reviews, and the record you keep as evidence of what was meant to change.
Each version carries a From date and an optional To date. Activating a version makes it eligible; Ballast then works out which version is effective on each day, using the company's time zone. When several are active, the latest From date wins, so you can stage next month's change today and a temporary change on top of a permanent one. Status is set only by Activate, and an active version cannot be edited, by the form or by an import.
Governance only works if there is no way around it. Every standard parameter page that edits a governed setting shows it read-only, including the pages that reach into other modules. Each table has exactly one owning module, and that module's version form carries every field any of those pages edits, so no setting is left locked with nowhere to change it.
Coverage is deliberate about what it leaves alone. Number sequences stay on their standard pages, as do settings shared by every company that appear on a per-company page, personal settings and the setup lists that have their own maintenance pages. Each module is its own feature in Feature management, so a module you do not want governed can be turned off, which unlocks its standard page again.
What you get
Configuration change you can review before it happens.
What is in the box
Every standard table Ballast versions, by module.
Each module is one bundle with its own version form under the module's Setup menu. System administration and Product information management are shared by every company; every other bundle is versioned per company. Numbers are table counts per module.
System administration 6
- System parameters
- File upload configuration
- System notification parameters
- Batch scheduler capacity
- Event system parameters
- File store parameters
Accounts receivable 8
- Accounts receivable parameters
- Sales parameters
- Sales price and discount policy parameters
- Rebate parameters
- Customer and vendor netting parameters
- Order hold defaults
- Customer automation parameters
- Customer change proposal fields
Accounts payable 5
- Accounts payable parameters
- Employee parameters (Russia)
- Vendor change proposal fields
- Vendor bank account change proposal fields
- Invoice matching by financial dimension
General ledger 10
- General ledger parameters
- Sales tax parameters
- Source document parameters
- Deferrals parameters (Russia)
- Tax accounting parameters (Russia)
- Tax register parameters (Russia)
- Agreement parameters (Russia)
- Reverse charge parameters
- Withholding tax parameters (India)
- EU sales list reporting parameters
Procurement and sourcing 7
- Procurement parameters
- Request for quotation parameters
- Purchase price and discount policy parameters
- Vendor request management parameters
- Catalog user review settings
- Vendor rebate parameters
- Vendor information form configuration
Inventory management 6
- Inventory parameters
- Bill of materials parameters
- Warehouse (WMS) parameters
- Process industries parameters
- Product compliance parameters
- Inventory dimension setup grid
Sales and marketing 1
- Sales and marketing parameters
Warehouse management 1
- Warehouse management parameters
Commerce 7
- Commerce parameters
- Commerce parameters extension
- Digital signature parameters
- Electronic invoicing parameters
- Chronological invoice posting parameters
- Clienteling parameters
- Fraud protection parameters
Project management and accounting 10
- Project management and accounting parameters
- Project service automation parameters
- Field Service project parameters
- Project intercompany parameters
- Pay-when-paid and vendor retention terms
- Billing type line properties
- Project stage names
- Project stage rules
- Funding search order
- Utilization types
Product information management 2
- Product information management parameters
- Engineering change product parameters
Fixed assets 3
- Fixed assets parameters
- Proposal journal names
- Document type setup (Russia)
Questions
What buyers ask.
Can someone still change a setting on the standard page?
No. Every standard page that edits a governed setting shows it read-only, so the version form is the only place to change it. A write that does not come through a page, such as a data import, an OData call or custom code, is not blocked; Ballast records it in the configuration audit trail and raises a business event so it can be followed up.
Which settings are not versioned?
Number sequences, settings shared by every company that sit in a per-company module, personal settings such as a user's display language, and setup lists that have their own maintenance pages. Those stay editable on their standard pages as before.
How does it handle several legal entities?
Every module except System administration and Product information management is versioned per company: each company has its own versions and its own effective version, and a change staged in one company never touches another.
Can we leave a module out?
Yes. Each module is its own feature in Feature management, and all are on when Ballast is installed. Turning one off removes its version form, stops the engine publishing it and unlocks its standard page; its versions and history are kept, untouched.
Do we have to build the first version by hand?
No. The first time a module's version form is opened, Ballast takes a baseline from the live settings, and every new version starts as a copy of the version that applies today.
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.