The two questions every edit must pass, the six editing permissions, which roles carry them on the item and in the organization, what always wins, and how feature locks work.
An edit reaches the rows only when two independent questions both say yes. They are asked in this order, on the server, for every change in every save, and a client never decides either of them:
A "no" to the first question refuses the whole operation for that person. A "no" to the second refuses one feature and lets the rest of the batch through.
Editing adds six fine-grained permissions to a data item. You never grant them one by one; roles carry them.
| Permission | What it allows |
|---|---|
| read records | see the layer's features and its capabilities |
| create records | add features |
| update records | change attributes and geometry of existing features |
| delete records | remove features |
| lock records | switch editing on and off, set the rules, lock and unlock features, take snapshots and restore them |
| read the edit history | see who changed what and which checkouts exist |
Grant a person or a group a role on the item from its Share controls. Each role includes the ones below it.
| Role on the item | Editing it carries |
|---|---|
| viewer | read records |
| editor | create, update and delete records; read the edit history |
| manager | everything an editor has, plus lock records: the switch, the rules, locks, snapshots, restore |
| owner | everything a manager has, plus deleting the item |
An item owned by an organization is also reachable through the member's organization role, without a grant on the item:
| Organization role | Editing it carries |
|---|---|
| viewer, security admin | read records |
| contributor, editor, publisher | create, update and delete records; read the edit history |
| content manager, admin, owner | everything above, plus lock records |
A person holding both an item role and an organization role gets the stronger of the two.
Permissions are checked on every request and never cached on a device. A role removed while someone is editing in Hyz Desktop takes effect on their next sync: the changes they made offline are refused one by one with you do not have permission, and stay on their machine.
Every feature carries a lock flag. While it is set, the feature cannot be changed or deleted by anyone, through any client, until someone with the lock permission clears it.
status equals approved) and press Lock matching or Unlock matching.A lock is a fact about the feature, not a permission. Nothing on a client can lift it, and no role bypasses it. The manager who locked a feature must unlock it to edit it.
One rule, Editors change only their own features, has an exemption: people with the lock permission (managers and owners on the item, content managers and above in the organization) may change anyone's features. Every other rule applies to everyone equally; see the rules.
Pointing a campaign at a layer needs the create permission on that layer for the person setting the target. When a record is approved, the reviewer's permission to create records on the layer is checked again at that moment, and the feature is recorded as created by the collector, so the own-features rule later treats it as theirs. See feeding a layer.