对于SaaS系统的权限，就是登录账号的功能权限和数据权限的合集。
功能权限是账号在平台上能看到哪些页面，能操作页面里面的哪些功能或按钮。数据权限就是这个账号能在系统中看到哪些数据，能对哪些数据做功能级的操作。功能权限一般靠角色和功能集进行关联，即RBAC模型。数据权限一般靠靠租户的组织架构来实现数据的隔离。然后账号和角色关联，获得功能权限，和组织架构关联，获得可管理的数据。下面对相应内容做详细介绍。
一、组织架构解决数据权限
在实际运营场景中，稍微大点的公司，组织架构相对比较复杂，层级比较多，每个层级节点要看到的数据要求是不一样的，所以要对不同层级节点的数据做隔离。例如，某餐饮公司组织架构如下，则总部的CEO要看到下属分公司的所有数据，分公司的总经理要看到所有下属区域的数据，朝阳区区域经理要看到下属所有门店的数据，门店店长要看到店里的所有数据。所以要在平台账号权限中引入组织架构，账号直接跟组织架构关联，在哪个层级看到哪个层级的数据，通过组织架构对多层级数据进行隔离。总体来说，账号关联组织架构时，需要确定下来方位的数据精确到哪一节点，是本节点及下级节点数据，或只有本节点数据，或指定的某个下级节点数据，或是只能管理属于自己创建的数据。特殊的也会存在跨层级查看数据的情况。有以下五种场景：
场景1：账号可看到本层级及下级数据。
在创建账号时，要选择这个账号属于哪个层级，则就能看到当前层级及以下层级的所有数据。如账号1可看到北京分公司及其下属节点的所有数据。这种是比较常用的数据权限，同时账号不能看到上级组织结构节点的数据，如账号2属于朝阳区这个节点，则不能看到属于北京分公司的数据。
场景2：账号只能看到本层级的数据。
数据权限更深层的需要细化出来这个账号能看到具体哪个级别的数据，如账号3是属于朝阳区，但他有可能只能看到属于朝阳区这一层的数据，下级节点的门店数据是看不到的。
场景3：账号只能看到下级某一节点的数据。
如售后人员的账号2，虽然是属于北京分公司，但只能负责朝阳区下面门店1和门店2的数据。基于这种情况，需要在创建账号时，在关联组织架构，还要指定当前账号能看到这个节点下的哪些数据。
场景4，账号只能看到指定层级的指定数据。
每个组织架构的层级上会有一些属于当前级别某些账号特有的数据。如商务合作的客户数据，属于当前组织架构的节点，同样属于某个商务人员独有，不会共享给其他招商人员。如招商部的A员工的账号3，管理的客户信息是属于朝阳区的，同样也只属于账号3所属的A员工管理。其他同级别的账号4所属的员工，则没有权限看到这些客户信息。但招商部的部门经理是要看到本部门的所有数据。所以在创建账号时，还要指定这个账号是能看到本部门的数据还只能看到自己创建的数据。
场景5：存在管理不同级别其他节点数据。例如账号5原本属于组织架构里的门店1，理论上只能管理门店1的数据，但如果门店4这种不在同一个上级节点的门店，希望帮忙分析售后问题，那账号5如何跨节点管理门店4的售后问题。答案是门店4的管理者可以指定某些数据或节点的所有数据共享给门店1的账号5管理。数据共享不限制组织结构的上下级和同级关系。
二、角色解决功能权限(RBAC模型)
1. 基础角色权限模型(RBAC0)
为什么要靠角色来解决功能权限，而不是使用账号跟功能直接关联?是因为平台页面多，页面内的功能也非常多的情况下，如果靠账号直接跟页面和功能关联，所有账号都操作起来比较繁琐。引入角色，把角色和权限关联，这样有相同权限的人直接跟角色关联，进而获得角色所对应的功能权限。提高的操作的便利性。角色本身就是功能的合集。同一个账号，可以有多个角色，则可获得多个角色的并集的权限。如账号4关联员工和助理两个角色，则账号4可获得员工角色对应的页面3、页面4和助理角色对应的页面5的功能权限。
2. 角色搭建组织架构(RBAC1)
对于组织架构没有那么复杂的，则会有使用角色来实现组织架构的，角色设计成带有上下级的树形结构。这种实现方式灵活性会比较差，如果组织架构复杂，则角色量比较多，同样一个店长角色，需要在每个组织架构的节点上都进行单独创建。一般不会采用这种实现方式。
3. 角色互斥场景(RBAC2)
实际业务场景中，存在同一个账号不能同时获得两个角色，两个角色互斥，有这个角色就不能获得另外一个角色。财务中的会计和出纳两个角色，一个人是不能同时负责，做到财权分离。这种需要在创建角色定义中专门去定义互斥情况。
4. 角色同时有组织架构和角色互斥(RBAC3)
复合型的RBAC1+RBAC2的一种合成形式，角色上既有组织架构，又有角色互斥的实现形式。
三、账号关联角色或组织内的岗位
1)账号只绑定角色来同时获得功能权限和数据权限。
如上图所示，把角色当成岗位，可将角色直接与组织架构关联，账号只需与角色关联，不用单独关联组织架构，则账号直接获取当前角色下的功能权限和角色对应的组织架构下的数据权限。这样如果账号需要调整岗位时，直接调整账号对应的角色就可以，方便操作。但这种需要在每个节点上创建好岗位和对应节点的角色，角色的数据量会比较多，每个角色都要配置对应的功能权限。
2)账号只绑定组织架构内的岗位来同时获得功能权限和数据权限。
在组织架构上创建岗位，岗位和对应的角色关联，账号直接跟组织架构上的角色进行关联，同时获得角色权限，无需再关联角色。账号在调岗时直接更换组织架构中的岗位就可以。这种和上面的场景一样，都需要频繁重复创建一样的内容。
四、审批流程业务场景
上面介绍的账号与角色和组织架构关联来解决功能权限和数据权限的问题，但涉及到审批流程的，如在门店1内部，服务员请假，需要店长审批，但两个人都属于同一组织架构的门店1上，没有上下级关系，只能在流程上指定人去审批。但这样每个部门内部都需要自己创建审批流程，操作起来比较繁琐。因为角色的作用本身就是岗位职责，可以在审批流程中引入角色，审批节点都是角色。
例如请假，可在审批流程中设定门店的员工角色请假都要让门店的店长或管理者角色审批，这样所有的门店都遵照这个流程。
例如报销流程需要走门店店长和区级财务经理这两个审批。如果报销一定金额，需要走分公司的财务副总这个人审批，则需要在流程中支持指定人来审批的功能。但一般不建议指定人审批，后续人员调整，审批流程也要做相应调整。
另外如果当前审批角色上有多个账号，则多个账号都可以审批，除非流程上指定某个账号审批。如财务报销走到了朝阳区的财务角色，下面有账号3和账号4，则账号3和4都可以审批，本着谁审批，谁负责的原则。如果账号3审批了某个报销单，后续打款也应当走到账号3上来进行审批。
五、角色组和用户组使用场景
角色组是多个角色的合集，多个角色下的功能权限的合集，为了在1个账号绑定多个角色时方便操作，倒不如直接建个新的角色绑定账号。
用户组，就是多个账号的合集，为了在多个账号绑定同一个角色时方便操作，并没有解决解决具体权限问题。
总结：目前基于SaaS平台的现有业务和未来管理类的业务特点，一般会采用标题1、标题2和标题4三种结合的形式，来分别解决功能权限，数据权限，和审批流程的权限。
