Promote what you tested
Export the version proven in the sandbox and import it into production as a draft, values and all.
Products / Ballast / Environments and integration
environments and integrationProve a configuration in a sandbox, then promote it without re-keying.
Every version and every governed table is a data entity, keyed by the version's name rather than a record id, so a version moves between environments through Data management and arrives as a draft for review. 20 service operations give your own tools the same governed path.
83
data entities, every one published for OData
20
service operations across 5 services
Draft
is how every import arrives
By name
versions matched by name, never by record id
The problem
A configuration that has been tested in a sandbox usually reaches production by someone re-keying it from screenshots or a spreadsheet, page by page and company by company, at exactly the moment a typo costs the most. Moving it as data is no better if the import writes straight into the live parameters, skipping the review it went through in the sandbox, or breaks because internal record ids differ between environments.
How Ballast answers it
Every version and every governed table is enabled for Data management. A version is exported from the environment where it was proven and imported into the next one: the version first, then its values. Versions are matched by name, so they reattach correctly however record ids differ, and an imported version is seeded from the target's own settings before the values are applied over it.
An import cannot take anything live. It always arrives as a draft, it cannot change a version that is already active, and it cannot activate anything. The person in the target environment compares the draft with what is live there, activates it and publishes it, so promotion ends in the same review as any other change.
Ballast is honest about what does not travel. References stored as internal record ids, financial dimension fields and fields stored as arrays stay at the target's own values, because a record id means a different record in another environment. The invoice-matching dimensions travel by the dimension's name, and a row naming a dimension the target does not have fails with a message that says so.
Your own tools can use the governed path too. 20 service operations across 5 services create, read, edit, compare, activate, restore and publish versions, and every one runs the same code as the version forms, with the same checks and the same audit events. Every Ballast entity, including the audit trail and the publish history, is published for OData and the Excel add-in.
Access stays deliberate. The Ballast integration role grants the service operations and no pages, for service accounts. Import, export and OData access are separate privileges in no shipped role, granted per module, so being able to publish does not let someone import, and the reverse.
What you get
One configuration, every environment.
What is in the box
Every service operation, by service.
Every operation runs the code the version forms run, and none throws across the boundary: a failure returns a typed error code and the message the page would show.
Version service 11
- Create a version
- Read a version
- Read the version effective today
- Change a draft's name, description or dates
- Read a staged value
- Stage a value in a draft
- Add a list row to a draft
- Delete a list row from a draft
- Activate a version
- Restore a version into a new draft
- Delete a draft
Snapshot service 2
- Compare a version with live
- Compare two versions
Publish service 2
- Publish now
- Schedule a publish run
Maintenance service 4
- Find snapshots stored blank
- Repair snapshots stored blank
- Count batch scheduler change events
- Purge batch scheduler change events
Deployment service 1
- Report the deployed model version and license status
Data entities 4
- A version entity for each module
- A values entity for each governed table
- Publish runs, run lines, exceptions and applied versions
- Ballast audit events
Questions
What buyers ask.
Can an import change production configuration directly?
No. An imported version always arrives as a draft, an import cannot change a version that is already active, and nothing imported can activate itself. Someone in the target environment compares, activates and publishes it.
What does not move between environments?
Settings stored as internal record ids, financial dimension fields and fields stored as arrays keep the target's own values, because a record id points at a different record in another environment. Everything else in the version travels.
Do our integrations need X++ developers?
No. The service operations are standard Finance & Operations custom services, called over HTTP and authenticated with Microsoft Entra ID like any other call, and the data entities are standard OData entities.
Who can import and export versions?
Only people you grant the data entity privileges to. They are separate from the Ballast roles and come per module, so an administrator cannot import by default and an integration account can be limited to the modules it needs.
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.