Our role management system provides flexible, precise control over user permissions with default and special roles, allowing for granular access and stacked permissions to meet specific organizational needs.
Role Management
Roles and permissions control what users can see (access) and what they can do (permissions). You assign roles in different contexts (organization, division, site, specific items), and the platform combines them to compute a user’s effective capabilities.
If you are looking for how to invite users, assign roles, or manage groups, see: User and Group management articles.
Key concepts
Access vs permissions
Access determines where a user can go (which divisions, sites, twins, plans, folders).
Permissions determine what actions a user can perform in that context (create, edit, delete, publish, download, manage access, etc.).
A user can have access to an item but still be blocked from actions if their role does not include the required permission.
Role stacking (permissions combine)
Users can receive roles from multiple places. When that happens, the platform combines the permissions.
Example: A user can be a viewer on a Site (inherited visibility), and an editor on one specific Twin inside that Site. The combined result is “viewer everywhere in the site, editor in that twin.”
Inheritance and nested context
Access in RealityPlatform follows the organizational hierarchy. When you grant access at a parent level (for example a Site), that access can be inherited by the items inside it, such as a Twin, a Plan project, or 3D data.
Nested context allows you to control what role, or no access, is applied to those inherited items.
For example, you can grant a user access to a Site but restrict them to:
RealityTwin only
RealityPlan only
3D Data Viewer only
Or block access to specific products entirely
This gives you fine-grained control over how access propagates through the hierarchy.
For a detailed explanation of how Divisions, Sites, and content are structured, see the Organizational Structure article.
Role types
Administrative roles (settings access)
Administrative roles control permissions associated to organization and division, such as:
Users and groups
Permissions
SSO and integrations
Subscription and invoices
Important information:
Super Admin has full administrative access. Other admin roles can be limited to specific settings pages and can be scoped to specific divisions.
Super Admin can’t be removed or edited.
Administrative roles can be scoped to specific divisions, or to the organization (all divisions, including new divisions created later).
A user can have only one administrative role.
Content roles (product and content actions)
Content roles control what a user can do within:
Content hierarchy (divisions, sites, folders, data)
RealityTwin
RealityPlan
3D Data Viewer (data bundles)
Permissions are granular and typically include view, create, edit, delete, publish, download, and similar actions.
Default roles (Standard model)
For organizations without role customization enabled, each context includes three predefined roles:
Manager
Editor
Viewer
These roles are predefined and cannot be modified.
Manager
Managers have full control over the specific content where they are assigned.
Typically, a Manager can:
View, create, edit, and delete content
Publish or download when applicable
Manage collaborators (invite or remove users)
Configure settings related to that content
Use case: project leads, site owners, administrators responsible for delivery.
Editor
Editors are contributors. They can perform most operational actions within the content, but cannot manage access.
Typically, an Editor can:
View content
Create and edit entities (assets, zones, measurements, layouts, etc.)
Save changes
Use most tools available in that product
Editors cannot invite or remove collaborators from that content.
Use case: designers, engineers, operators contributing to the project.
Viewer
Viewers have limited permissions.
Typically, a Viewer can:
View content
Navigate the project
Use read-only tools (depending on the product)
Viewers cannot modify content or manage access.
Use case: stakeholders, clients, executives, read-only reviewers.
Permission matrix
Each product and context (Content, RealityTwin, RealityPlan, 3D Data Viewer) includes a detailed permission matrix that defines exactly what Manager, Editor, and Viewer can do.
To see the exact actions enabled for each role:
Go to Settings → Permissions
Select the relevant context
Review the permission matrix
For Enterprise organizations with role customization enabled, these default roles can be used as a starting point and extended with additional custom roles. See Role customization (Enterprise) section
Role customization (Enterprise)
Role customization allows Enterprise organizations to create roles tailored to internal governance.
Create a role
Go to Settings → Permissions
Choose the section you want (Administrative, Content, RealityTwin, RealityPlan, 3D Data Viewer)
Click Create role
Name the role
Select the permissions
Save
Edit a role
Go to Settings → Permissions
Select the role
Update the permission checkboxes
Save
Tip
Start from a standard manager/editor/viewer pattern and make minimal changes.
Keeping roles simple makes them easier to troubleshoot.
Special rule: Access management
If a role includes Access management permission (ability to share content or invite collaborators), the platform requires that role to also include the underlying permissions for that context.
Reason: a user who can manage access could otherwise grant themselves a higher role.
Practical guidance: treat Access management as a high-trust capability, similar to a manager or owner level.
Deleting roles (fallback required)
If you delete a role that is assigned to users or groups, you must choose a fallback role. Users assigned to the deleted role will automatically be reassigned to the fallback.
After releases: new permissions default off for custom roles
When a new feature introduces a new permission:
Standard built-in roles may be updated automatically.
Custom roles do not automatically receive new permissions, new permissions are disabled by default until an admin enables them.
If users report that a new feature is missing, review the permission matrix and update the relevant roles.