本文基于面向某个垂直行业的SaaS系统的设计经验，抽象出一套适合中小企业的权限管理体系，目标是最大限度保留系统弹性的同时，把系统复杂度和开发成本尽可能降低。enjoy~
面向企业级的SaaS（软件及服务）系统，由于企业用户的规模和内部管理模式千差万别，设计一套具备足够弹性、符合绝大部分目标企业用户需求的权限管理系统，是一个很大的挑战。
我们可以看到，市面上面向多个行业的综合性SaaS系统，例如销售易、纷享销客等，由于它们的目标客户跨越了多个行业、多种规模，这些企业具备各种各样的内部管理风格和模式，在权限系统的管理上，往往做得非常复杂，不仅具备部门、角色、职位、数据等各个维度的权限管理，各个功能模块还有自己独立的权限管理，虽然具备最大的弹性，却给企业的系统管理带来较大的负担。
本文基于面向某个垂直行业的SaaS系统的设计经验，抽象出一套适合中小企业的权限管理体系，目标是最大限度保留系统弹性的同时，把系统复杂度和开发成本尽可能降低。
提炼的三个核心原则：
功能和数据权限分离
部门和角色分离
围绕上述三个基本原则，我们力图在满足中小企业需求的前提下保持足够的弹性，并严格控制复杂度和开发成本。详细描述如下。
1. 权限从上到下分为三个层级：企业账号（老板账号）、管理员账号、普通账号
对于中小企业来说，公司的实际控制人，往往是公司的创始人或自然人大股东，因此企业账号的使用者以及对应绑定的手机号码，都是公司的实际控制人，他应该掌握最核心、权限最大的企业账号，所以也可以称为“老板账号”。
但是在实际场景中，公司的实际控制人并不会直接管理公司的业务支撑系统，因此，需要在系统首次部署时，创建好企业账号，并由企业账号授权给某一个或多个系统管理员，由系统管理员去完成日常的角色创建、员工导入等工作。系统管理员，对应的一般就是HR或行政部门的管理人员。当然，企业账号的权限高于管理员账号，如果是小微型企业，也可以由企业账号直接替代管理员账号的功能。
除了企业账号和管理员账号之外，其他各级员工所持有的账号，都属于普通账号。普通账号的部门、角色、数据等权限的设置，一律由系统管理员配置。
三个权限层级示意图如下：
在实际系统中的核心业务步骤如下：
（1）企业购买系统时，创建一个企业账号，这个企业账号绑定的手机号码为公司实际控制人的手机号码。该手机号码必要时可以解绑（例如公司实际控制人变更），由于该功能触发频率很低，因此不需要在前端功能中实现，只需要在购买协议中写明，“购买企业可以通过书面方式提出企业账号手机号码绑定变更需求”即可。
（2）在部署和培训阶段，可指导企业账号持有人创建一个或多个管理员账号，该账号一般授权给行政总监或人力资源总监，后续配置即由管理员账号进行。
（3）管理员账号持有人需要接受系统培训，掌握部门创建、角色创建、功能和数据权限分配等基本操作。管理员所有操作都必须记录在案，供企业账号持有人监督，且管理员操作触发异常行为规则（如大量分配高等级权限等）时，系统会通过短信方式通知到企业账号持有人，确保企业账号对管理员的全方位掌控。
（4）企业账号可随时将管理员账号禁用或设定为离职，但管理员账号不可对企业账号进行任何配置或操作。
功能权限，定义为可见、可以操作的功能范围。例如某一部分菜单，或者某个页面里的各种操作。
数据权限，定义为若干个数据类型里的具体可见范围，例如“客户”就是一个数据类型，它的权限举例如“无权限”、“我的客户”、“我所在部门的客户”、“我所在部门及下级部门的客户”。
通过功能权限和数据权限的分离，我们可以做到以下场景：需要开拓和维护客户的角色集合，都可以拥有“客户”这个菜单的权限，但不同的角色进入“客户”菜单的列表时，看到的客户范围各不相同，极端情况是看不到任何客户。且不同角色在同一个客户页面上，能进行的操作也不同，例如有的角色可以新建客户，有的却不行，这就要由功能权限来控制。
可见，通过功能权限和数据权限的分离和配合，我们在具体的权限分配上有了非常大的弹性，且在技术层面的后台系统的设计上，也非常合理、清晰。
而在具体设计上，需要保证以下4点：
正确区分功能和数据，入口性和操作性的都应该归类为功能
正确对数据进行分类，避免存在分类后的某些数据存在交集
数据分类到多细的颗粒度，需要由行业特性决定
数据权限区分为查看、编辑和删除
示例图如下，由于涉及具体产品，对某些文字进行了打码：
3、部门和角色分离
部门的定义，自然就是公司行政组织架构下的部门。
在本设计方案中，角色等同于职位，而在许多大型的SaaS系统中，为了更大的灵活性，往往会把角色和职位分开，但根据我们的判断，对于中小企业，设定角色一个就够了，职位当然还存在，但仅仅是一个不涉及权限管理的文本title了。
以一个销售公司来说，角色可以包括：“渠道专员”、“渠道总监”、“销售专员”、“销售经理”、“总经理”等等。
所谓的部门和角色分开，就是不同的部门可以有相同的角色，例如如果有渠道一部、渠道二部，则这两个渠道部的员工的角色都可以设定为“渠道专员”，这两个部门的管理者都可以设定为“渠道经理”。再配合功能和数据权限，则进一步配置“渠道专员”具有“渠道”菜单的功能权限，其能够查看的渠道数据权限范围则仅为“我的”，而“渠道经理”同样具有“渠道”菜单的功能权限，但其能够查看的渠道数据权限的范围则扩大为“部门”。
具体设计上：
最大部门即为公司
不同部门可以配置相同角色
4. 权限系统和其他功能设计的关系
总结完权限系统三个核心的基本原则后，我们还需要指出一点：权限系统的设计方案，在整个系统中绝不是孤立的，它能否实现设计目标，并和整个系统完美配合，还需要做到以下几点：
首先，菜单和功能的设计，必须是最小颗粒度，否则就和数据权限产生冲突。例如：我们只需要一个“客户”菜单即可，不同角色在“客户”菜单里能干什么事情，由功能权限和数据权限配合进行控制，但切不可出现“我的客户”+“全部客户”两个菜单，这明显和数据权限有根本冲突，且也是一种不优美、不合理、扩展性差的设计。
其次，数据的分类，必须符合业务需求，且划分合理。有些数据都是公开的可以不归入数据权限进行管理，所有角色默认都有即可；有些数据需要进一步细分，例如同样以“客户”举例，在某些公司的业务规则中，就需要将客户的基本信息和联系信息分开控制，管理层可以看客户基本信息，但只有客户负责人才可以看联系信息，这种情况就需要将客户的数据权限分为“客户基本信息”和“客户联系信息”两个。
最后，权限变更的记录和所有账号的行为轨迹记录一样重要。权限系统本质是进行权力的限制，没有监管的权力必定是会失控的。在出现问题的时候，必须同时配合权限变更的记录、角色变更的记录和账号的行为轨迹记录进行追责和存证，确保维护企业的合法权益。
总结
