Basic knowledge of "authority design" of backend system

Toogee: Permission design is usually hidden deep in the background system, so much so that we all know it when we talk about it, but when we really face complex business needs and logical relationships, we are a little at a loss.

This article is a review of my previous permission design. I hope that while I am reorganizing it myself, I can also bring some ideas to other friends.

1. Requirements and background of permission system design

1. Complex business processes

As the business becomes more and more complex, previously only one salesperson was needed to follow up on an order, but now it requires five salespeople to collaborate to complete the process of an order (each salesperson is responsible for one of the processes).

At this point, we can use the permission system to grant the five sales people the authority to handle their respective processes (for example, Sales A only has the authority to enter intended orders, Sales B only has the authority to supplement customer information, etc.). In this way, each sales person can only see the information that flows to him or her, simplifying the complex process.

2. Information Sensitivity

When there are more than one department at the same level, competition will arise within the same company. For example, the user data that Sales Team 1 has worked hard to mine does not want to be seen by Sales Team 2.

The permission system can set the data of different departments to be independent of each other, and even the team leaders cannot see each other's data.

3. Safe operation and clear rights and responsibilities

In a large system, the consequences of a misoperation can be very serious.

The existence of the permission system avoids this kind of problem to a large extent. As long as the functions appear on the interface, they can be operated or will not cause serious consequences.

4. Keep the page simple

If the system does not have permission management, then each account will see the same interface after logging in, which is filled with all kinds of irrelevant and redundant information, and may even require special training and cost a huge amount of money to learn.

Through the management of the permission system, each account can only see the information related to itself after logging in, so that it can understand the business within its scope of work more quickly.

2. Basic composition of the permission system

The permission system is mainly composed of three elements: account, role, and permission.

• An account is a unique identification for logging into the system. An account represents a user. You can register it yourself or the system administrator can register and assign it to you.
• Roles are used to assign permissions to accounts in batches. In a system, it is impossible to customize permissions for each account, so a "role" is assigned to the same type of accounts to achieve the purpose of batch assigning permissions.
• Permissions are divided into operation permissions, page permissions and data permissions.

Operation permissions refer to the operations that users can perform, such as whether they can add, delete, edit, etc. Page permissions refer to the pages that can be viewed. Data permissions refer to the scope of data that can be viewed.

A simple example is as follows:

3. Example of Permission System Design

1. Example Background

This is an order management system, through which roles such as sales and customer service complete the entire order flow.

The system has a large number of users, a complex hierarchy, and a large number of sales teams that compete with each other at the same level.

2. Account Management

The process of creating an account in the current case is: the administrator creates a new account in the system, and the user activates it by email. The default role is "Staff", which only assigns the most basic permissions.

In order to reduce the workload of administrators, it also supports uploading via Excel, and the Excel format can be standardized according to the template.

3. Role Management

The role in the current case is "position", and users with different "positions" have different permissions.

The entry for role management is on the "Permission Management" page, which only has basic functions such as adding roles, editing roles, deleting roles, and adding role descriptions.

Usually, mainstream backend systems also have functions such as copying roles. Copying roles means: when creating a new role, first select an existing role with similar permissions, and then modify the permissions of the new role. This avoids the tedious situation where each new role must be re-set when there are too many permissions.

4. Permission Management

In actual design, many systems will choose to merge page permissions and operation permissions into functional permissions, such as the current case:

Each page has a master switch. Turning it on means assigning page permissions. For all fields on the page, there are four main operation permissions: add, delete, query, and modify. If you need to set separate operation permissions for some sensitive fields on the page, you can open the advanced settings and configure field-level operation permissions. As shown below:

In the current case, when there are multiple teams competing at the same level, the need for data authority allocation cannot be met simply by position, so we introduce "departments" to ensure that sales teams at the same level keep their information confidential and compete fairly.

In addition, higher-level departments, such as city managers or even general managers, should have the authority to see all data of the department they are in charge of and the subordinate departments.

Therefore, the "department" permission group has been divided into levels, and data permissions are further allocated according to the levels. For example, grassroots sales can only see their own data, sales team leaders can see the data of their department, general managers can see the data of their department and subordinate departments, and general managers can see all data.

We have placed the departmental hierarchy on the company settings page as an introduction to the company's organizational structure.

Written in ***

This is the basic structure of the permission system, but the actual permission design varies greatly.

In addition to understanding the basic concepts, you should also design the most appropriate permission system based on actual needs. You can also refer to the permission design of some mainstream backend systems to understand similar problems and how other systems solve them.

A small tip: Instead of going through the trouble of registering and trying out various backend systems, it is better to go directly to the official website to find help documents.