Portail ZAPP

Applying a GOLIVE and viewing the history

Available in en es fr

Updated on 10/25/2026

Applying starts from a preview (see "Choosing and previewing a GOLIVE"). It installs on this instance exactly what the preview shows: the package was kept as it was read, even if the source has changed since.

Applying

At the bottom of the preview, Apply the GOLIVE. The button does not appear while a blocking issue remains.

If the preview offers optional fields, save your choices first: applying uses the saved choices.

  • As a single block: items are installed in the order of their dependencies. If a single one fails, nothing is kept and this instance stays exactly as before. The history shows the item at fault and the reason; fix it, preview again, then apply.
  • Published versions: only processes and forms published in the source are promoted, and they are published here.
  • Nothing is deleted or activated: an item missing from the selection stays in place, and an item disabled in the source is disabled here, never the other way around. The only exception: the activation of languages is copied both ways (see "Choosing and previewing a GOLIVE").
  • One GOLIVE at a time: if another GOLIVE is running on this instance, try again once it has finished.
  • Only once: an applied preview cannot be applied again. For a new GOLIVE, preview again.

To reactivate

New triggers (schedules, mailboxes, thresholds…) arrive disabled, so that nothing starts before it has been checked. At the end of the GOLIVE, the To reactivate list gives those that are active in the source: check their settings here, then reactivate them in the service catalog or in the ticket administration (automation rules, escalation policies), or in monitoring (alert rules).

History

On the GOLIVE page, GOLIVE history lists every GOLIVE applied or attempted: date, source, author, result, and the number of new, modified or identical items. A failed GOLIVE changed nothing.

The detail of a GOLIVE shows, for each item:

  • the action: new, modified or identical;
  • the source fingerprint, that of the content promoted from the source;
  • the replaced fingerprint, that of the item here before the GOLIVE (empty for a new item).

Export (CSV) downloads the whole history, one line per item. Each GOLIVE also leaves a trace in the audit log.

Rolling back

A successful GOLIVE can be undone from its history page, entirely or in part.

  1. Open the GOLIVE in GOLIVE history.
  2. Tick the items to undo, or none to undo the whole GOLIVE, then Prepare the rollback.
  3. A preview is shown: nothing is written yet, and nothing is read from the source. Check it, then Apply the rollback.

A rollback is applied like a GOLIVE: in a single block, one at a time, and it appears in the history, linked to the GOLIVE it undoes. It can itself be undone.

  • An item modified by the GOLIVE gets back its previous content. For a process or a form, the previous version becomes the published version again, under a new version number.
  • An item created by the GOLIVE is disabled, never deleted. An item without an active state (form, process, script, status transition, maintenance window…) stays in place: the preview says so. A maintenance window created by the GOLIVE can be deleted in monitoring if needed.
  • An item modified since, by hand or by a later GOLIVE, is flagged in the preview: the rollback overwrites those changes.
  • A script whose content from before the GOLIVE exceeds the current rules (timeout above 24 hours, more than 10 retries: values allowed before these limits) is brought back within the limits: the preview says so with a warning giving the original value and the limit (for example "172800 → 86400", in seconds), and the script is restored.
  • Nothing is reactivated: an item the GOLIVE had disabled gets back its content but stays disabled, and appears in the To reactivate list. Only exception: a language, whose activation follows the GOLIVE both ways, is reactivated.

The previous content is only kept for GOLIVEs applied since rollback became available, and for the package retention period (12 months). Beyond that, modified items can no longer be undone: the preview shows a blocking issue.

Retention

A preview that was never applied is deleted after 30 days. The package of an applied preview is kept for 12 months, then erased. The history itself is kept without limit.

Applies from version 1.0 Verified for version 1.0

Was this article helpful?

Still need help? Create a request