In this article, we will discuss the role-based permissions that determine what tasks you and other users can perform in the Qubit platform.
Each user in a property can be assigned 1 or 4 roles, from the most basic, Viewer, to the most advanced, Owner.
Each of these roles can be augmented with an additional set of permissions through the role Reporting, which enables a user to create and configure Qubit Exports.
DANGER: The role Reporting gives user access to customer data and potentially sensitive personal data. The assignment of this role should therefore be done with caution.
Refer to the following table for details of each role:
Role | Permissions | Additional permissions | Example |
---|---|---|---|
viewer |
| Can view experiences but cannot build new experiences, edit, pause, or publish | |
contributor |
|
| Can do all of the above plus create and pause experiences and create Recommendations rules, but cannot publish experiences |
publisher |
|
| Can do all of the above plus publish and republish experiences |
owner |
|
| Can do all of the above plus create and edit users and user permissions |
reporting |
| Can be applied to any role to allow the user to create and configure exports |
For each of the above roles, and especially for organizations with multiple properties, it is important to understand that the users you can view and manage depends completely on the properties that you yourself have permissions in. This is the scope of your permissions as a user.
WARNING: You can only view and manage users in properties in which you also have some form of permission.
As an example, if an organization has 10 properties, but you only have permissions for 2 of them, you will only see those users in the 2 properties that you have access to. Users in the other 8 properties will be invisible to you. Look at the following example:
In the above example, User 1 has permissions in 2 of 10 properties for TEST ORG. User 2 has permissions in 4:
The column PROPERTIES reports the number of properties a user has permissions for that you also have permissions for. Note in the above example, this is 2 and not 4.
User 1 will not see that User 2 has permissions for 2 further properties, a total of 4, for TEST ORG, because User 1 does not have permissions for those additional 2 properties.
This concept of scope also applies when you search for a user or filter the list of users by organization or property.