The edit log and its retention, snapshots as versions, what restore does step by step, why uploads are blocked while editing is on, and what is deliberately not remembered.
An editable layer remembers in three ways, and they answer different questions:
| Memory | Answers | Where |
|---|---|---|
| Edit log | who changed which feature, when, from what to what | the item's Editing → History tab, and the API |
| Snapshots | what the whole layer looked like at a moment | the item's Editing → Snapshots tab and its version history |
| Versions | what was uploaded, and what was snapshotted, in order | the item's version history |
The original upload is never modified: it remains version one (or whichever version was hosted), so the earliest state is always there to download. Everything after it is log entries and snapshots.
Every applied change is one entry: the edit version it produced, the operation (created, changed, deleted, lock changed), the feature, the person, the moment, and the feature's row before and after. The layer's edit version (sync version) goes up by one per applied batch; Hyz Desktop asks for "everything since my version" with it, and every snapshot records the version it was cut at.
The History tab shows the last fifty entries and the checkouts other tools hold. The API returns the full log filtered by feature, person or version. Reading the log needs the history permission (editors and above on the item; contributors and above in the organization).
Retention. The instance folds the log past its retention window, ninety days by default and set by an administrator. Folding removes old entries and raises the layer's log floor; a Hyz Desktop copy whose version is below the floor cannot ask for "everything since" any more and is told to check the layer out again. Snapshots are not affected by folding.
Replays are recognised: a change that was already applied (the same client identifier) is answered with what happened the first time and changes nothing, which is what makes a retried sync safe.
A snapshot exports the live rows and stores them as a new version of the item, marked Snapshot in the version history, with the edit version and the feature count it was cut at. Taking one needs the lock permission and a layer with editing on.
A snapshot behaves like any version:
Two columns travel with a snapshot: the feature's revision and its lock flag. Who changed a feature and when do not, because a snapshot is data, not a log.
Take a snapshot before anything you may want to undo: before switching editing off to upload a new file, before a large filter lock, before opening a layer to a new team, and on a schedule if the layer matters.
Restore puts a snapshot's rows back into the live layer. It needs the lock permission, editing switched on, and a snapshot that has been scanned clean. In order:
Restore does not delete any version: the snapshot you restored from, the safety snapshot and the original upload all remain in the history.
A new file version cannot be uploaded onto an item while any of its layers is being edited: the answer is a layer is being edited; snapshot or disable first. The reason is simple: an upload builds a new Hyz Layer from the file, and the edited rows would stop being the item's current data. Take a snapshot, switch editing off, upload, and switch editing on again for the new layer if it should stay live.
A linked item is the exception you must manage yourself: its sync is not blocked by editing, so freeze the link into a hard copy before you switch editing on. See editable or not.