Permission Reference

This page lists every permission that can be granted through a Permission Set, grouped exactly as in the permission-set editor, and explains what each one actually does.

Each permission offers up to five actions:

Action Meaning

Read

View the item.

Create

Create new items.

Update

Change existing items.

Delete

Remove items.

Allow

A single on/off grant for actions that are not create/read/update/delete (for example triggering a device action or opening a statistics page).

Only the permissions marked with a shield icon (Buildings, Floors, Rooms, Zones, Places, Devices, Networks and the Read action of MQTT) can be scoped to specific entities via Partial Permissions. Everything else always applies organization-wide.

Some permissions let a user extend their own access. Grant the Users & Permissions permissions only to people you fully trust as administrators:

  • Permission Sets (Create / Update): a user who can edit permission sets can put any permission into a set and assign it, effectively granting themselves or others unlimited access. This is as powerful as being an administrator.

  • Users and User Groups (Create / Update): controlling who is in which group, or which permission sets a user has, lets a person add themselves (or others) to powerful groups and inherit those permissions.

See Security-Critical Permissions below for the full list and Best Practices for guidance.

Building Structure

See also: Building Structure.

Permission Can be scoped? What it lets a user do

Buildings, Floors, Rooms, Zones, Places

🛡 Yes

Read, create, edit and delete the whole building hierarchy (buildings, floors, rooms, zones and the places inside rooms). Editing also covers placing devices onto a floor; deleting a parent removes everything inside it.

Device Management

See also: Devices, Networks, Enrollment.

Permission Can be scoped? What it lets a user do

Devices

🛡 Yes

Read, edit and delete devices in the inventory, including filtered searches. A device can always read and update itself, so this permission governs access to other devices.

Device Details

—

Show the extended detail cards on the device overview (technical, mesh and hardware information beyond the basic list). This is a Portal display flag only.

Device Custom Fields

—

Read and edit the organization’s definition of custom device fields (which extra fields exist), not the per-device values.

Device Provisioning

—

Read, create, edit and delete device enrollment configurations, including bulk creation. The self-service enrollment flow itself is not affected.

Networks

🛡 Yes

Read, create, edit and delete networks (sites) that connect Gateways and mesh nodes. Editing (Update) also unlocks mesh keys, environment profiles and pushing packages to the network, so treat it as powerful.

Diagnostic Logs

—

Download, upload and delete a device’s stored log files (debug, diagnostic and system logs). In the Portal this unlocks the Diagnostic Logs view for supported hardware.

Device Repository

Permission What it lets a user do

Manufacturers

Read, create, edit and delete the manufacturer and device-type catalog used by the device repository.

Device Groups

Read, create, edit and delete device groups and their membership. Update also reassigns devices between groups and triggers group-level actions; group data is shown across the configuration and device screens.

Sensors & Monitoring

See also: Sensor Data, Sensor Map, Building Automation.

Permission What it lets a user do

Sensor Data

Read sensor measurements of every sensor type (latest values, history and the aggregation queries behind charts) and write sensor values manually (for example on virtual devices). Read includes Environmental Sensors and the read access of Climate, Lighting and Shading Control.

Actuator Control

Send setpoints and commands to actuators, dispatched to the device over MQTT. The full grant controls actuators in all domains and makes the actuator control widgets interactive.

Sensor / Actuator / Indicator Metadata

Read the definition metadata (units, value ranges, retention) used to render sensors, actuators and indicators. Required together to export full building or network topology.

Climate Control / Lighting Control / Shading Control

Read sensor values and control actuators for a single building-automation domain (heating/cooling/ventilation, lighting, or blinds/shutters). Controlling a domain includes reading its values.

Environmental Sensors

Read room measurements such as temperature, CO2, humidity, VOC and loudness, without access to any other sensor data. Intended for the room view of the Office App, which shows these values and keeps them up to date over MQTT. It does not give access to sensor history, charts or the sensor pages of the Portal; those still need Sensor Data.

View Occupancy / Sensor / Sensor Map / Energy / Energy Saving Statistics

Show the corresponding analytics page in the Portal (occupancy, sensor statistics, the floor-plan sensor map, energy consumption, energy saving).
The View…​ permissions only show or hide the corresponding page in the Portal. They do not restrict access at the API level and they grant no editing rights; they only affect Portal page visibility.

Which Permission Reads Which Sensor Type

Sensor Data (Read) reads every sensor type. The narrower permissions each read a fixed list of types. This decides which values a user sees in the Office App’s room controls and which sensor topics a user with restricted MQTT Read may subscribe to.

Permission Sensor types it reads

Environmental Sensors

CO2, VOC, VOC_LEVEL, HUMIDITY, AIR_PRESSURE, TEMPERATURE, LOUDNESS, PRESENT_AMBIENT_LIGHT_LEVEL

Climate Control

SETPOINT_TEMPERATURE, SETPOINT_TEMPERATURE_ADJUSTMENT, CLIMATE_CONTROLLER_MANUAL_TEMPERATURE_ADJUSTMENT, MIN_TEMPERATURE, MAX_TEMPERATURE

Lighting Control

BRIGHTNESS, DIMMING, LIGHT_CONTROLLER_FEEDBACK_DIMMING

Shading Control

SLAT_POSITION, SLAT_ANGLE, DRIVE, DRIVE_STOP, SHADING_CONTROLLER_FEEDBACK_POSITION, SHADING_CONTROLLER_FEEDBACK_ANGLE

The measured TEMPERATURE is an environmental reading, while the temperature setpoint and its limits belong to Climate Control. Every type not listed here, for example WINDOW_CONTACT or indexed variants such as VOC_1, requires Sensor Data (Read).

Configuration

See also: Configurations.

Permission What it lets a user do

Configurations

Read, create, edit and delete configuration profiles and their versions and payloads. Devices only ever receive a published version.

Publish Configurations

Create and publish a new configuration version so it is actually rolled out to targeted devices. Without it, a user can edit a draft but cannot activate it.

Configuration Assignments

Read, assign and remove configuration versions on devices and device groups, and re-apply already-assigned configurations.

App Management

Permission What it lets a user do

Services

Read, create, edit and delete the in-app service catalog (categories and entries) shown to end users in the BlueRange/Office app.

Extended Properties

Permission What it lets a user do

Extended Properties

Read, create, edit and delete the organization’s custom property and metadata definitions (name, data type, unit, range, category).

Extended Property Assignments

Attach or remove custom property values on devices, buildings, floors, rooms, zones, places and networks. These values appear as chips on the device and building overviews.

Automations & Monitoring

See also: Monitoring, Notifications.

Permission What it lets a user do

Automations & Monitoring

Read, create, edit and delete automations (the same entity appears in both the Automation and Monitoring modules). Update also toggles an automation on or off, which starts or stops the rule.

Automation & Monitoring Assignments

Read, attach and remove automation bindings to target entities (devices, networks, buildings, floors, rooms, zones, places). Assigning is what actually deploys an automation.

Automation & Monitoring Templates

Read the AutoMate template catalog (schemas and renderers) used to build new automations.

Alerts

Read, create, edit and delete alert definitions (severity, type, name) that belong to an automation.

Alert Assignments

Read, attach and remove alert bindings to target entities.

Bluetooth Low Energy Advertising

See also: Beaconing, BlueRange Tags.

Permission What it lets a user do

Advertising Messages

Read, create, edit and delete the BLE beacon payloads a device broadcasts (iBeacon, Relution Tag, Eddystone-UID and Eddystone-URL).

Advertising Tags

Read, create, edit and delete device tags. A tag’s numeric id is what a device broadcasts as a Relution Tag and also drives BLE scanning; deleting a tag detaches it from all devices.

Device Actions

See also: KNX, BACnet, Updating the System.

Permission What it lets a user do

Device Action Management

Read the action queue/history of a device, and cancel or delete already-queued actions. Creating a specific action still needs the matching permission below.

Trigger Debug Diagnostics

Push a diagnostics action to a BlueRange Gateway that can change log levels, restart the gateway or its sub-services into debug mode, and upload its logs to the server.

Start Enrollment

Make a Gateway scan for and enroll nearby mesh/IoT devices.

Start KNX / BACnet Enrollment

Make a Gateway discover and enroll devices on the KNX bus or BACnet network.

Send Command to Device

Send a command or message to a device. On a BlueRange Gateway this delivers a terminal command; on mobile/asset devices it is delivered as a push notification.

Reboot Device

Remotely reboot a BlueRange Gateway.

Refresh Device Info

Ask a Gateway to re-report its current status, configuration and inventory to the server.

Start Reverse SSH Tunnel

Have a Gateway open an outbound reverse SSH tunnel to a relay host, giving interactive remote shell access from behind firewalls. Highly sensitive.

Upload Device Update

Push a firmware or software package to the Gateway’s mesh nodes and beacons, optionally as a gradual rollout.

Device Inactivity Notifications

Permission What it lets a user do

Rulesets

Read, create, edit and delete notification and automation rulesets for event-driven behavior.

Device Rulesets

Read, assign and remove which devices are monitored by a ruleset for inactivity.

Notification Settings

Read and configure how inactivity notifications are delivered (recipients and intervals).

Physical Access Control

Permission What it lets a user do

Salto External ID

Read, set and remove the Salto access-control identity linked to a user. Because that link is what lets an account obtain a physical door key, granting this effectively controls per-user door access.

Users & Permissions

This is the privilege-granting category. The permissions here control who can access the platform and what they are allowed to do. Anyone who can update users, user groups or permission sets can effectively raise their own or someone else’s access. Restrict them to a small group of trusted administrators.

See also: Managing Users, Managing Groups, Permission Sets.

Permission What it lets a user do

Users

Read, create, edit and delete user accounts. Update also resets passwords and changes a user’s group membership, so it can alter other users' access.

User Groups

Read, create, edit and delete groups and their membership. Update changes which permission sets a group grants, and therefore the effective permissions of every member.

Permission Sets

Read, create, edit and delete permission sets. Because a set can contain any authority, even ones the editor does not personally hold, this is effectively full administrative power when combined with the ability to assign it.

Access Tokens

Read, create, edit (expiry only) and revoke a user’s long-lived API tokens. Creating one mints a bearer token that authenticates as that user, shown only once. Users can always manage their own tokens.

Password Policy

Read and change the organization’s password rules, expiry, lockout thresholds and which MFA methods are enforced for every account.

Organization Settings

See also: Organization Settings.

Permission What it lets a user do

General Settings

Read and edit the organization’s identity (display name, unique name, address), the sensor-data retention period and the Look & Feel (logo, CSS, translations).

Support Settings

Read and edit the support contact details, imprint and the FAQ entries shown to users.

Device Inactivity Settings

Read and edit the device availability checks (ping intervals, per-device-class inactive thresholds, compliance behavior) and device ownership.

LoRaWAN Settings

Read and configure the LoRaWAN (The Things Industries) connector — region, application and API key — that links the organization’s LoRaWAN devices. The secret key is write-only.

AutoMate Settings

Enable, disable and pin the version of the AutoMate automation engine for the organization.

Salto Settings

Read and configure the organization-wide connection to the Salto access-control backend (host and credentials).

Accept Terms

Marks the holder (typically administrators) as subject to the terms-of-service acceptance flow; users without it skip the terms prompt.

System Information

Permission What it lets a user do

Server License Information

View the organization’s effective license — its entitlements and limits — and open the License page.

MQTT

Permission Can be scoped? What it lets a user do

MQTT Read

🛡 Yes

Connect to the organization’s MQTT broker and subscribe to its topics. Granted organization-wide, it covers all topics of the organization. In the Portal it also determines whether the live MQTT websocket is opened at login, so it is what a user needs to receive live sensor and device updates. Restricted to specific entities, it only covers their live sensor data, see Restricted MQTT Read.

MQTT Write

—

Publish on the organization’s MQTT topics, for example to send commands to devices. Grants MQTT Read as well — the read checkbox is selected and locked automatically. Always applies organization-wide, so a user who holds MQTT Write also reads organization-wide, even if the permission set is restricted.
Organization-wide MQTT access is not scoped to individual topics. It applies to all topics of the organization. Because the MQTT message bus carries most of the data flowing through the platform (sensor data, device state, commands and more), organization-wide MQTT Read exposes almost everything happening across the installation, and MQTT Write additionally allows injecting data and commands. Treat both as security-critical and grant them only to trusted users and integrations. Users who only need the live readings of their own rooms, such as Office App users, should get a restricted MQTT Read instead.

Restricted MQTT Read

From version 26.2.2, MQTT Read can be restricted with Partial Permissions. A user with a restricted MQTT Read may only subscribe to the live sensor data of the devices the grant covers, and only to the sensor types they may read (see Which Permission Reads Which Sensor Type). Nothing else of the organization is available to them over MQTT: no device state, events, actuator commands, beacon or asset-tracking data, and no publishing.

Which devices a grant covers follows the same rules as access to devices:

  • A grant With descendant elements on a building, floor, room, zone, place or network covers all devices below it, including devices added later.

  • A grant on a device covers that device.

  • This element only on a building element or network covers none of the devices below it, so it gives no live data.

  • A grant With descendant elements on the organization counts as organization-wide MQTT Read.

Keep the following limitations in mind:

  • Only the Office App uses it. A restricted MQTT Read only works with clients that request topic-specific credentials, which currently is the BlueRange Office App. The Portal’s live views need organization-wide MQTT Read: a user with a restricted MQTT Read can use the Portal normally, but sees no live updates (no error is shown). MQTT clients that log in to the broker directly, for example with an API token, get no topics of the organization either. Developers can request topic-specific credentials as described in API Authentication.

  • Checked when connecting. The topics are checked when the app connects. A connection that is already open keeps its topics when permissions change; the change applies the next time the app connects, for example when the user opens the room again.

  • Moved devices. After a device has moved to another room, its Gateway may keep publishing the device’s room readings under the previous room until it has received the updated network data.

For a complete setup see Example: Office App Users Limited to Their Rooms.

A third MQTT authority, MQTT Admin, exists on the server but is not part of any permission set and cannot be granted through the Portal. It only applies to the system organization and makes its holder an MQTT superuser: the broker skips all topic checks, giving unrestricted read and write access to the topics of every organization on the installation. It also permits opening a native MQTT connection without an enrolled device or an access token.

It is an installation-operator authority for running and debugging the broker itself, not an administrative counterpart to MQTT Read / MQTT Write within an organization.

Security-Critical Permissions

Keep the following restricted to trusted administrators, because they can be used to gain more access than intended:

Permission Why it is sensitive

Permission Sets (Create / Update)

A permission set can bundle any authority, even ones the editor does not hold. Editing one that is assigned to yourself, or creating a powerful one and assigning it, grants unlimited access. Treat as equivalent to full administrator.

User Groups (Create / Update)

Group membership carries permissions. Whoever controls memberships can add themselves or others to any group and inherit its access.

Users (Create / Update)

Allows assigning users to groups, resetting passwords and changing security settings.

Access Tokens (Create)

Tokens act on behalf of a user and can be used for programmatic access.

MQTT (Read / Write)

The MQTT message bus carries most platform and device data. Organization-wide Read is not scoped to individual topics, so it exposes almost everything happening on the platform; restrict it with partial permissions for users who only need the live data of their rooms. Write is always organization-wide, additionally allows publishing data and commands to devices, and implicitly grants organization-wide Read.

Networks (Update)

Also exposes mesh security keys and lets the holder push packages to the network.

Best Practices

  • Grant operational permissions freely. Device, sensor, configuration and automation permissions let teams do their job and carry no escalation risk. Give them to the groups that need them.

  • Restrict the Users & Permissions category. Reserve Users, User Groups and Permission Sets (especially Create/Update) for a small number of trusted administrators. Handing these out is equivalent to handing out administrator access.

  • Prefer Read over write. If a role only needs to see data, grant only Read and leave Create/Update/Delete off.

  • Be deliberate with Delete. Only grant Delete where a role genuinely needs to remove items.

  • Use the predefined roles as a baseline. The predefined roles already separate administrative from operational access sensibly; start from them and add custom sets only for what they do not cover.

See Also