Data Permission Management

1. Layer business packages in FineBI following the principles of "Be convenient for data distribution and management, improve system performance, and facilitate data maintenance and updates." The goal is to minimize cross-level associations, control the magnitude of updates, and simplify data permission allocation.

2. Considering the differences in industry and warehouse structure, companies can create business packages or groups in FineBI according to the company's business type, system, user department, and person in charge of the business package. For example:

3. Follow the responsibility system when managing business packages.

• Assign each business package/group to data administrators as needed. Typically, the raw data is managed by IT personnel, the basic data is handled by department data analysts, and the analysis table is managed by the business personnel who create the table.

• Ensure the data quality of their business packages/groups, including but not limited to ensuring no duplicate data tables, correct indicator logic, and consistent data calibers.

•  Keep the business package data as the only source of official data output. The data released by the business package administrator is the only official data for the corresponding module.

• An example of a permission allocation and maintenance system:

4. The four elements of business package naming are the business/system/user department, the business package level, the data information, and the person in charge of the business package. Enterprises can name business packages according to the actual condition and do not have to strictly follow the naming rules. For example, some customers usually simplify naming and omit some prefixes in the actual application. For example:

5. In addition to dividing groups and business packages by organization, system, and business subject, you can also create a public group to store tables for public use by multiple departments in the BI system and tables used for configuring BI permissions to facilitate the subsequent detailed permission assignment and avoid confusion. At the same time, administrators should notice the valuable data concluded by business users through self-analysis to continuously improve the public data tables.

6. Here is an example of the business package design.

Dataset Naming Rules

The name of a public dataset interprets the data the most clearly. Clear naming helps to reduce communication costs and helps users quickly know the dataset content.

The recommended naming rules are as follows.

1. Department_dataset content_creator

2. Analysis indicator_business purpose_creator

3. Table granularity_business meaning_database source

Data Management

A business package should include raw data, basic data, and analysis tables, and tables of the same class should be stored at the same level. After grouping business packages by department or business, divide the data of each group into raw data, basic data, and analysis tables.

The construction rules are as follows.

1. Raw data consists of tables from the operational data store (ODS), and are not directly used in FineBI. It is non-essential but serves as an underlying layer for maintaining scalability. Data redundancy may occur in case of large data volume. Select tables as needed.

2. Basic data consists of tables from the data market (DM), with specified business meanings and coverage.

• Creation rules: High cohesion and low coupling.

• Fields in the table must be highly matched with the subject of the basic table.

3. Analysis tables are summary tables obtained by business personnel through processing basic tables in FineBI, requiring no adding by administrators. Administrators only need to prepare the raw data and basic data and allocate permissions.

Public Data Management Approach

Data Preparation in FineBI 5.x and Public Data in FineBI 6.0 provide public data to users within the enterprise. If the data in these modules is not well managed, poor data utilization may occur in the long run due to the continuous increase of redundant resources, the gradual confusion of data lineage, and the increased difficulty in data usage.

Super admins as well as all secondary admins (users with permission to manage public data) shall wittingly:

1. Publish and remove data following rules: Comply with corresponding rules to publish and remove public data and record necessary information.

2. Observe data table maintenance responsibility system: Each data table must have a clear person in charge, who is responsible for the interpretation, question answering, error checking, and subsequent maintenance of the data.

3. Improve public data description: A simple but comprehensive description of the public dataset can help others to use it.

4. Clarify the logic and boundaries of the dataset: Ensure that the connections and distinctions between datasets are clear, and avoid multiple tables for the same business.

The ideal public data is as follows.

• Public data is grouped by business modules and users can find all the required data in the team directory, with only one copy of each data table (no longer distinguishing between the types of data tables).

• Public data is of good data quality, with clear dimensions, consistent criteria, and clear primary keys. Users no longer need to confirm dimension information or verify whether the calculation caliber meets expectations. During joint analysis, cross-source data can be correlated smoothly and are not forcibly put together.

• Rights and responsibilities are clear. All data tables published to the public module have undergone strict review and similar data are not repeatedly published.

• It supports the release of data models, and users can refer to or reuse the existing data models, which are also constantly optimized with the newly drawn analysis conclusions.

A well-managed directory of the BI system can improve the efficiency of users, while the opposite may cause unnecessary misunderstanding and dissatisfaction among users.

1. Directory nodes can be named following the organizational structure and special classification as needed.

2. The directory level should not exceed three.

3. It is prohibited to set dashboards and directory nodes at the same level at the same time.

4. After the user applies to publish a dashboard, the business administrator shall confirm to which directory the user wants to mount the data and review the content and efficiency of the dashboard. The inspection items include but are not limited to:

• Whether functions work properly;

• Whether the color scheme and UI design meet the standards;

• Whether the data is accurate;

• Whether the component name complies with standards;

• Whether the loading time is in line with performance requirements;

• Whether the necessary text description is included.

5. The dashboard name can be in the format business meaning_responsible person, such as "Platform user analysis_peter". through which users can know the purpose of this dashboard in combination with the directory name.

BI Permission System

Permission Scope

Permission Allocation Object

The data permissions in FineBI can be allocated by department, position, role, and user.

Among them, the configuration of permissions for a user takes priority over that for other objects. If a user is configured with permissions (with a yellow/grey guy icon on the right side of a node), the user’s permission settings to that node prevail over those for his/her department/position/role.

If user permissions are configured on department, position, and role dimensions, the final permission is the union of those settings.

• If a user belongs to multiple permission carriers, such as User A belongs to Department A-Position 1, and Role A, the permission settings of different carriers for the same permission entity (dataset) jointly take effect.

• If a user belongs to multiple permission carriers, such as User A belongs to Department A-Position 1, and Role A, the permission settings of different carriers for different permission entities jointly take effect.

Unified Allocation Workflow

It refers to designating a system administrator to handle all permission allocation, including:

1. Initial authorization: During the system construction and promotion, administrators will add many datasets and dashboards into the system, to which the initial permissions should be set according to the results of permission research.

2. Permission application and authorization: During usage, users may gradually find that their permissions fail to meet analysis needs. To grant permissions, a permission approval workflow should be created with an entrance for permission application.

3. Permission viewing: After allocation, if you want to view the allocated permissions, you can use the Export Permission plugin or check them in the system authorization logs. 

Hierarchical Authorization Strategy

In large and medium-sized enterprises, in addition to a unified super admin, FineBI also needs to set up subordinate administrators to grant the permission of permission allocation to each business module to facilitate daily work. This scenario can be achieved by the hierarchical authorization function. For details, see Sub-admin Permission Scope.

Note:

The super admin should set standards for the daily authorization by sub-admins in advance and review their work regularly.

Implementation Scheme

Case Studies

A total of more than 100 data tables are spread across 10 departments in a company. Two departments with typical data characteristics were selected based on the previous information collection to build the permission system.

Data characteristics of Department A: There are three different job levels, namely team leader, team member, and intern. The team leader can see all the data of the department and usually does not conduct data analysis. Team members can see most of the data and need to conduct data analysis. Interns can only see a small part of the data and do not need to conduct analysis.

Data characteristics of Department B: There is only one position and everyone is familiar with all the data in this department, but they belong to different stages in the workflow. "Business personnel" only need to view the data analysis results, "analyst" is responsible for further developing the processed detailed data to obtain the results required by business personnel, and "developer" is responsible for introducing and standardizing the department's data for use by analysts.

The two departments share a data operator named Kate, who knows the data of both departments well, especially which data is sensitive, which data can be shown to external people, and which data can be made public.

Based on these data characteristics, the company has designed the following permission logic table.

Permission priority from high to low is listed below.

• Authorization permission

• Adding, deletion, and modification (management) permissions

• Usage permission

• Viewing permission

In enterprises, managers usually hope that users at different levels can only view the data within their permission scope, such as certain data rows for their department or business line, or only certain users have access to specific data fields (for example, only the manager can see salary information, while others can only see basic personal information). FineBI allows setting row and column permissions to achieve this scenario.

For details, see Assigning Partial Data Permission of a Data Table.

For detailed configuration cases, see:

• Viewing Corresponding Data Based on the Login User's Information — Example One 

• Viewing Corresponding Data Based on the Login User's Information — Example One

• Assigning Permission for a Multi-level Organization

• Quadruple Table Model 

In addition, for data obtained through a direct connection, using system username parameters, department parameters, etc. for control is advised. For details, see Assigning Permissions Through System Parameters.