A member’s rights come from three places: their built-in role, the groups they are in, and any access policies. This page explains permissions, the Access Rights matrix and groups. Access policies are in Access policies.
Permissions and minimum roles
Every action in Hermetry is guarded by a permission, for example iot_device.devices.read (see devices) or iot_rpc.send.privileged (send privileged commands). Each permission has a minimum role (Owner, Admin or User). A member can use a permission when:
- their built-in role is at least the minimum role and the organisation’s matrix grants it to that role, or
- one of their active groups grants it and the minimum role is Admin or User.
A group can lift a member over an Admin minimum, but never over an Owner minimum. Owner-only permissions (ownership transfer, deleting the organisation, raw commands, firmware signing keys, rotating API keys) stay with owners whatever groups say.
Permissions belong to modules. A module your plan does not include adds no permissions to the lists below.
Access Control
Open Settings > Access Control (address /admin/settings/access-control): “Roles, groups and the permission matrix for this organization.” It has three tabs.
Access Rights
The matrix of “Which permissions each role/group is granted.” Rows are the permissions of your enabled modules, grouped by module; columns are the built-in roles and your groups. Use Filter permissions by name, key, group or module… to find a row.
- Tick or untick cells.
- Select Save (n), where n is the number of changes.
“Locked cells (the Owner column and owner-only permissions) can only be changed by the owner.” Where an access policy applies, its deny always wins over the matrix.
A permission a module update added, for which your organisation has no rule yet, shows as Allowed by default: the platform default applies, so members can use it if their role meets its minimum role.
Groups
“Built-in roles are fixed; create custom groups to grant tailored permission sets. Groups appear as columns in Access Rights.”
To create a group:
- Select New group.
- Enter a Key (lowercase, dotted, for example
plant.north.operators; “Cannot be changed later”) and a Label. - Select Create, then open the group to pick its Permissions (Search permissions…, Select all or Clear per module) and add a Description.
- Leave Active on. “An inactive group keeps its members but grants nothing — the way to switch a permission set off without unassigning anybody.”
From template… adds a ready-made group (below). Deleting a group removes it from every member.
Users
“Assign each member’s role/group.” For each member, change the Role or select Edit under Groups to assign groups. “Groups only add permissions on top of the built-in role — they never take one away.”
You can also assign groups from a member’s page with Manage groups, and check the result on the member’s Permissions tab (Effective access). See Users and roles.
The IoT group templates
| Template | Gives |
|---|---|
| IoT operator | “Watches and edits devices and writes their attributes. No device credentials, no creating or deleting devices.” |
| IoT viewer | “Sees every IoT page and list (devices, profiles, alarms, places, cameras, firmware, rules, certificates, LoRaWAN, endpoints, device settings) and is given no right to change anything. No credentials, keys, eSIM, panel sessions or settings pages.” |
Templates offer only permissions of modules your organisation uses. Once added, a template group is an ordinary group: you can edit, assign or delete it.
Typical setups:
| Person | Role | Groups |
|---|---|---|
| Field technician | User | IoT operator |
| Auditor, customer viewer | User | IoT viewer |
| Integrator who builds flows and profiles | Admin | none |
| Plant manager who approves firmware | Admin | none |
Common IoT permissions
| Permission | What it allows | Minimum role |
|---|---|---|
iot_device.devices.read | View devices | User |
iot_device.devices.create / .update / .delete | Create, edit, delete devices | Admin |
iot_device.credentials.manage | Issue, rotate and revoke device credentials | Admin |
iot_device.attributes.write | Write device attributes | Admin |
iot_device_profile.profiles.read / .write | View / change device profiles | User / Admin |
iot_alarm.read, iot_alarm.acknowledge | View and acknowledge alarms | User |
iot_alarm.resolve, iot_alarm.mute, iot_alarm.rules.manage | Resolve alarms, mute devices, manage alarm rules | Admin |
iot_rpc.send.basic | Send basic commands | User |
iot_rpc.send.privileged, iot_rpc.send.critical, iot_rpc.commands.manage | Send privileged and critical commands, manage the command catalog | Admin |
iot_rpc.send.raw | Send raw commands | Owner |
iot_ota.packages.manage, iot_ota.assign | Manage firmware and assignments | Admin |
iot_ota.keys.manage | Manage firmware signing keys | Owner |
iot_rules.read, iot_rules.run, iot_rules.mode | View rules cards, run them, switch manual/auto mode | User |
iot_rules.manage | Create and change rules cards | Admin |
iot_provisioning.claim, iot_provisioning.quarantine.activate | Claim licensed devices, activate quarantined devices | Admin |
iot_pki.certificates.read, iot_pki.certificates.revoke | View and revoke device certificates | Admin |
automation.read, automation.manage | View and edit flows | Admin |
dashboard.boards.read, dashboard.boards.write | View and edit own boards | User |
dashboard.boards.manage | Manage shared boards | Admin |
The full list is in the Permissions reference.
Good practice
- Prefer groups over raising a role. A User with the IoT operator group cannot see credentials or change settings; an Admin can.
- Keep group keys meaningful: they appear in the audit log and in access policies (
subject.roles contains 'plant.north.operators'). - Review the Access Rights matrix after you add a module: its new permissions start as Allowed by default.