工具类 APP 的权限系统，核心不是“给不同用户显示不同菜单”，而是同时控制用户能看什么、能做什么，以及能处理哪一范围的数据。预约、巡检、报修、上门服务、设备记录等场景通常包含任务分派、表单流转和后台管理，若只在客户端隐藏页面，后台接口仍可能被越权调用，权限设计就无法形成真正的安全边界。
先拆清权限的三个维度
较完整的权限模型，至少应区分以下内容：
- 功能权限：是否可以进入某个模块，例如表单、任务、消息或统计。
- 操作权限：进入模块后能否新增、编辑、提交、审批、退回、导出或删除。
- 数据权限：能够查看和处理哪些数据，例如本人任务、所属部门任务或指定区域数据。
这三类权限不能互相替代。员工可以拥有“任务查看”权限，但不代表能够查看全部区域的数据；主管可以审批表单，也不代表可以修改已经完成的记录。权限判断应由后台统一执行，客户端仅负责展示可用界面。
角色只是入口，数据范围才是难点
工具类 APP 常见角色包括客户、派单员、员工、主管、区域负责人和审核人。设计时不宜直接为每个用户逐项配置权限，而应先建立角色，再为角色绑定功能、操作和数据范围。这样既便于员工邀请和组织调整，也能减少维护成本。
尤其要把“组织关系”和“业务关系”分开处理。一个员工可能属于某个部门，但临时参与其他区域任务；一个主管可能拥有审批权限，却只能处理指定部门的表单。权限规则需要明确优先级、适用范围和生效条件，避免出现角色叠加后权限意外放大的问题。
审批流必须与权限联动
表单权限不能只按页面划分。草稿保存、提交、退回修改、重新提交和最终完成，往往对应不同角色和状态。系统应明确每个状态下谁可以操作、操作后状态如何变化，以及是否允许重复提交。自动分配负责人、现场照片、签名和数据导出，也应纳入权限矩阵，而不是上线后再补充。
后台管理同样需要权限控制。用户、角色、表单、任务、消息、统计和数据导出不应默认对所有管理员开放，并应保留操作记录，便于定位误操作和权限异常。
上线前用权限矩阵验收
报价和验收时，应将“某角色在某数据范围内能执行哪些动作”写成可验证描述，而不是只写“支持权限管理”。至少要逐项检查：越权访问是否被拦截，退回后谁能修改，区域负责人能否看到无关数据，员工离开角色后权限是否及时变化，以及后台和 APP 端是否执行同一套规则。权限系统越早固化，后续扩展多角色、多区域和复杂审批时，返工成本越低。
