Article verified for Release 17.0 on October 11, 2026.
This article explains how user permissions are defined in the application, the difference between System Roles and Workspace Roles, and how the two role types combine to control user access.
For detailed instructions on how to create and manage workspaces, please refer to the article: How to Create and Organize Workspaces.
Understanding how permissions work
Permissions define which actions a user can perform and which parts of the application a user can access. Permissions are grouped into roles, and there are two primary types of roles:
- System Roles (Global): Define permissions that apply across the entire system.
- Workspace Roles: Define permissions that apply within a specific workspace.
The user’s permissions are determined by their System Role, which defines global permissions across the application. If the user is assigned to a workspace, their permissions within that workspace are additionally determined by their assigned Workspace Role.
System Roles
- Apply across the entire system, regardless of workspace.
- Take precedence over Workspace Roles when permissions overlap.
- Define broad access to global functionalities, such as user management, workspace management, and system-wide settings.
Workspace Roles
- Limited to specific workspaces.
- Grant permissions related to managing workspace-specific entities, such as tests, surveys, training courses, question pools, user groups, and users.
- A user can have one Workspace Role per workspace. The Workspace Role can be configured with a combination of the available workspace-specific permissions, based on the user’s responsibilities within that workspace.
- Users must first be added to a workspace to receive a Workspace Role. To learn how to assign users to a workspace, see How to Organize and Manage Users in Workspaces.
System Role vs. Workspace Role
- Scope: A System Role applies to the entire application, while a Workspace Role applies only to the workspace where the user is a member.
- Permissions: A System Role covers global functionalities. A Workspace Role covers workspace-specific entities.
- Assignment: Each user account has one System Role. Within each workspace where the user is a member, the user can have only one Workspace Role.
- Precedence: A System Role overrides a Workspace Role when both grant the same permission.
How System Roles and Workspace Roles interact
If both a System Role and a Workspace Role grant the same permission, the System Role overrides the Workspace Role.
Example: If a user has the System Role permission Question pool Manager, the user automatically has access to all question pools across the platform. This applies regardless of workspace membership or Workspace Role. Assigning a Workspace Role with a similar permission is unnecessary.
Note: To restrict a user’s access to specific workspaces, remove the corresponding permissions from the user’s System Role.
Recommended permission model
The recommended model separates global permissions from workspace-specific permissions:
- System Roles: Include permissions that are not specific to workspace entities and provide access to the application pages relevant to workspace entities.
- Workspace Roles: Include permissions for workspace entities, such as creating and managing tests, surveys, and training courses.
Example: A System Role includes the permission Create new tests, surveys, or training courses. Any user with this role can create these items anywhere in the system. To limit content creation to a specific workspace, remove the permission from the System Role and add the permission Create tests, surveys, or training courses to a Workspace Role. The user can then create content only in the workspace where the Workspace Role is assigned.
Key point: Workspace Roles apply only within the workspace where the user is a member. System Roles apply across the entire platform. Combining both role types controls what users can do system-wide and within specific workspaces, and it prevents permission overlap and unintended access.
Creating System Roles (Global)
System Roles should be created before Workspace Roles. A System Role for workspace administrators should include the permissions that are not specific to workspace entities, along with access to the pages where workspace entities are managed. Workspace privileges are defined later, in the Workspace Role.
The following permissions are suggested for a global workspace administrator role:
For more information on creating user roles, please refer to this article.
Creating Workspace Roles
Workspace roles are assigned within specific workspaces and determine what actions users can perform in that workspace. These actions may include:
- Managing tests
- Assigning users
- Creating surveys
- Editing training content
To create a workspace role:
- Navigate to the Workspaces section in the main menu, then select Manage workspace roles.
- Click the Create new button.
- Enter a role name.
- Choose the desired permissions. For the workspace administrator role in this example, select all permissions.
- Click the Save button.
Conclusion
System roles and workspace roles work together to provide a flexible and scalable permission structure. System roles ensure consistent access across the platform, while workspace roles offer localized control within specific workspaces.
By understanding how these roles interact, administrators can create clear permission boundaries, prevent unauthorized access, and maintain an organized user management system. Always define system roles first, then assign or map workspace roles based on your organizational structure and user needs.
For more related instructional materials, visit:
