SaaS系统权限架构设计主要包括功能权限和数据权限，前者控制用户对某个菜单某个按钮是否可见、能否操作，后者控制用户能看到什么层级的数据。

一、功能权限

1. 是否可见

目标：控制某个菜单某个按钮是否对访问用户开放。

解决方案：RBAC模型，基于角色的访问控制。1个用户可以有多个角色，每个角色又赋予了多个系统权限点，最终实现用户与权限的关联关系。

2. 能否操作

目标：进一步控制访问用户是否能对可见按钮进行操作。

场景说明：一般情况下，可见按钮均是可以操作的，不会做特别的权限控制，但在某些场景下，比如销售在看客户详情时，可以通过链接查看工单详情，那他是否可以操作工单上的按钮？

解决方案：当权限需要在此类场景下细化时，可进一步对按钮权限进行控制，比如定义只有工单负责人及其上级主管可操作。

3. 注意事项

1）必须按实际的业务场景需求进行角色初始化，大部分用户都是很懒的

一款产品无到有，产品经理需要做些什么？

在一个产品从无到有的过程中，要做好产品经理这个角色实在是不容易，除了大家都知道的写需求、写需求、写需求，要做的事多着呢。产品经理不是你眼中的只会找你麻烦，提要求..

查看详情 >

2）预设角色不能编辑权限，否则后期迭代功能上新时，就无法自动为这些预设角色勾选新功能了

二、数据权限

1. 通用场景

目标：依托组织架构实现数据权限的控制。

解决方案：对组织架构内的员工定义数据权限，比如只能看自己的数据，只能看本部门数据，可以看本部门及下级部门数据。

2. 特殊场景

目标：脱离组织架构实现数据权限的控制。

场景1：希望跨组织架构看到其他部门的数据，比如质检部门需要看到销售部门的数据。

解决方案1：设置共享权限，单独共享某个部门或人维度的数据。

场景2：希望能将自己的某个客户共享给其他人。

解决方案2：从业务上进行场景定义，比如设置协作人字段等。

场景3：设置节点流程的审批人。

解决方案3：在流程配置页面设置审批人，比如指定角色？指定人？直接主管？