The states a data item moves through — uploaded, scanned, hosted, published, editable, snapshotted, replaced, deleted — and what each state allows.
A data item moves through a small number of states, and each state decides what can happen next: whether the file can be downloaded, whether a layer is drawn, whether a service is served, whether anyone can edit. This page walks those states in order, from the first upload to deletion, and says at each step what is allowed, what is refused and why. Kinds of data names the shapes; this page is about time.
Every data item, room and map shows where it is, in the same badge everywhere — at the top of its page and on its card or row in a list. It is the platform's own word, not the page's guess.
| Stage | Meaning | What to do next |
|---|---|---|
| Draft | no clean version yet | upload a file, or wait for the scan |
| File | a clean file, not online | Make a service |
| Online | the layer is online, not published | Make a service |
| Service | published — read-only or editable | use it in a map, a campaign, a dashboard |
Beside the stage: the visibility (private, organization, unlisted, public), the origin when it is not a plain file (linked — a live source; copy — cloned or an offline copy; result — made by a Workspace tool), and whose it is (mine, my organization, someone else's). A table chip marks an item with no geometry.
Someone else's public item can be opened and downloaded once you are signed in — nothing more is asked. To make a service from it, clone it to your space first; the copy is yours, and the badge on it says copy. A linked item can be turned into an offline copy with Take an offline copy, which saves the source as a version you can make a service from.
A room's badge says empty, items or services (every item has a service); a map's says static map or service map.
An item starts as a named container with a visibility: private (you and the people you grant), organization (every member of the owning organization), unlisted (anyone with the link) or public. It also carries a licence, an optional description in both languages and the topics it belongs to. Creating an item counts against your plan's data items allowance. Nothing else happens until a version arrives.
Something you cannot reach answers not found, never forbidden: an item you have no access to looks exactly like an item that does not exist. That holds for every state on this page.
Every upload adds a version numbered one higher than the last. The file is stored exactly as sent, its checksum recorded, its format recognised from the name, and a quick inspection reports the coordinate system, geometry type, feature count and extent when it can. That inspection is help, not a gate: a file that fails it is still stored, only marked as carrying no geometry.
Two things can refuse an upload:
A new version is pending until the virus scanner answers. Pending versions are not served to anyone; the owner can see them listed but cannot share or download them. The scanner's answer is final:
| Verdict | What it means | What is served |
|---|---|---|
| clean | no threat found | everything: download, share, map, hosting |
| infected | a threat was named | nothing, to anyone, ever; the version stays as a record |
| unsupported | the scanner could not read the file (too large, an unknown container) | nothing; upload a smaller or plainer file |
| pending | no answer yet, or the scanner was unreachable | nothing; the scan is retried |
Scanning is fail-closed. An instance whose scanner is down does not serve new uploads until it is back. Instances that run without a scanner mark every version clean on arrival and say so.
Only the newest clean version represents the item on maps, in pickers and in rooms. Older clean versions stay downloadable by number; a pinned reference in a data room keeps pointing at the version it was pinned to.
When hosting is switched on for the instance, every clean version is handed to the GIS engine automatically, except snapshots. The engine copies the geometry into the platform's spatial database, in your own schema, and the result is a Hyz Layer with a state you can follow on the item's Hyz Layer panel:
| State | Meaning | What you can do |
|---|---|---|
| queued, inspecting | waiting for or reading the file | wait |
| needs a mapping | the coordinate system could not be decided, or the archive holds several layers and none was chosen | choose the coordinate system, or pick one layer or all of them, and retry |
| importing, indexing | rows are being written and indexed | wait |
| ready | the layer is queryable | publish it, switch editing on, check it out in Hyz Desktop |
| failed | the engine refused the file; the reason is shown | fix the file and upload a new version, or retry |
| archived | the rows were dropped; the file remains | nothing; the item was deleted or the layer replaced |
A version that carries no geometry (a table, a raster, an ordinary file) ends as failed with a plain reason and is not a layer. That is expected, not an error in your data.
A multi-layer archive produces one Hyz Layer per source layer, each with its own state, key, publish switch and editing switch. Everything below the item's layer tabs belongs to the layer tab you picked.
A ready layer can be published: tiles, features and, on request, OGC endpoints under one stable reference. Publishing has its own visibility, private (Haiyz accounts that may view the item) or public (anyone, metered), and counts against your plan's publications allowance. The publication carries a revision. It starts at one and moves when you republish after a new version, and it also moves when people edit the layer, so a map that follows the publication sees edits without anyone republishing. Unpublishing stops the service and keeps the reference for a later republish. An optional offline archive (PMTiles) is built per revision and goes stale when the layer changes after it. See published layers for how maps and projects should use a published layer.
Someone with the manager permission on the item switches editing on for a ready layer. From this moment:
The owner then sets the rules (which operations, which fields, an editing area, whether editors may touch only their own features, how conflicts are settled) and may lock individual features. The whole editing model, who may edit and how, is in editable layers and the pages after it.
Switching editing off keeps the rows as they are. People can no longer edit, checked-out copies in Hyz Desktop cannot sync, and uploads are allowed again.
A snapshot freezes the live rows into a new version of the item, marked Snapshot in the version history, carrying the sync version it was cut at. It is scanned like any version, counts against storage like any version, and can be downloaded or shared, but it is never hosted as a layer of its own. Restore puts a snapshot's rows back into the live layer: the current state is kept as a safety snapshot first, then the rows are swapped, and every Hyz Desktop checkout of the layer expires because feature identities change. Snapshots and restores need the manager permission. See history, snapshots and restore.
When editing is off, a new clean version builds a new Hyz Layer, and the item's current data becomes that version. Republish to move the publication's revision to it. The earlier layer's edits live on in the snapshot you took before the upload, and in the earlier version's history. Editing starts switched off on the new layer; switch it on again if the layer should stay live.
For a linked item, a scheduled or manual sync is what brings a new version, and a sync is not held back by editing. Do not switch editing on for a linked item that still syncs: the next pull builds a fresh layer and the edits stop being the current data. Freeze the linked item into a hard copy first, then edit the copy.
Access is decided on every request, never cached on the client:
Sharing covers the mechanics; who may edit covers the editing half.
A nightly job applies the instance's retention windows, skipping organizations under legal hold:
| What | Default window | Effect |
|---|---|---|
| Edit log of an editable layer | 90 days | older log rows are folded away; a Hyz Desktop copy older than that must be checked out again |
| Items marked removed | 30 days | deleted completely |
| Personal items of erased accounts | 30 days after erasure | deleted completely |
| Hyz Desktop checkouts | 30 days from check-out | expire; the desktop asks for a fresh checkout |
Versions are never purged by age or count. Storage only comes back when you delete a version's item.
Deleting an item is one ordered cascade: share links are revoked, the item leaves every data room, its publications are unpublished and their views dropped, its Hyz Layers are dropped (the rows marked archived), its files and previews are deleted from storage, its storage allowance is released, and the item disappears. What survives on purpose: sealed copies inside maps and presentations (a live map layer loses its data with the item), a room's access log, and tool-run records.
Two things can stop a delete: you lack the delete permission (owner, or an organization role that carries it), or the item was promoted into the Open Data catalog and must be taken out of the catalog first. Editing being on does not stop a delete; it stops uploads only.
| From | Event | To | Allowance touched |
|---|---|---|---|
| nothing | create item | empty item | data items |
| empty item, or any item | upload a version | version pending | storage |
| pending | scanner answers | clean, infected or unsupported | |
| clean version with geometry | hosting on | Hyz Layer queued → ready | |
| ready | publish | published, revision 1 | publications |
| ready | switch editing on | editable, sync version moving | editable layers, then edits per month |
| editable | snapshot | a Snapshot version | storage |
| editable | restore a snapshot | safety snapshot, rows swapped, checkouts expired | storage |
| editable | switch editing off | read-only Hyz Layer, uploads allowed | |
| read-only layer | upload a version | new layer, new current data; republish to follow | storage |
| any | mark removed | purged after the window | |
| any | delete | gone; copies in maps survive | storage released |