Changes land without anyone logging in
Activate today for the 1st of next month; the scheduled engine publishes it on the day, in every company that has it.
Products / Ballast / Publishing and rollback
publishing and rollbackChanges go live on their date, and come back out the same way.
A scheduled batch job publishes each module's effective version where it differs from what is applied, and records every table it writes in every company. Rolling back is restoring a known-good version through the same reviewed path.
Only differences
published, checked against what is applied
Per table
and per company, every publish accounted for
Isolated
failures: one company never stops the rest
Forward
rollback that keeps the history intact
The problem
A configuration change that has to land on a particular day usually means someone logging in at the right moment to type it in, in every company it applies to. If it turns out to be wrong, recovery depends on someone remembering the old values or on restoring a database, and nothing records which companies actually received the change and which did not.
How Ballast answers it
Activating a version chooses it; publishing applies it. You can publish on demand with Publish now, and the publish engine, a standard batch job you schedule with the usual recurrence, publishes on its own. Each run works out the effective version of every module in every company, checks it against a registry of what is already applied, and writes only where they differ. A run with nothing to do writes nothing.
Effective dates are days, not times. A version applies from its From date, and reaches the live parameters when the engine next runs on or after that date, so a daily run at 02:00 takes a version dated the 1st live at 02:00 on the 1st. Every scheduled run records its scheduled start, how long after it the run started and how long it took, and a version applied after its date had passed is flagged with how many days late it was.
Every run is accounted for. A publish run records one line per table per company, with the number of rows applied and an outcome, and rolls up to No changes, Success, Partial or Failed. A company that fails is rolled back on its own and recorded with a reason-coded exception, which you retry, dismiss or resolve from the run, while every other company and module carries on. Each version published raises a business event.
Temporary changes undo themselves. Give a version a To date and, when it passes, the engine reverts each company to the open-ended version underneath, with a warning and a business event. If nothing but the original baseline is left, it holds instead of rewinding months of configuration, and opens one exception so someone decides.
Rollback is a release like any other. Restore this version copies any earlier version into a new draft with a link back to its source; you compare it, activate it and publish it. Nothing is overwritten or deleted, so the history shows the change, the problem and the fix. When configuration has been changed outside Ballast, Force republish puts the governed values back.
What you get
Cutovers without the midnight shift.
What is in the box
Publishing, run history and recovery.
Publish now and the publish engine run the same code; the engine is a standard batch job with the standard recurrence.
Ways to publish 4
- Publish now, from any version form
- The publish engine as a recurring batch job, for one module or all of them
- A one-off run scheduled through the publish service
- Force republish, to reapply governed values over outside changes
Run outcomes 4
- No changes
- Success
- Partial
- Failed
What every run records 4
- Scheduled start, start delay and duration of the run
- One line per table per company, with rows applied and an outcome
- Reason-coded exceptions with the captured error text
- A warning when a version went live after its date
Recovery 4
- Restore any version into a new draft, with lineage to its source
- Retry, dismiss or resolve each exception from the run
- Automatic revert when a temporary version's To date passes
- A hold, not a rewind, when only the baseline is left
Questions
What buyers ask.
Does Ballast publish on its own after it is installed?
Only once you schedule it. The publish engine is a standard batch job, and a fresh install creates no recurrence: open the Ballast publish engine and set one on its Run in the background tab. Until then Publish now is the only thing that publishes, and a future-dated version waits.
Can a change take effect at a particular time of day?
Effective dates are whole days. A version goes live when the engine next runs on or after its From date, so you choose the time by scheduling the engine. Each scheduled run records its scheduled start and how long after it the run began.
What happens if a publish fails in one company?
That company's work rolls back on its own and is recorded as a failed line with an exception; every other company and module carries on, and the run shows Partial. Retry the exception from the run once the cause is fixed.
What if our license lapses?
Ballast's pages always open, and viewing, comparing and auditing are never restricted. Activate, Restore and Publish are refused only when the licensing service has returned a definite verdict against the license (expired, invalid, or offline beyond the permitted window), and a refused batch publish is recorded as a failed run. An environment with no verdict yet keeps working.
Is it priced per company or per module?
Neither. Ballast is one flat price per production instance per year, with every module included, and it is free in sandbox and other non-production environments.
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.