数据权限是B端产品经理需要掌握的技能点之一，这篇文章，作者从数据权限的基础概念开始讲起，向我们介绍了数据权限管理模型、特殊业务场景的通用设计，文末还提供一种特殊的权限设计思路，我们一起来看下吧。
上一篇分享了功能权限设计，这一篇详细分享数据权限架构。文末会提供一种特殊的权限设计思路，一定要看到最后哦！
一、数据权限基础概念
1、数据权限
数据权限管理：定义登录用户可以查看哪些数据记录。即：定义用户登录系统之后，可以查看哪些客户、哪些订单、哪些产品等数据记录。
2、对象级数据权限
对象级数据权限包括：对于功能对象数据的增、删、改、查四类操作：
- 查：用户允许查看数据；
- 增：用户允许创建数据；
- 删：用户允许查看并删除数据；
- 改：用户允许查看并修改数据。
注：增、删、改这三类权限，通常在功能权限控制中也可以通过按钮是否可以使用来进行控制，但对象的数据权限定义时，也会对这个对象是否允许增、删、改进行限制。数据权限定义到对象层，是更底层的权限限制，如果对象数据限制不允许创建，即使开放创建按钮也无法新建。
二、数据权限管理模型
1、基础权限模型
- 全部数据安全性：允许用户查看系统所有数据。一般授予系统管理员、企业高层（如：CEO、CFO等）
- 本部门及下级部门数据安全性：允许用户查看当前部门及下级部门的所有数据，默认是按数据创建人归属的部门进行查看，即：查看数据创建人的部门为登录用户的部门或者下级部门的数据。一般授予部门负责人
- 本部门数据安全性：允许用户查看当前部门的所有数据，默认是按数据创建人归属的部门进行查看，即：查看数据创建人的部门为登录用户的部门的数据。一般授予部门负责人
- 本人及下级数据安全性：允许用户查看本人及下属员工的所有数据，默认是按数据创建人进行查看，即：查看数据的创建人为当前用户或者下属员工的数据。一般授予部门负责人、小组组长等
- 本人数据安全性：允许用户查看本人的所有数据，默认是按数据创建人进行查看，即：查看数据的创建人为当前用户的数据。一般授予普通业务人员
权限管理基础模型可支持较为简单的一些业务场景，如：客户管理中，销售业务员仅查看自己创建的客户，销售总监可以查看销售部的所有客户，CEO可以查看企业所有客户。
2、基于数据归属人的权限模型
在实际业务中，稍微复杂一些的场景，基础权限模型就已经远远无法满足业务需求了。
以一个实际场景来说明：企业希望通过拨打400热线电话做售前咨询的客户，分配给到销售人员进行做跟进成交。由客服人员在CRM系统中为客户建档，然后分配给到销售业务员跟进。
在这个场景中，客户的创建人为客服人员，基础权限模型可以满足每个客服只能查看自己创建的客户。但是，对于销售人员而言，这部分客户都不是自己创建的，也就没办法查看到这部分客户，无法开展工作。
那么在这种情况下，我们就需要重新来定义数据归属，什么是“我的数据”。通常情况下，数据的创建人会默认认为是数据的归属人。但是，由于业务的需要，数据记录会在不同的用户之间进行数据的转移操作，也就是说：在这种情况下，数据的创建人并不一定是数据的归属人。
那么在上诉的场景中，客户数据的归属人，在数据创建时，归属人为客服人员。当客服人员将客户分配给到销售业务员时，销售业务员成了数据的归属人。在基础的权限模型中，将原本通过创建人/创建人所属部门为基础的权限优化成通过归属人及归属部门为基础的权限，就可以解决销售人员无法查看到客服创建的客户数据了。
3、基于角色自定义归属的权限模型
在企业复杂的业务场景中，【基于数据归属人的权限模型】同样没办法满足较为复杂的业务需求。将【2】中的实际场景再做延伸进行说明：
客户分配给到销售业务员进行跟进后，在跟进过程中，如果需要报价给到客户时，销售业务员需要加入报价专员负责报价。
在这个场景中，数据归属人为销售业务员，报价专员也需要加入进来，能够查看到客户，为客户进行报价。但是在这个过程中，销售业务员仍然需要跟进客户，数据归属人没办法直接转移给到销售业务员。
那么在这种场景下，我们又需要重新来定义数据的归属，“什么是我的数据”。
- 对于客服人员而言，创建人为自己的是我的数据；
- 对于销售业务员而言，销售业务员为自己的是我的数据；
- 对于报价专员而言，报价专员为自己的是我的数据。
也就是说，对于不同角色的用户而言，“我的数据”的定义是不同的。那么就需要能够给不同角色去定义“什么是我的数据”的能力。
那么，在进行权限配置时，支持用户在定义角色的同时，还需要支持用户定义“我的数据”。如下图：
在配置不同功能模块的数据权限时，除了定义权限类型（本人可见、本部门可见等），还可以支持用户自定义配置权限字段，以满足不同角色可以查看到不同的“我的数据”。
如：
- 客服人员根据“创建人”字段查看我的数据；
- 销售业务员根据“销售员”字段查看我的数据；
- 报价专员根据“报价员”字段查看我的数据。
三、特殊业务场景的通用设计
1、权限覆盖
在实际业务场景中，当用户访问某一数据记录时，该记录关联了其他的单据，用户需要同步查看关联的这部分单据数据。
如：CRM系统中的客户数据，客户同时关联了联系人数据、订单数据、合同数据等。当用户查看客户A时，需要查看到A客户的所有联系人、订单、合同数据。但是由于客户A可能有多个销售同时跟进，该客户的联系人、订单、合同信息并非都是由该用户创建，单一的数据权限便无法满足该业务场景。
那么，当用户操作访问客户A的权限时，他需要同步可以获取到访问A关联的业务单据对象数据的权限。即：拥有客户对象数据的访问权限时，需要覆盖客户相关联对象原本的数据权限。
2、团队成员
在实际业务中，对于某一记录，需要将数据共享给到多个用户共同访问、编辑。如：对于商机的跟进，需要不同角色的人员参与，需要销售人员负责维护客户、顾问负责方案制定、实施人员进行可行性评估、报价专员制作报价、投标人员负责投标资料整理等。对于不同的商机，不同角色对应的业务员均不一样，需灵活指派员工进行负责。
那么，在这种场景下需要有个群组的概念，将这部分人员组成一个群组对数据记录负责，并且共享相关内容，这个群组即是团队成员的概念。由数据的负责人进行组建，可将相关用户加入团队成员中，共享指定的数据记录。
3、共享规则
团队成员适用于灵活组建数据负责群组的场景，不同的数据记录可组建不同的团队。那在实际业务中，会存在一些相对固定的数据共享的场景。
如：公司派遣一名导师去到不同的门店进行指导。当培训导师去门店进行指导前，就需要将该门店的订单数据共享给到导师。这种场景下，每个订单去添加导师的访问权限明显是不现实，这就需要有批量共享的能力，将该门店的订单打包共享给到培训导师。
那么，对于这种有固定规则的数据共享场景，可以将这些固定规则统一抽象，形成共享规则，更方便地完成数据共享。
4、岗位层级
一般的权限设计中，数据权限通常与人、组织进行绑定。但是通过人和组织进行绑定的方式，比较难解决一些特殊的业务场景，如：
- 企业的人员变动频繁，人员的离职/入职需要完成大量的数据交接工作；
- 一人多岗的业务场景下，难以实现不同岗位的数据权限隔离，如：用户不同岗位的上级领导查看对应岗位的数据。
引入岗位，可以将数据与人解绑，通过岗位与数据进行关联。员工离职的数据继承，可以通过继承岗位进行实现；一个多岗的场景，用户不同岗位的数据与各岗位关联，岗位的上级领导只能查看对应岗位的数据。
那么，首先要在系统中建立岗位层级管理，岗位与组织架构类似，也是自上而下的树状结构。顶层为企业CEO，一层一层向下延展。
其次，在数据记录中记录数据关联的用户岗位，一人多岗的场景下，数据关联的岗位可以由用户手工选择或者默认为当前登录的岗位等，可根据实际业务而定。
四、特别的权限设计架构 – 页面级数据权限控制
目前，市面上大多数产品的数据权限均控制在对象层，在具体的功能对象上按角色设定数据权限。当拥有该角色的用户登录系统后，在该对象的各个页面均根据设置的数据安全性执行数据查看。如：销售人员角色的用户设定了允许查看本人的客户数据权限，那么客户的各个页面，销售人员均查看自己创建的数据。
这种权限架构下，有一些特殊的场景无法满足，如：销售人员查看客户数据时只允许查看本人的客户数据。
但是，销售人员在做客户报备时，需要根据提报的客户数据，在系统中与全部客户数据进行查重，查看客户是否已经报备过。在这种场景下，对象级权限控制则无法满足业务，销售人员因只允许查看本人的数据，报备时也只能与本人的客户数据进行查重。
这里分享一种特殊的权限设计架构，页面级数据权限控制。注：这种权限设计架构可以满足大部分的业务场景，但是，整体权限架构较为复杂，维护成本也相对较高，并不推荐所有的系统数据权限设计按这个模式设计，仅作为思维拓展。
首先，在对象层设定数据权限时，设定的是数据权限模板，如：本部门的数据安全性，设定按哪个部门（创建部门、归属部门、更新部门等）字段作为权限字段；本人的数据安全性，设定按哪个用户（创建人、归属人、更新人等）字段作为权限字段。
其次，在页面层按不同的角色可设定引用哪一个数据权限模板。如：对于销售人员而言，客户列表执行本人的数据安全性，仅可以查看自己创建的客户数据；客户报备页面执行全部数据安全性，销售人员可根据客户信息查询系统所有客户数据。
本文由 @茶话B端 原创发布于知识吧，未经许可，禁止转载
题图来自Unsplash，基于CC0协议