Permissions concept

Overview

The permissions concept describes what building blocks make up access in niotix—essentially: what someone may do, where that applies, and how rights are assigned in practice.

Permissions define which actions are allowed on which object types (for example read-only vs full management of Digital Twins). Access scopes define which account and related data those rights apply to—and for Digital Twins, in which object context Virtual Devices and data sit. Roles bundle several permissions into a package; roles are assigned per access scope for each user so every permission does not need to be set individually.

A UI feature or API action is only available when both apply: the role includes the permission required for the action, and the access scope covers the data in question. That means there is no separate “master switch” aside from role and access scope—both must fit the task.

Broad permissions such as all.manage bundle many capabilities and are intended for system administrators; they do not replace choosing specific rights where possible. Principle: Grant only as many permissions as each role actually needs—prefer several well-scoped roles over blanket maximum access.

Step-by-step instructions for modules, Role Editor, and Default Role Wizard are under Permissions. The data model and relationships are described under Data model & definitions.

Permissions

A permission always describes two things: what it applies to—an object type in the platform, such as Digital Twin, Virtual Device, or user management—and what is allowed, i.e. the action (read, create, edit, manage, and similar). In technical names, actions are often short English labels such as read, write, or manage; depending on the object type, additional or different actions exist.

Points to note:

  • Not every permission maps to a menu item. Some only drive background behaviour or access for other modules (e.g. lists without full detail views).
  • Combinations matter. Whether a view or action is available often depends on several permissions at once (e.g. read permissions at different levels).

Access scopes

An access scope limits where a permission applies. Without a matching scope, even an existing permission does not apply to the data in question.

From an organisation perspective, two variants matter (see also the diagram under Data model & definitions):

  • Access scope in the user / account context: Defines which accounts (parent and sub-accounts) and related structures a user may access. Parent accounts typically “inherit” visibility and administration downward—someone who may manage a parent account often covers sub-accounts as well; the reverse is not automatic.
  • Access scope in the Digital Twin context: Security context for Digital Twins and their Virtual Devices. Sub-branches may have their own scope or, depending on how they were created, be covered under a parent twin’s scope.

In short: permissions describe the “what” (which action on which object type); access scopes describe the “where” (which tenant or object context).

Roles

A role is a named set of permissions—similar to a template (e.g. read-only, or managing integrations). Roles are maintained per account: a role is visible and usable only for the account it was created for, not globally for the whole installation.

Users and API keys are assigned roles per access scope. The same user can have different roles in different scopes (e.g. full rights on the main account, limited on a sub-account).

Default roles define which roles new users receive for a chosen scope when no different selection is made on creation—reducing maintenance and keeping initial rights consistent.

How it fits together

As in the overview: roles supply the bundled permissions; assignment to a user or API key is per access scope. The UI and API check each action whether the required permission exists in the appropriate scope.

This is implemented technically as attribute-based access control (matching object type, action, and scope). For day-to-day use it is enough to remember: permission + valid access scope + assignment via roles.

Configuration in the UI

  • Settings → Permissions: modules, Role Editor, Default Role Wizard—details and lists of platform permissions: Permissions.
  • Settings → Accounts: create or edit users and set access scopes and roles per user.