Versions and rollback

Every publish creates a numbered version. A version stores the banner snapshot, its author, notes, creation time, and build status.

Review version history

Open the banner's version history before a rollback. Confirm the target version's name, number, author, notes, and build status.

A built status records that the build completed when that version was published or rebuilt. A failed status records a build failure. Promotion reuses a version without updating this stored status. A previous built status does not verify that every current environment points to that version or that a later environment promotion built successfully.

Roll back the default publication

Rollback requires Publish permission for the Banners section and publish access to the banner.

When you select an earlier version, CookieBeam:

1. Restores the stored snapshot into the banner's live configuration tables.
2. Creates a new version named for the rollback target unless you provide another name.
3. Sets the new rollback version as the banner's current published version.
4. Rebuilds the default bundle and active variant bundles.
5. Purges the banner cache after a successful build.

Rollback does not delete or rewrite version history. The new rollback version receives the next version number.

The same compliance-mode consistency check used during publish also runs during rollback. A stored snapshot can require an explicit mismatch acknowledgement before it is restored.

Account for rollback exceptions

Rollback updates the default publication. It does not change publishedVersionId on environment rows. An environment path such as env/production/latest.js can therefore continue to use a different version after a default rollback.

After a rollback, publish the restored configuration to each environment that must move with it. Confirm both the default path and every environment path used by your sites.

Rollback restores the banner snapshot and the related configuration tables handled by the rollback service. It does not restore the detected connection inventory, and it does not move environment pointers. Review the scanner's connection inventory separately when the rollback depends on earlier connection classifications.

Recover from a failed build

The database publication changes before asset generation finishes. A failed rebuild can leave the selected version in the database while the CDN still serves an earlier complete asset or a partially updated asset set.

Only the current published version can use the rebuild action. After a failure:

1. Record the version number and failed build status.
2. Correct the configuration or service error that caused the build to fail.
3. Rebuild the current version.
4. Load the CDN asset in a private window and verify its behavior.

For an environment-specific build failure, publish or promote to that environment again. The default-version rebuild action does not update an environment pointer or rebuild an environment path.

Discard unpublished changes

Discarding a draft restores the current published snapshot to the editable banner tables. It does not create a new version or rebuild the CDN assets.

Use rollback when you need to change the published default bundle. Use discard when you only need to remove unpublished edits.