企业 Gumloop 部署中，Connectors（Slack/Salesforce/Jira/Snowflake 等集成）通常是受管控资源——组织通过 App Policies、Composable Roles 限制哪些成员能用哪些 connector。普通成员在 Agent 中添加 connector 时常撞上权限墙。
v10.4.0 之前，撞墙后体验割裂：成员卡住或脱离产品发私信/工单；管理员被动响应散落请求，没统一队列、没记录、没 SLA。Gumloop 早有成熟的 access-request 机制（官方称 Action Requests），只是覆盖面在逐版本扩展。
┌──────────────────────────────────────────────────────────────────────┐ │ Gumloop Access-Request 自服务闭环的演进 │ ├──────────────────┬───────────────────────────────────────────────────┤ │ v9.5.0 Bonavista │ Slack Notifications for Access Requests │ │ (2026-05-15) │ 访问请求通过 Slack 通知审批者 │ ├──────────────────┼───────────────────────────────────────────────────┤ │ v9.10.0 Atlin │ Notification Center（通知中心） │ │ (2026-05-29) │ 把 access/role requests 引入 app 内，一键审批 │ │ │ "补齐企业级权限管理最后一环（申请→审批→通知）" │ ├──────────────────┼───────────────────────────────────────────────────┤ │ v9.11.0 Huntsville│ Access Notifications for Agents/Skills/Flowbooks │ │ (2026-06-02) │ 覆盖面扩展到 Agents/Skills/Flowbooks │ ├──────────────────┼───────────────────────────────────────────────────┤ │ v10.4.0 Nelson │ Request Access to Connectors ◀━━ 本功能 │ │ (2026-06-25) │ 覆盖面扩展到 Connectors —— 全域资源统一覆盖 │ └──────────────────┴───────────────────────────────────────────────────┘
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 成员在 │───▶│ 撞权限墙 │───▶│ 点 │───▶│ 申请送达 │───▶│ 管理员 │
│ Agent 中 │ │ （该 │ │ Request │ │ owner/ │ │ 审批 │
│ 添加 │ │ connector│ │ Access │ │ admin │ │ │
│ connector│ │ 无权限） │ │ │ │ (email + │ └────┬─────┘
└──────────┘ └──────────┘ └──────────┘ │ Slack) │ │
└──────────┘ ▼
┌──────────────────────────────────────┐
│ 两个审批通道（既有）： │
│ ① In-App Inbox：Approve/Open/Reject/ │
│ Dismiss │
│ ② Slack 一键：DM 含 Approve/Deny 按钮 │
└──────────────────────────────────────┘
│
▼
┌──────────────────┐
│ 权限授予/拒绝 │
│ 成员继续配置 Agent │
└──────────────────┘
| 资源类型 | 申请送达谁 | 覆盖版本 |
|---|---|---|
| Agents | Agent owner | v9.11.0 |
| Skills | Skill owner | v9.11.0 |
| Workflows | Workflow owner | 既有 |
| Files | File owner / 创建该文件的 Agent 的 owner | 既有 |
| Teams | Workspace admin | v9.10.0 |
| Organization roles | Organization admin | v9.10.0 |
| 🆕 Connectors | [推断] Connector 管控者（org admin / App Policies 管理者） | v10.4.0 |
Connectors 的独特性：与 Agents/Skills（有明确 owner）不同，Connectors 访问权通常由组织级 App Policies / Composable Roles 管控。因此审批者更可能是 organization admin 或 App Policies 管理者 [推断]。
① In-App Inbox：申请进来显示为通知（申请人、资源/角色、时间）。四个响应——Approve（立即批准）/ Open（看详情再定）/ Reject（不可撤销拒绝）/ Dismiss（忽略）。已处理进 Resolved tab 备查，可 Clear 清理。
② Slack 一键审批：审批者收 Slack DM 含 Approve/Deny 按钮，一键不必离开 Slack。前提：审批者 + 申请者都连了 Slack。[文档已验证] Slack 一键目前对 team/org 请求可用，其他类型 incremental rollout——Connectors 的 Slack 覆盖度取决于该 rollout。
每个申请有持久化记录：Pending（已发送待决）→ Accepted（批准，权限授予）/ Rejected（拒绝）/ Expired（过期窗口内未处理）。申请只能处理一次；被拒绝可稍后重提。
Connectors 访问管控源于 App Policies（v8.6.0，组织级 app/MCP server 工具 guardrail）和 Composable Roles（v8.7.0，角色级 connector/工具限制）。成员因这些规则无法用某 connector 时，v10.4.0 让他撞墙处直接申请——把"管控"和"自服务"连起来：管控方制定规则，成员有标准化路径申请例外，而非完全被阻断。
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| A1 | 成员尝试添加无权限 connector | 显示权限墙 + Request Access 按钮 | P0 |
| A2 | 成员点 Request Access | 创建 Connector 访问申请，进入 Action Requests 流程 | P0 |
| A3 | 申请内容 | 含申请人、目标 connector、所在 Agent 上下文、提交时间 | P0 |
| A4 | 重复申请同一 connector（已有 Pending） | [推断] 提示已有 pending 申请，避免重复 | P1 |
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| B1 | Connector 访问申请创建后 | 送达有审批权的角色（org admin / App Policies 管理者）[推断] | P0 |
| B2 | 送达通道 | 经 In-App Inbox 通知 + email | P0 |
| B3 | 审批者连了 Slack 且该类型在 Slack 一键覆盖范围 | 经 Slack DM 含 Approve/Deny | P1 |
| B4 | 申请人未连 Slack | 仅经 email（与既有行为一致） | P1 |
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| C1 | 审批者在 Inbox 点 Approve | 授予申请人对该 connector 访问权；申请转 Accepted | P0 |
| C2 | 审批者点 Reject | 拒绝；申请转 Rejected；可稍后重提 | P0 |
| C3 | 审批者点 Open | 查看详情（申请人、Agent 上下文、connector）后决定 | P1 |
| C4 | 审批者在 Slack 点 Approve/Deny | 与 Inbox 等效，权限变更同步 | P1 |
| C5 | 授权范围 | [推断] 授予"该成员对该 connector 使用权"，作用域个人级或按 Agent 级 | P2 |
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| D1 | 申请创建 | 持久化记录，状态 Pending | P0 |
| D2 | 过期窗口内未处理 | 转 Expired | P1 |
| D3 | 已处理的申请 | 进入 Resolved tab 备查 | P1 |
| D4 | 企业审计 | [推断] Connector 申请/审批纳入 Audit Logs | P1 |
用户画像：陈昊，26 岁，新入职销售运营。想给"客户跟进 Agent"接 Salesforce connector，但公司只允许特定角色用，他没权限。
作为新员工，我希望撞权限墙能一键申请，管理员批准后继续配置——而不是卡住、再去 Slack 找 IT 求权限、等半天。
验收标准：添加 Salesforce connector → 权限墙 + Request Access → 送达 admin（Inbox + email + Slack DM）→ Slack 一键 Approve → 陈昊收授权通知继续配置 → 全程有记录可审计。
用户画像：林芳，32 岁，市场运营。季度末要批量处理 Google Ads 数据，但她的角色平时不需要 Google Ads connector 权限。
作为运营，我希望临时申请 Google Ads connector 权限完成季度任务，做完权限可回收——而不是为一次性需求走漫长的永久提权流程。
验收标准：添加 Google Ads connector → 撞墙 → 申请 → admin 审批（可注明临时授权）→ 完成任务 → [推断] admin 后续可调整角色/权限回收（Composable Roles 既有能力）。
用户画像：赵刚，40 岁，IT 管理员。过去成员要 connector 权限都私信他，散落处理、没记录、没法统计。
作为 IT 管理员，我希望所有 connector 权限申请都进我的 Inbox/Slack，一键审批、有记录、能追溯——而不是被动响应各种私信。
验收标准：所有申请集中到赵刚 Inbox（Resolved tab 留痕）→ Slack DM 一键审批 → 审计记录可查 → 季度复盘可统计哪些 connector 申请最多、平均审批时长、谁有什么权限。
| 竞品 | 功能/行为 | 优势 | 劣势 | 洞察/机会 |
|---|---|---|---|---|
| Slack / 工作沟通工具 | 撞权限时无标准化流程，靠人沟通 | — | 全靠线下私信，无记录无 SLA | Gumloop 把"线下求助"产品化为标准流程 |
| Okta / 身份治理（IGA） | 完整 access request / 审批 / 认证流程 | 企业级成熟、与身份系统深度集成 | 重、独立系统、不嵌入业务工具上下文 | Gumloop 优势是"在 Agent 配置现场申请"，上下文齐全 |
| Salesforce / 企业 SaaS | 各自的权限申请流程 | 成熟 | 每个工具一套流程，碎片化 | Gumloop 用统一 Action Requests 覆盖所有资源类型 |
| Notion / Figma | 文档/设计资源的 access request | 轻量、体验好 | 仅覆盖自有资源，无 connector 概念 | Gumloop 覆盖面含 connector 这种集成层资源 |
| 漏斗阶段 | 事件名称 | 触发条件 | 指标/KPI | 优先级 |
|---|---|---|---|---|
| 采用 | connector_access_requested | 成员对无权限 connector 发起申请 | 申请发起数 / 撞墙次数 | P0 |
| 审批 | connector_access_approved | 管理员批准 | 审批转化率 | P0 |
| 速度 | connector_access_time_to_approve | 提交到批准时长 | 平均审批时长（SLA） | P0 |
| 通道 | connector_approval_channel | 审批经 Inbox / Slack / email | Slack 一键审批占比 | P1 |
| 替代 | offline_permission_request_decline | 历史线下权限请求被本流程替代 | 线下请求下降率 | P1 |
| 治理 | connector_access_audit | 申请/审批进入 Audit Logs | 审计完整性 | P1 |
| 阶段 | 时间线 | 里程碑 | 状态 |
|---|---|---|---|
| Phase 1 — Action Requests 基础 | v9.5.0–v9.10.0 | Slack 通知 + Notification Center 一键审批 | ✅ 已发布 |
| Phase 2 — 资源类型扩展 | v9.11.0–v10.4.0 | Agents/Skills/Flowbooks → Connectors，全域覆盖 | ✅ 已发布 |
| Phase 3 — Slack 一键全量 | v10.x | Slack 一键审批覆盖所有资源类型（含 Connectors、单个 Agent/Workflow） | ⬜ 进行中 |
| Phase 4 — 智能审批策略 | v11.x | AI 辅助审批：基于角色/历史/上下文自动建议，低风险请求自动批准 | ⬜ 探索中 |
| Phase 5 — 时限权限 | v11.x | 申请带时限（如 7 天临时权限），到期自动回收 | ⬜ 探索中 |
| Phase 6 — 权限洞察 | 远期 | 管理员仪表盘：谁有什么 connector 权限、使用频次、闲置权限回收建议 | ⬜ 探索中 |
spec_resource/gumloop-docs_share-permissions.md — Share Permissions 官方文档（Action Requests：申请—审批机制、Inbox、Slack 一键、可请求资源类型、生命周期）
v10.4.0 Nelson 版本详情 — 含本功能原始 changelog 描述
演进关联：v9.5.0 Bonavista（Slack 通知）· v9.10.0 Atlin（Notification Center）· v9.11.0 Huntsville（Agents/Skills/Flowbooks）· v10.4.0 Nelson（Connectors，本功能）
治理关联：App Policies（connector 管控源头）· Composable Roles（角色级 connector 限制）