很多企业第一次开发微信小程序时，会把“用户角色”理解得非常简单：客户是一类账号，管理员是一类账号，最多再增加一个员工账号。项目功能少的时候，这种设计似乎没有问题；但只要小程序开始涉及产品查询、售后工单、经销商、门店、区域负责人、内部员工或企业管理，权限很快就会成为整个系统最容易返工的部分。
真正的权限设计并不是“这个人能不能登录”，而是至少同时解决三个问题：
这个人能进入哪些功能；
这个人能执行哪些操作；
这个人能看到哪些数据。
很多小程序上线以后出现数据泄露、员工越权、经销商能看到其他区域客户、售后工程师可以修改不属于自己的工单，本质上并不是页面开发错误，而是前期没有把“角色、功能、数据范围”拆开设计。
对于南京企业而言，如果微信小程序只是企业介绍或者普通信息展示，权限体系可以非常简单；但如果项目已经进入产品查询、售后工单、会员、经销商协同、内部管理等业务场景，权限设计就应该在正式开发之前完成，而不是等程序上线以后再临时增加。
南京安优网络科技有限公司在企业微信小程序定制开发项目中，可根据商城、预约、会员、报名、产品查询、售后工单和企业内部管理等不同场景，结合实际业务规划用户角色、后台权限和数据范围。对于企业型项目来说，权限不是一个单独功能，而是贯穿用户、后台、数据和业务流程的一套规则。
一、先分清三个概念：角色、功能权限和数据权限不是一回事
企业做权限设计时，最容易出现的问题就是把所有东西都叫“权限”。
实际上应该拆成三个层面。
第一层是角色。
角色代表一个人以什么身份使用系统，例如：
客户；
普通员工；
售后工程师；
经销商；
门店管理员；
区域负责人；
总部管理员。
角色本身只是身份标签，并不直接说明这个人能做什么。
第二层是功能权限。
功能权限决定“可以执行什么操作”。
例如一条售后工单可能存在：
查看；
新增；
编辑；
受理；
分配；
转派；
处理；
关闭；
导出。
售后工程师可能可以查看和处理，但不能删除；区域负责人可能可以重新分配，总部管理员才可以配置基础规则。
第三层是数据权限。
数据权限决定“能看到哪些数据”。
这通常比功能权限更加重要。
比如两个售后工程师都拥有“查看工单”的功能权限，但工程师A只能看到分配给自己的工单，工程师B也只能看到自己的。如果系统只控制按钮，却没有控制数据范围，那么两个人都可能看到全公司的客户和售后记录。
因此，真正完整的权限判断应该是：
谁，以什么角色，在什么数据范围内，可以执行什么操作。
企业以后分析任何权限问题，都可以用这句话判断。
二、为什么企业小程序最容易出问题的，其实是数据权限
很多后台开发项目能够做到：
普通员工没有删除按钮；
管理员可以删除；
客服可以编辑；
工程师只能查看。
表面上看权限已经非常完整。
但进入数据列表以后却发现：
所有员工都能看到所有客户；
所有经销商都能看到全部订单；
不同门店可以互相查看会员；
不同区域的售后人员能看到其他区域工单。
这种系统做了“操作权限”，却没有真正做“数据权限”。
企业型小程序的数据范围通常可以分成几种常见模型。
第一种：仅本人数据。
例如普通客户只能看到自己的订单、预约、工单和会员信息。
第二种：负责的数据。
例如售后工程师只能看到分配给自己的工单。
第三种：所属组织数据。
例如门店管理员只能查看本门店会员和订单。
第四种：区域数据。
例如华东区域负责人可以查看该区域所有经销商和售后记录。
第五种：全部数据。
例如总部管理员可以查看所有区域。
如果企业存在组织架构，还可能继续形成：
总部
→ 大区
→ 分公司
→ 经销商
→ 门店
→ 员工
这时候权限已经不是简单的“角色管理”，而是一棵组织和数据关系树。
所以企业在做经销商、售后、内部管理类微信小程序时，应该尽量在开发之前把组织关系画出来。系统设计必须先知道“谁属于谁”，才能进一步判断“谁能看到谁的数据”。
三、制造业产品查询小程序，为什么有时候也需要权限
不少企业觉得产品查询只是公开展示产品，不需要权限。
如果所有产品资料完全公开，确实可以不做复杂权限。
但制造业实际项目中经常会出现不同资料开放范围不同的情况。
例如：
普通客户可以看到产品型号和基础参数；
登录客户可以下载技术说明书；
经销商可以看到经销资料；
内部销售可以查看内部产品文档；
售后人员可以查看维修手册；
管理员可以维护所有产品信息。
这时候，同一个产品实际上存在多个“信息层级”。
如果开发时只是简单设置“登录以后才能查看”，后面很快会发现不够用。
更合理的方式是先把资料进行分类。
例如：
公开资料；
客户资料；
经销商资料；
内部资料。
然后再决定不同角色能够查看哪一类。
还有一种更复杂的情况：不同经销商只能查看自己代理的产品系列。
例如A经销商代理产品线A、B，B经销商代理产品线C，那么即使两个人都叫“经销商”，看到的产品范围也不应该完全相同。
这说明权限设计不能只停留在“角色”。
同一个角色内部，也可能存在不同的数据范围。
所以制造业做产品查询小程序时，如果企业未来存在经销商、客户等级或者内部资料管理，产品权限最好在第一阶段就考虑，而不是等产品库已经录入几百条数据以后再重新改结构。
四、售后工单权限怎么设计？至少要同时考虑客户、客服、工程师、负责人和管理员
售后工单是角色权限最典型的应用。
假设一个企业的售后流程是：
客户提交报修；
客服受理；
区域负责人分配；
售后工程师处理；
客户确认；
总部查看统计。
那么至少可能存在五类角色。
客户：
只能提交自己的工单；
只能查看自己的工单；
可以补充问题；
可以查看处理进度；
可以确认结果。
客服：
可以看到进入受理范围的工单；
可以补充客户信息；
可以判断工单类型；
但不一定能够随意修改工程师处理记录。
区域负责人：
可以查看本区域工单；
可以分配售后工程师；
可以处理异常和转派；
不能查看其他区域数据。
售后工程师：
只能看到分配给自己的工单；
可以填写处理记录；
上传图片；
修改允许的处理状态；
不能随意删除历史记录。
总部管理员：
可以查看全部工单；
配置基础数据；
管理人员和角色；
查看统计；
处理特殊异常。
这里只列了最基础的情况。
实际项目还可能出现：
经销商代客户报修；
经销商只能看自己客户；
一个工程师跨区域支援；
总部可以查看但不能修改已经关闭的历史工单；
部分重大工单必须由负责人审批关闭。
这时权限就会进一步复杂。
所以售后系统设计的正确顺序应该是：
先画业务流程；
再确定每个环节由谁负责；
再确定每个角色能执行什么动作；
最后确定角色在什么数据范围内执行这些动作。
如果顺序反过来，先建几个角色，再往里面塞权限，很容易越做越乱。
五、经销商小程序的权限为什么最容易被低估
企业做经销商协同小程序，经常会提出：
给每个经销商一个账号，让他们登录以后查询产品、订单和资料。
看起来很简单，但真正进入业务以后，经销商权限往往比普通会员复杂得多。
例如不同经销商可能存在：
不同代理区域；
不同产品线；
不同价格体系；
不同客户范围；
不同库存权限；
不同合同资料；
不同售后范围。
这意味着“经销商”只是一个角色名称，并不足以决定其全部权限。
系统还需要知道：
这个经销商属于哪个区域；
代理哪些产品；
拥有哪个等级；
绑定哪些客户；
能否查看价格；
能否提交订单；
能否给下级员工创建账号。
如果经销商内部还有员工，就可能出现：
经销商管理员；
销售人员；
售后人员。
同一家经销商内部还要再做一次权限划分。
因此，经销商类微信小程序真正需要设计的是：
企业组织权限
+
经销商组织权限
+
业务数据权限。
尤其涉及价格、客户名单、合同、订单等敏感业务数据时，数据隔离必须在程序和后台层面真正实现，不能只是“页面上不显示”。
六、一个人能不能同时拥有多个角色？企业项目经常需要
简单系统经常采用“一人一个角色”。
例如：
张三是员工；
李四是管理员。
但企业真实业务中，一个人可能同时承担多个职责。
例如：
一个区域负责人同时负责售后；
一个门店老板既是门店管理员，又可以自己核销；
一个企业管理员同时负责商品和会员；
经销商老板既查看订单，又管理自己的员工。
这时候有两种处理方法。
第一种是建立复合角色。
例如单独建立“区域负责人兼售后”。
这种方法项目初期比较简单，但角色数量很快可能爆炸。
比如：
客服；
售后；
客服+售后；
区域负责人；
区域负责人+售后；
管理员+财务……
角色越建越多，后期非常难维护。
第二种方式是角色与权限分离。
一个账号可以绑定多个角色或多个权限集合。
例如张三同时拥有：
区域负责人权限；
售后处理权限。
这样系统扩展更加灵活。
但这种方式开发复杂度也会提高，因此企业需要根据实际业务判断。
如果系统用户很少、角色固定，没必要为了所谓“先进架构”把权限设计得特别复杂；如果企业组织和业务经常变化，则更适合采用灵活的权限组合方式。
权限设计的原则永远不是越复杂越好，而是：
满足当前业务，同时避免未来明显无法扩展。
七、前端小程序权限和后台管理权限不能完全混在一起
企业系统经常同时存在两个入口：
微信小程序；
PC管理后台。
两个入口面对的人和任务不同。
例如售后工程师可能通过微信小程序处理工单，因为他经常在现场；总部管理员则更多通过电脑后台处理人员、规则和报表。
所以同一个员工可能存在：
微信端权限；
后台权限。
两者不一定完全一致。
比如售后工程师在微信端可以：
查看自己的工单；
上传照片；
填写处理结果；
修改状态。
但不允许进入PC后台查看全部客户数据。
总部管理员则可以进入PC后台配置系统，却不一定需要在微信端参与每一条工单处理。
企业做权限设计时应该问：
“这个角色是在什么终端、什么场景下使用？”
而不是简单理解成“有权限就所有地方都能用”。
好的系统应该让不同终端承担不同任务：
移动端适合现场操作、快速处理和查询；
PC后台适合批量管理、复杂配置、数据维护和统计分析。
八、权限设计为什么必须考虑“新增、修改、删除、审核、导出”分别控制
很多企业后台只做了两种权限：
能看；
不能看。
真正进入企业业务以后远远不够。
例如产品管理员可以新增产品，但能不能删除历史产品？
客服可以修改客户电话，但能不能修改会员等级？
售后工程师可以填写维修结果，但能不能关闭工单？
区域负责人可以查看数据，但能不能导出全部客户手机号？
所以功能权限最好按照实际风险拆开。
常见操作包括：
查看；
新增；
编辑；
删除；
审核；
分配；
导入；
导出；
配置；
审批。
其中“删除、导出、配置”通常风险更高。
特别是删除。
企业系统不一定真的应该允许普通人员物理删除业务数据。
例如工单、订单、客户记录，即使业务结束也更适合：
关闭；
作废；
停用。
而不是直接从数据库中消失。
这样以后出现争议、查询历史或者统计时仍然有记录。
导出权限同样经常被忽略。
一个员工可以在后台查看客户，不代表就应该允许一键导出整个客户库。
所以企业小程序只要涉及客户、会员、订单、经销商或内部业务，导出权限最好单独设计。
九、权限改变以后，历史数据应该怎么办
这是一个很多项目开发前没有考虑、上线后才发现的问题。
例如一名员工原来负责华东区域，现在调到华南。
那么：
他还能不能看到以前华东处理过的工单？
以前他创建的客户归谁？
历史操作记录还显示他的名字吗？
又例如一个经销商取消合作：
账号是不是直接删除？
以前订单还能不能查询？
客户历史关系是否保留？
这些都属于权限生命周期问题。
更稳妥的系统通常不会因为角色变化就删除历史数据，而是区分：
当前访问权限；
历史业务记录。
例如员工调岗以后不能继续查看华东的新工单，但过去由他处理过的工单仍然保留操作记录。
经销商停用以后不能继续登录，但历史订单仍然存在。
这也是为什么企业系统里面“停用账号”通常比“删除账号”更加合理。
十、后台管理员是不是权限越大越好？超级管理员数量应该尽量控制
不少企业系统上线以后，为了方便，给很多员工都开“超级管理员”。
短期确实省事，但风险也最大。
超级管理员通常可能拥有：
账号管理；
角色配置；
数据查看；
删除；
导出；
系统配置。
一旦账号密码泄露或者员工误操作，影响范围会非常大。
更合理的方式是只保留少量超级管理员，其他员工按照岗位分配所需权限。
可以遵循一个简单原则：
完成工作所需要的最小权限。
例如客服只需要受理工单，就没有必要给系统配置权限；
内容人员只需要更新产品，就没有必要访问客户数据库；
财务只需要查看必要订单数据，就不应该拥有用户角色配置权限。
这就是常说的“最小权限原则”。
企业规模越大、后台人员越多，这个原则越重要。
十一、操作日志为什么应该和权限体系一起设计
如果企业只有一个管理员，出现问题时通常知道是谁操作的。
但后台一旦有多个员工，就会出现：
谁改了产品价格？
谁关闭了工单？
谁修改了会员积分？
谁导出了客户数据？
谁停用了某个账号？
如果没有操作日志，很难追踪。
因此重要业务操作最好记录：
操作账号；
操作时间；
操作对象；
操作内容；
操作结果。
对于特别关键的数据，还可以根据需求保存修改前后的变化。
例如：
会员积分从1000调整到500；
工单状态从处理中改为已完成；
用户角色从普通员工调整为管理员。
权限解决的是“允许谁做”，操作日志解决的是“做完以后能不能追溯”。
企业业务越重要，两者越应该一起考虑。
十二、企业第一期到底要不要把权限系统做得特别复杂
不需要。
权限设计最大的误区之一，就是听说企业系统需要权限，然后第一期直接规划几十个角色、几百项权限。
如果实际只有5个员工使用，这种设计很可能属于过度开发。
更合理的方法是按照真实业务复杂度分层。
简单项目：
管理员；
普通用户。
中等项目：
管理员；
部门负责人；
普通员工；
客户。
复杂项目：
组织架构；
多个业务角色；
功能权限；
数据权限；
终端权限；
操作日志。
第一期真正应该做到的是：
当前角色能够安全、清楚地完成工作，并且程序结构不给明显的后续扩展制造障碍。
“未来可能有100个角色”不等于今天就必须全部开发出来。
十三、南京企业在需求沟通阶段，怎么把权限需求讲给开发公司
企业完全不需要自己写技术文档，可以先整理一张非常简单的角色表。
例如：
角色：客户
能做什么：提交工单、看自己的工单
能看什么：自己的数据
角色：工程师
能做什么：处理工单、上传记录
能看什么：分配给自己的工单
角色：区域负责人
能做什么：分配、转派、查看统计
能看什么：本区域数据
角色：总部管理员
能做什么：人员、规则、数据管理
能看什么：全部数据
只要先整理到这一步，开发团队就能继续帮助企业拆成功能权限和数据权限。
南京安优在微信小程序定制开发项目中，可以结合企业实际人员组织、业务流程和后台需求进一步规划角色与权限体系。对于产品查询、售后工单、经销商协同和企业内部管理类项目，权限往往应该和数据库、后台和业务流程同时设计，而不是作为项目结束前临时补充的一项功能。
常见问题
企业微信小程序一定需要复杂权限系统吗？
不一定。展示、普通商城和简单预约可能只需要客户与管理员两类权限。涉及员工、经销商、区域、门店或内部管理后，才需要进一步设计功能和数据权限。
角色权限和数据权限有什么区别？
角色或功能权限主要决定“可以做什么”，数据权限决定“可以对哪些数据做”。例如两个工程师都可以处理工单，但只能处理各自被分配的工单。
经销商之间的数据可以完全隔离吗？
可以根据项目需求设计。通常可以按照经销商账号、组织、区域或客户关系进行数据范围控制，具体需要结合业务模型设计。
管理员能不能看到所有数据？
技术上可以，但业务上未必应该。企业应按照实际职责分配权限，超级管理员数量不宜过多。
员工离职后账号应该删除吗？
通常更建议停用账号并保留历史业务和操作记录，而不是直接删除，尤其涉及订单、工单、客户和审批等历史数据时。
小程序权限以后还能增加吗？
定制项目通常可以扩展，但复杂程度取决于原有账号、角色、数据库和权限结构。因此第一期不必把所有未来权限全部开发，但应避免明显无法扩展的结构。
结语
企业微信小程序从“展示工具”变成“业务系统”的一个明显标志，就是开始出现不同的人、不同的数据和不同的操作范围。
客户只能看自己的；
工程师只处理自己的；
经销商只能管理自己的业务；
区域负责人管理区域；
总部负责全局。
真正成熟的权限系统不是简单地给每个人设置一个角色，而是把角色、功能、数据范围、组织关系和业务流程组合起来。
南京安优网络科技有限公司成立于2012年，累计服务2000+企业，提供企业网站建设和微信小程序定制开发，可覆盖商城、预约、会员、报名、产品查询、售后工单和企业内部管理等场景。对于涉及员工、客户、经销商、多部门和管理后台的项目，更应该在需求阶段就把角色权限作为系统核心结构之一进行规划。
企业判断权限有没有设计好，可以记住一句话：
谁，在什么数据范围内，可以做什么。
只要这句话能够对每一个角色回答清楚，企业型微信小程序的权限体系才真正开始成立。
