The Quick BI supports the custom role permission system to help enterprises secure and flexible organization and operation management. From users, resources, to role permissions, it meets the multi-level security compliance requirements of the enterprise. Users are assigned by multiple posts and roles. Users are assigned to specified roles in batches for unified management and clear functional boundaries. From organization-level to space-level roles, it supports highly customized permission control for each functional module and performs its own duties within the scope of security protection functions. This topic describes how to customize organization roles and workspace roles, and add users to custom roles.
Limits
Only the Professional Edition supports custom roles.
Feature description
Preset official role: supports a default spatial role. You can delete the default official role and bind a new custom role.
At the organization level, three preset organization roles are Organization Administrator, Permission Administrator, and common user.
At the workspace level, the following roles are preset: workspace administrator, workspace developer, workspace analyst, and workspace viewer.
Custom roles: Enterprises can add multiple roles for users based on actual application scenarios, and support custom organization-level roles and space-level roles.
Functional permissions: You can define the scope of functional permissions for a specified role based on actual application scenarios.
Resource permission: supports organization-level and space-level centralized resource authorization.
Go to the Event Center page
On the Quick BI homepage, follow the instructions in the following figure to go to the Role Management page.
Organization Role
Create an organization role.
On the Roles page, create an organization role as shown in the following figure.
Configure feature permissions.
On the Role Management page, configure the permissions of the role as shown in the following figure.
NoteBy default, the Metric Monitoring, Subscription Management, and Embedded Analysis modules are selected for a new organization role. You can clear the check box or add other modules.
You cannot modify the permissions of a preset organization role.
Organization administrator is the role with the most permissions in an organization and can manage all features in the organization. Supports metric monitoring, subscription management, resource package management, organization-level AK/SK, embedded analysis, custom components, and enterprise security modules.
Permission administrator supports the following modules: metric monitoring, subscription management, embedded analysis, and enterprise security.
common user supports metrics monitoring, subscription management, and embedded analytics modules.
Add role users.
On the Roles page, add a role user as shown in the following figure.
After you click Add User, the selected user appears in the Role Users list.
You can continue to select users from the user list on the right to add users.
You can switch to a user group and add multiple members to a user group at a time.
You can click Show User Group (①), Select All Users in Current User Group (②), or Select Some Users in Current User Group (③).
After you click Add User, the selected user appears in the Role Users list.
Deletes a role user.
In the User Role list, move the pointer over the target user and click the
icon in the upper-right corner. In the Dismiss Role message, click OK to delete the user. 
You can delete multiple users in batches as shown in the following figure.
Change role users in batches.
In the role user list, click Change Role as shown in the following figure.
On the Change Role page, select the roles that you want to change to and click OK.
Workspace Roles
Create a space role.
On the Roles page, create a workspace role as shown in the following figure.
Configure feature permissions.
On the Role Management page, configure the permissions of the role as shown in the following figure.
NoteBy default, the display permission of each module is selected for the newly created workspace role. You can select or clear the check box for the function module. You can add the create (edit) permission of each module and the use permission of datasets and data sources.
You cannot modify the permissions of a preset workspace role.
The workspace administrator has the permissions to create, edit, and view all modules. The workspace administrator is the role that has the most permissions in the current workspace. In addition to the preceding permissions, the workspace administrator can manage the permissions and works of other members in the workspace.
The workspace developer has the permissions to create, edit, and view all modules.
Spatial analysts have the permissions to create (edit) and view BI portal, dashboards, data dashboards, worksheets, ad hoc analysis, and self-service retrieval modules, view data forms and data sources, and use and view datasets.
The workspace viewer has the permissions to view all modules.
Add role users.
On the Role Management page, you can view the list of role users. The list of newly created role users is empty. You need to configure the role users on the Workspace Members and Information page.
Follow the instructions in the following figure to go to the Workspace Members and Information page and add a role user.
In the Add Workspace Member dialog box, configure Members and Roles.
You can select Users or User Group.
For more information, see Add workspace members.
Click OK. The user is added to the workspace.
On the Role Management page of the workspace, the user appears in the Role Users list.
Deletes a role user.
On the Workspace Management tab of the Workspace Management page, find the workspace that you want to delete and click the
icon in the Actions column. 
For more information, see Delete a workspace member.
Scenario 1: The administrator role of a custom data dashboard
This topic describes how to use a custom role to grant role permissions to employees in a position. This way, employees can use BI functions within their functions.
Background information
Assume that Xiao Ming, an employee of your enterprise, is an employee of the publicity team of the marketing department. You want him to only use the data dashboard for external display.
Procedure
Assume that you are a new customer. You can perform the following steps to assign a role to Xiaoming:
Create a workspace as shown in the following figure. In this example, it is "Propaganda Department Demonstration Space".
The role of the new workspace is the big screen administrator.
You can also create or edit a dashboard and use the dataset and data source for the dashboard administrator role.
On the Workspace Management page, add Xiao Ming as the administrator of the demo space of the Propaganda Department.
At this time, Xiao Ming can only see and use the data big screen module, and reasonably use BI functions within his functional scope.
Assuming you are a regular customer:
Xiao Ming's existing permissions are: Xiao Ming is already in the space, the organization level is the common user role, and the space level is the developer role. Xiao Ming can see all function module directories under the space, and can create and edit all functions.
You can follow the following steps to give Xiao Ming the corresponding role:
The role of the new workspace is the big screen administrator.
and grant the user role of the dashboard administrator the permissions to create or edit dashboards and use datasets and data sources.
On the Space Members and Information page, change Xiaoming's existing initialized space developer permission to the big screen administrator.
At this time, Xiao Ming can only see and use the data big screen module, and reasonably use BI functions within his functional scope.
Priorities
This section describes the logic of permission priority in two scenarios.
Permission Priority
From a functional perspective, functional permissions are greater than spatial resource usage permissions.
From the perspective of resources, functional permissions are restricted by space resource permissions.
Scenario 1
User permissions: Xiaoming is already in the space. The organization level is the common user role and the space level is the developer role. Xiaoming can view the directories of all functional modules console in the space and can create (edit) all functional modules such as dashboards, workbooks, data dashboards, data sources, and datasets.
Change user permissions
The organization administrator enters the role management center and creates the Dashboards No Permission role. The corresponding permissions are as follows, that is, no permission to create or view dashboards.
On the Space Members and Information page, change the permissions of the Space Developer role to the No Permissions on Dashboards role.
At this time, Xiao Ming cannot see the dashboard entrance of space A and cannot operate the dashboard. That is, Xiao Ming's permission to use the dashboard in the original space resources is invalid.
Therefore, the function permissions are greater than the space resource usage permissions.
Scenario 2:
Existing user permissions
Xiao Ming has been in space A, the organization level is the common user role, the space level is the role of space analyst.
Xiao Ming can see console all directories in space a, cannot operate data sources and data sets, and can only operate the reports he has created.
At the same time, Xiao Ming was authorized to edit the three reports made by Xiao Zhang in space A.
Change user permissions
On the Space Members and Information page, change the permissions of Space Analyst to Dashboard Administrator.
The following table shows the permissions of Dashboard Administrator.
At this time, Xiao Ming can only view the dashboard in the space, and can manage his own reports and the three reports authorized by Xiao Zhang.
Therefore, function permissions are also subject to space resource permissions.