Versions and rollback

Every publish archives the body it replaced. Sigil keeps the last ten published bodies of each template, and every template has its own independent history rather than sharing one.

Looking at a version first

The history can only tell you when each version was published and by whom, which is rarely what you are actually choosing between. Preview opens the archived version rendered as a signature, so you can see it before deciding.

It renders against sample data, the same as the editor’s preview with no mailbox named, so placeholders show where each person’s own details will sit. It does not render the version for a named individual.

The archived body is rendered as it was stored rather than validated again. A custom field retired since that version was published would otherwise make exactly the old versions worth looking at the ones that refuse to open.

Restore is offered from the preview as well as from the list, and goes through the same confirmation either way.

Restoring a version

Restore from the Versions view, using the signature picker to choose which template’s history you want, or from a template’s row menu on the Templates view.

Restoring publishes the old body as a new version. That is worth understanding: it is a forward action rather than a rewind, so the version you rolled back from is itself archived and stays recoverable. Rolling back a rollback works.

Restored versions reach users in seconds, exactly like any other publish.

Rollbacks are recorded in the change log.

Rollbacks and staged rollouts

Restoring a version is the recovery path for something that is already live for everyone. It is a real publish, and it takes a moment to notice the problem and a moment more to put it right.

A staged rollout is the path that avoids reaching that point. Because the live body never changes until the new version has proved itself, abandoning one republishes nothing and archives nothing. The two are worth keeping straight: one undoes a publish, the other declines to complete it.

A rollout that promotes behaves like an ordinary publish here. The outgoing body is archived and can be restored in the usual way.

Ten versions per template

The history holds ten published bodies per template. The eleventh publish drops the oldest.

If you are about to make a series of experimental publishes, consider duplicating the template and experimenting on the copy, so the original’s history stays intact.

For anything you want to keep permanently, export it. An exported bundle is a file you control, with no retention limit.

Recently deleted

Deleting a template moves it to Recently deleted rather than destroying it. It keeps its full version history and can be restored for 30 days.

An administrator who is certain can delete it permanently straight away. Anything left in Recently deleted is purged by a daily sweep once the 30 day window has elapsed.

Deleting is blocked while a template is assigned to a role or referenced by an assignment rule, so you cannot accidentally delete the signature people are currently receiving. Reassign first, then delete.

Restoring from Recently deleted puts the template back in the library with its history. It does not reassign it to a role, so you also need to point the role or the rule back at it if that is what you want.

What is not versioned

Version history covers template bodies. Other objects have their own lifecycle:

Images are replaced in place, and the previous file is not retained. Replacement needs the uploaded file to arrive under exactly the stored name, so a logo you want to update should be re-uploaded as Acme-Logo.png rather than as the Acme Logo.png still sitting on your desktop. Where the name had to be normalised, Sigil stores a numbered variant instead of overwriting. See images. The upload is recorded in the change log either way. Keep your source files.

Banners and footers are edited in place with no version history. They are small and quick to reconstruct, and the change log records that they were edited.

Assignment rules are replaced as one ordered list on each save. The change log records the edit.

The change log

The change log is the append-only trail of what happened: publishes, rollbacks, creates, renames, duplicates, deletes, restores, permanent deletions, role assignments and asset uploads, each with who did it and when.

Version history tells you what a template used to contain. The change log tells you who changed it and in what order. They answer different questions and are worth reading together when something has gone wrong.