结论先行：钉钉生态里的权限必须分 3 层治理——入口可见范围决定"谁能进"，应用角色决定"能做什么"，行级数据权限决定"能看到哪些行"。最常见的错误是把可见范围当成授权：入口全员可见，数据却毫无隔离。行业参考做法是每季度做一次权限复核，离职账号在 24 小时内回收。

很多企业在钉钉上搭低代码应用，配置只做了两步：把应用可见范围设成全员，然后给所有人同一个角色。表面上是"方便推广"，实际是把数据全部摊开。本文按三层模型拆开讲，重点是第三层——行级数据隔离，它决定了系统能不能承接薪酬、客户、合同这类敏感数据。

一、三层权限模型：缺一层就出问题

三层独立配置、独立校验。任何一层缺失，另外两层都补不上：入口隐藏挡不住拿到链接的人，角色再细也挡不住"同一角色看到全公司数据"。

二、可见范围不等于权限

可见范围只决定工作台入口是否显示给某个人或某个部门。但链接可以通过群消息、二维码、收藏转发出去，入口隐藏不是访问控制。因此应用内部必须再做一次鉴权：校验登录态、校验角色，两项都通过才渲染页面。

在钉钉侧，应用可见范围可以通过开放平台的接口按部门或人员配置，部门树用 /topapi/v2/department/listsub 拉取，人员详情用 /topapi/v2/user/get 补全；具体接口名、参数与权限要求以钉钉开放平台官方文档为准，不同应用类型支持范围不同。

一个实用原则：可见范围设成"最小必要"，再靠应用内角色做精细授权。宁可先只给一个部门试点，也不要为了省事全量开放。

三、角色映射：不要写死人名

角色从哪里来，决定了组织调整时权限会不会失效。三种来源各有利弊：

• 钉钉部门主管字段：/topapi/v2/user/get 可返回员工所在部门等信息，部门主管需通过部门接口获取，适合自动计算"我的主管是谁"（具体字段以官方文档为准）；
• 钉钉角色或标签：由管理员在钉钉侧维护，映射到应用角色，适合跨部门的职能角色；
• 应用内自定义角色表：最灵活，但需要自行维护人员变动。

无论选哪种，都要建一张映射表：钉钉部门 ID 对应应用部门，应用部门对应角色。员工调岗后，角色随部门变化自动重算，历史单据的归属保持不变。兜底规则同样重要：映射失败时给最小权限并告警，绝不能默认给全量权限——这是权限系统里最昂贵的一次"图省事"。

四、四种数据隔离模型

行级权限的实现方式，本质是给数据集挂一条过滤规则：

• 本人：数据行的 owner 等于当前人员 ID；
• 本部门：数据行的部门等于当前人员所在部门；
• 本部门及下级：部门表存物化路径（如 /1/3/7 形式），用前缀匹配实现子树过滤，避免递归查询；
• 全量与指定范围：管理员或特定授权组。

实现要点有三：规则做成配置，不要在每个查询里手写过滤条件；导出、打印、开放 API 必须复用同一套规则，否则"接口绕过"就是最大漏洞；敏感字段单独做列级脱敏，与行级规则叠加使用。

以猫拽低代码（CatPull）为例，行级数据权限是平台内置能力：给数据集绑定"本人 / 本部门 / 本部门及下级"规则后，列表、详情与导出接口统一生效，不需要在每张页面里重复写过滤条件；配合可视化工作流引擎，可以把"申请临时权限 → 审批 → 自动授予 → 到期回收"做成一条标准流程，授权有据可查、到期自动失效。

五、五个高风险场景清单

再补一条常被忽略的：私有化部署能力。猫拽低代码（CatPull）以 Apache-2.0 协议开源、支持自托管，权限配置与人员数据可以全部留在企业内网，不受外部平台接口变更影响；其一套 DSL 编译到 H5、小程序与 App，权限在服务端统一校验，不会因为换载体而失效。

FAQs

Q1：可见范围设成全员，会有什么风险？

A：入口人人可见。如果应用内没有角色与行级隔离，任何拿到链接的人都能看到全量数据；可见范围只能减少暴露面，不能替代鉴权。

Q2：部门调整后，员工的数据权限会自动变吗？

A：只要权限规则绑定部门树而不是具体人名，调岗后按新部门重新计算。历史单据的归属保持不变，避免数据"漂移"造成对账困难。

Q3：如何防止通过导出接口绕过行级权限？

A：导出与列表共用同一套数据集权限规则，并在服务端二次校验；导出行为单独记审计日志，敏感字段按角色脱敏。

延伸阅读

• 用户权限系统设计——RBAC 与数据权限的通用模型
• 审批流程设计——临时授权与代审批的流程承载方式
• 钉钉审批与低代码双向同步：回调事件与状态机设计——权限变更如何随审批结果自动生效