企业官网建设流程全解析

ToolJet 工作流权限详解：Admins、App 编辑组与终端用户的三级访问控制

【免费下载链接】ToolJetOpen-source foundation of ToolJet AI - the enterprise app generation platform for internal tools, dashboards, business applications, workflows and AI agents. Build visually, from a prompt, or from Claude Code, Codex and Cursor over MCP 🚀项目地址: https://gitcode.com/GitHub_Trending/to/ToolJet

工作流（Workflows）是 ToolJet 中用于编排自动化逻辑的核心能力，而权限体系决定了谁能查看、编辑和执行这些工作流。本文以 docs/docs/workflows/permissions.md 为主体，结合 ToolJet 开源仓库的服务端权限实现，完整梳理工作流权限的三种用户角色（Admins、Groups with App Editing Permissions、End Users）各自的能力边界，并深入到 CASL 能力模型与默认用户组常量，帮助你精确配置内部工具、仪表盘和业务应用中的工作流访问控制。

工作流权限总览

在 ToolJet Workflows 中，权限管理遵循"结构化、可精确到单个动作"的设计思路：谁可以查看、编辑或执行工作流，都通过统一的权限模型来约束。下面这张表给出了工作流权限的完整摘要，它同时也是本文后续三个章节的索引：

从表中可以清晰看到权限的"三层递进"结构：

• Admins拥有全量权限，是唯一能够进入工作流仪表盘、创建/编辑工作流，以及启用或禁用工作流执行的群体；
• 具有 App 编辑权限的组属于"构建者"定位，能复用已有工作流来搭建应用，但不能修改工作流本身；
• 终端用户仅能在应用内触发工作流执行，属于纯消费方。

Admins：工作流的全权管理者

Admins可以创建、编辑和管理工作流，能够访问工作流仪表盘（Workflow Dashboard）与流程构建器（Flow Builder），并且可以在 ToolJet 的App Builder中使用这些工作流。此外，他们还可以使用工作流编辑页面右上角的Enable开关，在 ToolJet 应用中启用或禁用工作流的执行——这是控制工作流是否对外生效的"总闸门"。

这一能力在服务端源码中有着直接的对应实现。在 server/src/modules/group-permissions/constants/index.ts 中，DEFAULT_GROUP_PERMISSIONS为默认的ADMIN用户组预置了workflowCreate: true与workflowDelete: true，同时isBuilderLevel: true表明该组处于构建者级别；而在DEFAULT_RESOURCE_PERMISSIONS中，USER_ROLE.ADMIN对ResourceType.WORKFLOWS资源持有canEdit: true，意味着管理员对所有工作流资源都具备编辑能力。

更底层的判定逻辑位于 server/src/modules/apps/ability/workflow.ability.ts 的defineWorkflowAbility函数中。当isAdmin || superAdmin为真时，CASL 能力构建器会一次性授予工作流相关的全部FEATURE_KEY，包括CREATE、UPDATE、DELETE、GET_ONE、GET_BY_SLUG、RELEASE、VALIDATE_PRIVATE_APP_ACCESS、VALIDATE_RELEASED_APP_ACCESS与UPDATE_ICON：

if (isAdmin || superAdmin) { // Admin or super admin can do all operations can( [ FEATURE_KEY.CREATE, FEATURE_KEY.UPDATE, FEATURE_KEY.DELETE, FEATURE_KEY.GET_ONE, FEATURE_KEY.GET_BY_SLUG, FEATURE_KEY.RELEASE, FEATURE_KEY.VALIDATE_PRIVATE_APP_ACCESS, FEATURE_KEY.VALIDATE_RELEASED_APP_ACCESS, FEATURE_KEY.UPDATE_ICON, ], App ); return; }

从源码结构看，ToolJet 中的工作流在数据模型上对应type === 'workflow'的 AppVersion（见 server/src/modules/workflows/guards/workflow-access.guard.ts），因此管理员对工作流执行UPDATE、RELEASE（发布）等操作，实际走的也是统一的 CASL 授权通道。此外，数据迁移 server/data-migrations/1754999194042-UpdateWorkflowPermissionsForAdminAndBuilder.ts 与 server/data-migrations/1758009004418-AddWorkflowGranularPermissionsToExistingAdminGroups.ts 进一步印证：工作流权限会随版本演进被回填到既有管理组，保证历史工作区与新增权限模型保持一致。

Groups with App Editing Permissions：复用工作流，但不能修改

具有 App 编辑权限的组（Groups with App Editing Permissions）可以在 ToolJet 的App Builder中使用已有的工作流，将其接入应用交互，但无法像 Admins 一样创建或修改工作流本身。

典型场景示例

假设一家公司使用 ToolJet 构建内部应用，HR 部门希望集成一条"员工请假申请获批后自动发送邮件"的新工作流。作为具有 App 编辑权限的组的成员，可以完成以下操作：

• 在 App Builder 界面中添加一个名为Approve Leave（批准请假）的按钮；
• 将该按钮链接到一条已有的、用于发送自动邮件的现有工作流；
• 使用另一条提供相关数据的工作流，设计一张展示"每月获准请假数量"的图表。

也就是说，这类用户能够"驾驭"现有工作流并将其整合进应用功能，但无法像 Admins 那样亲自创建或修改工作流。

源码视角的印证

在 server/src/modules/group-permissions/constants/index.ts 的DEFAULT_RESOURCE_PERMISSIONS中，USER_ROLE.BUILDER对ResourceType.WORKFLOWS同样持有canEdit: true，且DEFAULT_GROUP_PERMISSIONS.BUILDER同样开启了workflowCreate与workflowDelete——这说明"具有 App 编辑权限的组"通常与默认 Builder 组同属构建者级别。

而对于被显式限制为"仅可编辑应用、不可编辑工作流"的自定义组，workflow.ability.ts中的逻辑会精确收敛其能力：当userWorkflowPermissions.editableWorkflowsId列表不含当前workflowId时，UPDATE、GET_ONE、RELEASE等编辑类能力均不会被授予；只有FEATURE_KEY.CREATE在isAllWorkflowsCreatable（对应userPermission?.workflowCreate）为真时才放开。这意味着从能力模型层面，工作流的"可编辑"与"可执行"是两套独立判定的维度，可以被细粒度拆开配置。

End Users：仅执行，不接触构建

终端用户（End Users）只能在工作流所在的应用程序中执行工作流，无法访问工作流仪表盘，也无法在 App Builder 中使用或修改工作流。

典型场景示例

沿用上面的公司场景：一名来自销售部门的员工（终端用户）登录 ToolJet 构建的内部应用申请年假，其完整交互链路如下：

• 员工填写Leave Request（请假申请）表单；
• 提交后点击Request Leave（申请请假）按钮——该按钮链接到一条"将申请发送至 HR 部门"的工作流；
• 当 HR 使用Approve Leave按钮（由"具有 App 编辑权限的组"创建）批准请假后，员工会收到一封自动邮件通知，该通知由另一条工作流触发。

在这条链路中，终端用户全程只扮演"触发者"角色：他们发起的是工作流的执行，而非工作流的构建或管理。

源码视角的印证

DEFAULT_GROUP_PERMISSIONS.END_USER中workflowCreate: false、workflowDelete: false，且isBuilderLevel: false；DEFAULT_RESOURCE_PERMISSIONS[USER_ROLE.END_USER][ResourceType.WORKFLOWS]为canEdit: false, canView: true。这与权限表中的"❌ 创建/编辑、✅ 执行"完全吻合。

在defineWorkflowAbility中，终端用户对应的分支是"执行级"授权：

if ( isAllWorkflowsExecutable || (userWorkflowPermissions?.executableWorkflowsId?.length && workflowId && userWorkflowPermissions.executableWorkflowsId.includes(workflowId)) ) { // add view permissions for all workflows or specific workflow can([FEATURE_KEY.GET_ONE, FEATURE_KEY.GET_BY_SLUG, FEATURE_KEY.VALIDATE_RELEASED_APP_ACCESS], App); }

可以看到，当用户仅持有执行权限时，只会被授予GET_ONE、GET_BY_SLUG与VALIDATE_RELEASED_APP_ACCESS这类"读取 + 校验已发布应用访问权"的能力——这正是"能触发执行、但拿不到任何编辑能力"的底层保证。而真正拦截越权请求的，是 server/src/modules/workflows/guards/workflow-access.guard.ts 中的WorkflowAccessGuard：它会校验appVersionId的 UUID 格式、当前用户是否已认证，并确认该版本确实对应一个type === 'workflow'的应用版本，随后将解析出的工作流挂载到请求上下文供后续控制器与能力判定使用。

从"用户组"到"执行权限"的落地链路

综合以上源码，可以梳理出 ToolJet 工作流权限从配置到生效的完整链路：

1. 定义层：默认用户组（Admin / Builder / End User）的权限模板集中在 server/src/modules/group-permissions/constants/index.ts，通过workflowCreate、workflowDelete与ResourceType.WORKFLOWS上的canEdit/canView决定组的初始能力；
2. 判定层：server/src/modules/apps/ability/workflow.ability.ts 的defineWorkflowAbility基于 CASL 构建当前用户的能力集，区分"全部可编辑/可执行"与"按 workflow ID 白名单可编辑/可执行"两种模式，管理员直接走全量授权分支；
3. 执行层：工作流相关请求经 server/src/modules/workflows/guards/workflow-access.guard.ts 验证资源类型与身份，再由控制器（server/src/modules/workflows/controllers/workflows.controller.ts、workflow-executions.controller.ts 等）依据能力模型放行或拒绝；
4. 管理面：Admins 通过编辑器右上角的Enable开关控制工作流在应用中的执行开关，这一"启用/禁用"能力仅授予管理员层级，与权限表中的最后一列一一对应。

实战建议

• 按"最小权限"分配：默认情况下只把 Builder 或同等构建者角色授予需要编排工作流的成员；仅需在应用内复用工作流的成员应归入"具有 App 编辑权限的组"，而最终使用者一律以 End User 身份登录；
• 善用 Enable 开关：在灰度或故障期间，Admins 可以暂时禁用某条工作流的执行，而不影响其在 App Builder 中的引用与后续再次启用；
• 理解"可执行"与"可编辑"的独立性：从workflow.ability.ts可以看到，执行权限（executableWorkflowsId）与编辑权限（editableWorkflowsId）是独立的判定维度，若你的工作区启用了细粒度工作流权限，可以按工作流 ID 精确放行执行权而不授予任何编辑权；
• 版本升级注意回填迁移：仓库中的相关数据迁移（如 1754999194042-UpdateWorkflowPermissionsForAdminAndBuilder.ts）会自动为既有管理组补齐新增的工作流权限，升级后建议抽查一次默认组的权限模板，确保与预期一致。

【免费下载链接】ToolJetOpen-source foundation of ToolJet AI - the enterprise app generation platform for internal tools, dashboards, business applications, workflows and AI agents. Build visually, from a prompt, or from Claude Code, Codex and Cursor over MCP 🚀项目地址: https://gitcode.com/GitHub_Trending/to/ToolJet