所以后期我们可以在数据权限设置时增加对组织架构的设定的三种类型：
2. 初始化角色（预制角色）
用户权限设置完成后，我们还需要考虑新用户的预制角色，我们不能让用户从零开始一点点配置，因为这样不仅费时费力，大部分用户也配不明白，即便平台提供了培训手册或视频，但是又有多少用户会认真看呢？
所以不同的平台对于新入驻的用户，要预制一套相对常规的规则。当然不仅是预制角色，其他的业务功能也需要按需预制，毕竟降低用户的理解难度和操作难度，也是提高入驻率的关键方式。
后续我也会单独整理我们可以采用哪些方法降低B端用户的上手难度和准入门槛，欢迎持续关注~
3. 有些功能需要单独维护访问权限
有些场景不太好通过平台级的设计来解决，建议还是针对具体的场景进行特色化设计。
比如企业的合同管理功能，人事一部只能看到员工的劳务合同，人事二部只能看到员工的保密协议。这种按业务类型区分的数据分类，参照上文的设计模式就不好实现，所以只能在合同管理功能中单独增加以类型区分的数据筛选条件。
05 需要强调的两件事1. 尽量不要把特色化改动直接挂到“用户”上
即便遇到一些偶现的用户权限特殊处理，也尽量采用对角色的新增和配置形成权限集合后，再赋予用户，而不是在用户上直接进行修改。
2. 在最终测试验证环境，一定不要只使用【超级管理员】操作
因为超管一般不会出问题，我们需要使用新维护的角色，代入用户的实际使用场景，对平台的功能进行全流程冒烟测试，在这个过程中才能够发现更多的隐藏问题。
以上就是今天对用户权限的设计总结。
06 写在最后设计思路是一回事，具体的解决方案又是另一回事，希望今天的分享能够为你带来一些帮助。
权限设置在后续的工作中和实际场景连接后，会演变出非常多的可能性，所以需要我们结合自身团队的诉求，产品的目标和现状，和研发人员一起讨论出更合理的设计方案。
作者：不想延期，公众号：不想延期
本文由 @不想延期 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
