Version history
On a versioned model, each save writes a new numbered version that is never altered afterwards. You can list a record's versions, compare one with the one before it, and restore an earlier one.
Which models keep history
A model keeps history when versioning, publishing or variants is switched on for it. All three are off by default and are set per model. On a model with none of them, an update replaces the data in place.
What the console shows
The History tab on a record lists its versions with the author's name and the change description. From there you can compare a version with the one before it, or restore it. The description is optional through the API and the CLI, and the console fills in "Content saved" when an editor leaves it blank.
Restoring adds a version
A restore brings the old version's content back as a new version, validated like any other save. History only moves forward, and the version you restored from is unchanged. If the model has changed since that version was written, the restore drops fields the model no longer declares and refuses values in a shape it no longer accepts.
Checking a restore first
foir records revert takes a --dry-run flag. It reports what would be converted, dropped or refused, writes nothing, and exits non-zero if the revert would be refused. The revert mutation in GraphQL has a matching dryRun argument.
How long history is kept
History is kept for a window that depends on your plan, and a daily sweep reclaims versions older than that. Some versions are kept whatever their age: the one being edited, the published one, one queued for a scheduled publish, one that a rollout's rollback would restore, and the newest version of every record.
Read the detail
The records guide explains how versions are written, how long they are kept and what a restore does when the model has changed.