Allowed operations, geometry, editable and required fields, own features only, the editing area, locked-by-default features and the conflict policy — each with the refusal it produces.
Rules are set once per layer by someone with the lock permission and apply to everyone who edits it, from every client. They are not permissions: permissions say who, rules say how. Changing a rule changes what every editor may do from their next save on; edits already in flight are re-checked on arrival under the new rule.
Open the item, pick the layer tab if the item hosts several, and use Editing → Rules. Every rule is saved together with Save rules, and every change is recorded as an audited event.
Editing on or off. Off is the state every layer starts in and returns to. Switching on needs a ready layer, counts against your plan's editable layers allowance, adds the system columns and the edit log to the layer, and from then on blocks new file versions on the item until you switch off or snapshot. Switching off keeps the rows as they are.
Create, edit and delete, in any combination. A layer that only allows edit is a layer whose shape is fixed but whose attributes may be corrected; a layer that allows create only is an inbox. Every operation a person attempts outside this set is refused with this operation is switched off for the layer, even when their role would allow it.
Off means attributes only: no vertex can move, no shape can be redrawn, and Hyz Desktop's geometry tools are greyed for the layer. A new feature still needs a geometry, because a feature without one cannot exist on a map; only changing existing geometry is refused. Refusal: geometry is not editable on the layer.
By default every field is editable. Untick a field to make it read-only for editors: its cells grey out in the browser and in Hyz Desktop, and a change to it is refused with this field is not editable on the layer. Mark fields required: a new feature whose required field is empty is refused with a required field is empty. A field must exist on the layer to appear in either list; the platform's own columns (revision, lock, who and when) are never editable.
A value that does not fit a field's type (text into a number, a date that is not one) is refused with the value does not fit the field, whichever rules are set.
On, an editor may change or delete only the features they created; anyone else's features refuse with only its creator may change it. People with the lock permission are exempt and may change every feature. Features that existed before editing was switched on have no creator and can be changed only by the exempt roles while this rule is on. A feature created from Hyz Field belongs to the collector, not to the reviewer who approved it.
Draw a polygon on the map (Rules → Draw an editing area, then click the corners on the Edit tab and finish). With an area set:
Refusal: outside the editing area. Remove the area returns the whole layer to the editors. The area is stored with the layer and drawn in violet for everyone who edits.
On by default: a feature someone adds is immediately editable by everyone the other rules allow. Off: every new feature is born locked, and stays so until a manager unlocks it, one by one or by a filter on the Locks tab. Combine it with an inbox layer (create only) and a Field campaign to get a review queue in which nothing is published until a manager has seen it. See permissions and locks for how locks behave.
Every feature carries a revision. A change says which revision it was based on, and when the feature has moved since, the two changes conflict. Two policies:
Deleting a feature someone else has just changed is a conflict too, under the same policy.
For a single change the server asks, in order: is editing on for the layer; is this operation allowed; is the person allowed this operation; does the change touch a field that does not exist or is read-only; is the geometry well formed. For a new feature: is there a geometry; are the required fields filled. For an existing feature: does it still exist; is it locked; is it the editor's own (when that rule is on); is geometry being changed while geometry is read-only; has the feature moved since it was read (conflict). Last, inside the database: do the values fit the fields, does the geometry type match the layer, and does the result fall inside the editing area. The first "no" is the reason you see. Why an edit was refused lists every reason with its fix.
An archive that hosts several layers has one switch and one set of rules per layer. Roads can be editable with a fixed shape while parcels stay read-only; each layer tab shows its own Editing panel, its own history and its own snapshots.
| Goal | Rules |
|---|---|
| Corrections to attributes only, shapes fixed | operations: edit; geometry off; required fields as needed |
| A field inbox reviewed by a manager | operations: create; new features start unlocked off; a campaign targets the layer; the manager unlocks approved features |
| A team maintaining one district each | operations: create, edit, delete; one editing area per team layer; editors change only their own features on; conflicts reject |