service-itsm-slack-itservice-configure

在 Slack 中为员工设置自助服务（Employee Service / ITSM）

完成 “在 Slack 中为员工设置自助服务” 检查清单组——这是 Slack 上 Employee Service（ITSM）的员工端设置，让员工可以直接在 Slack 中创建和管理自己的工单。每项操作都会通过 headless-360 执行。

每次只执行一个步骤。 这些操作会实际更改状态——执行一项操作，确认成功后再继续。不要将设置调用批量放入同一个并行代码块中。

步骤 1 是阻塞关卡。 Slack↔Salesforce 连接请求需要由 Slack 管理员发起。每次运行时，都要显示步骤 1 的内容，并且停止，直到用户确认已发送请求——在此之前不得调用任何 API（甚至不能读取）。如果用户未确认，则 Slack 设置尚未完成。

表达清晰；将内部信息留在推理中。 切勿展示工具名称、原始错误代码、内部端点、开发者名称或记录 Id——请使用通俗表述（“Slack 的 Employee Service 现已启用”），并通过用户和站点的可读 Name 来指代它们。每条面向用户的摘要都必须以标记 (via service-itsm-slack-itservice-configure) 开头。

范围

• 自动化（API）：启用 EmployeeServiceSlackEnabled；为每位已确认的员工用户分配全部三个核心权限集——EmployeeSlackNotifications + ItsmPortalUelUserPermset + 一个启用了 API 的权限集；列出员工门户；设置 Preferred Digital Experience Site（SLACK_PREFERRED_SITE）。另需读取连接状态。
• 引导 + 委派：将 Agentforce 连接到 Slack（步骤 6）——确保 IT Service Employee Agent 已存在（委派给 service-itsm-agentic-setup-employee-agent-configure），读取并检查连接状态，然后引导用户完成仅限 UI 的写入操作。
• 引导，仅限 UI：连接请求（第 1 部分，步骤 1）+ 批准/激活（第 2 和第 3 部分，步骤 2，仅在 API 读取无法确认时）+ 字段映射；Agent 与 Slack 的连接 + 工作区安装（步骤 6）。
• 范围之外：Slack 通知偏好设置（开/关）。

**前提条件：**组织必须拥有 Employee Service（ITSM）许可/权限——只有满足此条件才能编辑 EmployeeServiceSlackEnabled（参见注意事项）。员工门户应已存在，或通过 experience-portal-create 创建。

---

工作流

步骤 1 — 请求 Slack↔Salesforce 连接（Slack 管理员端）— 阻塞关卡

将组织连接到 Slack 工作区需要从 Slack 管理员端发起——不涉及 Salesforce API。严格关卡：原样呈现第 1 部分（请求），然后停止，等待用户确认（“ok”/“done”）；此时不得调用 API。如果用户未确认，Slack 设置尚未完成。不要提前处理 Salesforce 端的批准——你将在步骤 2 中尝试自行确认。

Connecting the org to Slack starts with a Slack-admin-side request — there's no Salesforce API for
it, so I can't do it for you. Do Part 1 now; after that I'll check the Salesforce side myself.

── PART 1 — Request a Salesforce connection in Slack (Slack desktop app) ──
  1. Click your workspace name in the sidebar.
  2. Hover over Tools & settings, then click Manage Salesforce organisations.
  3. Click on Connect Salesforce org in the top-right corner.
  4. Enter your Salesforce org URL.
  5. Choose whether to use Email or SAML NameID for the Account mapping field. If you like,
     toggle Automatic account mapping off to manually map accounts.
  6. Click on Request connection, then click on OK. Your request will be sent to Salesforce for
     approval.

Full walkthrough (all three parts — request, Salesforce approval, Slack activation):
  https://slack.com/intl/en-in/help/articles/30754346665747-Connect-Salesforce-and-Slack

Once you've sent the "Request connection" (Part 1), reply "ok".

步骤 2 — 确认连接（优先尝试 API），然后为 Employee Service 开启 Slack

不要立刻让用户前往 Salesforce — 先尝试自行确认连接，只有在无法确认时才引导用户在 Salesforce 端批准并激活。然后启用 Employee Service 组织偏好设置。

2a. 尝试通过 API 读取连接（无头用户没有 Setup UI，因此应先读取，而不是贸然让他们前往那里）：

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/connect/slackbridge/connections"
)

返回 {team:{status, teamName, teamDomain, teamId}, currentUserMapping:{salesforceUserId, slackUserId}} （已验证为 200）。根据 team.status 分支处理：

• CONNECTED → 已批准并处于启用状态。使用 teamName 指出工作区；跳过第 2 和第 3 部分，直接转到 2c（启用偏好设置）。（currentUserMapping.salesforceUserId 为 null 表示此用户尚未映射到 Slack 用户 — 请说明这一点；这不会阻止连接。）
• team: null / 未连接 / 出错 → 你无法确认连接。 此端点仅适用于 CONNECTED 状态，无法查看待处理/已请求的连接，因此 null 不表示请求不存在。绝不要说请求“没有提交”或“未出现在 Salesforce 端”。只说明 API 尚未显示已激活的连接，然后进行 2b。

2b. 仅当无法确认时（team:null / 待处理），粘贴第 2 和第 3 部分，然后停止。 第 2 部分是 Salesforce 端的批准操作和映射字段（默认为 Email；询问组织是否使用 SAML）— 这确实只能通过 UI 完成，因此应引导用户操作，不要伪造批准 API。指引用户前往待处理视图 Setup → Manage Slack Connection（/lightning/setup/SlackWorkspaces/home）。等待用户回复“ok”（已批准并激活）后再进行 2c。

── PART 2 — Approve the connection on the Salesforce side (guided) ──
  1. Go to Setup → Manage Slack Connection (/lightning/setup/SlackWorkspaces/home).
  2. Find the pending request and Approve it.
  3. Set the Account mapping field to Email (default) — or SAML NameID if your org uses SAML.

── PART 3 — Activate the connection back in Slack (Slack desktop app) ──
  Do this after the connection is approved on the Salesforce side. Owners / Salesforce-admin system
  role in Slack can activate:
  1. Click your workspace name in the sidebar.
  2. Hover over Tools & settings, then click Manage Salesforce organisations.
  3. Select the pending connection.
  4. Review the connection details, then click Activate.

Reply "ok" once the connection is approved and activated, and I'll continue with the Salesforce setup.

可以读取，不能批准 — 不要伪造。 读取状态是真实可行的；批准连接和设置映射字段确实只能通过 UI 完成。不要捏造 /connect/slack… 批准调用，也不要声称连接已获批准。 详情 / API 证据：references/manage-slack-connection.md。

2c. 为 Employee Service 开启 Slack。 这是直接的组织偏好设置开关（可通过 PATCH 访问）。通过 API 自行启用；不要让用户切换 Setup 开关。先读取（操作具有幂等性 — 如果已启用，则跳过写入）：

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/setup/org/preferences/EmployeeServiceSlackEnabled"
)

预期返回 200 {"isPreferenceEnabled": <bool>}。如果为 false，则启用：

mcp__headless-360__dispatch(
  method: "PATCH",
  url:    "/services/data/v67.0/setup/org/preferences/EmployeeServiceSlackEnabled",
  body:   { "desiredState": true }
)

预期返回 200 {"isPreferenceEnabled": true}。重新运行 GET 以确认。告知用户已启用 — 不要让他们自行切换开关。

已验证： REST 偏好设置名称为 EmployeeServiceSlackEnabled（不是 Metadata API 名称 enableEmployeeServiceSlack；猜测的变体会返回 404）。写入权限门槛请参阅 Gotchas。

步骤 3 — 启用 / 列出员工门户

Slack for Employee Service 通过 Digital Experience 门户提供自助服务。列出组织中的站点，并确认存在员工门户（此列表将在步骤 5 中用于选择首选站点）：

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/connect/communities"
)

每个条目都包含 id（Network ID，0DB...）、name、status、templateName、siteUrl。展示列表并识别员工门户（templateName 为 "Employee Portal" / "Agentforce Employee Center"）。如果不存在门户 — 或 Digital Experiences 尚未启用（调用出错 / 无返回结果）— 则转交给 experience-portal-create（其中也涵盖组织级启用），然后返回。

步骤 4 — 管理用户访问权限（为员工分配权限集）

Go 页面中的 “Manage User Access” 步骤会为每位已确认的员工用户分配权限集（绝不能为所有活跃用户分配——先询问要为哪些用户分配，再进行分配）。始终为每位已确认的用户分配全部三个核心权限集——不要询问用户要选择“仅通知”还是“完整”范围；只有三者配合使用，Slack for Employee Service 才真正可用（通知 + 记录可见性 + API 访问权限），少分配权限会导致记录访问无声地失效：

• EmployeeSlackNotifications — 工单更新的 Slack 通知（此步骤的核心）。
• ItsmPortalUelUserPermset（“ITSM Portal Uel User”）— Incident、Service Request、Case 的读取／创建／编辑权限（自助服务）— 让员工查看和处理自己的记录。
• API Enabled — 让 Slack 应用能够调用 Connect API。复用组织中已有的任何 API Enabled 权限集；否则创建一个以 Slack 命名的权限集（PermissionSet，PermissionsApiEnabled = true，例如 Name Slack_ApiAccess / label "Slack API Access"）。参见 references/manage-user-access.md。

Agent 访问权限是单独且有条件的——仅当用户选择在 Slack 中使用 Agentforce Agent（步骤 6）时才分配：该 Agent 的专属 Agent_Access 权限集（该 Agent 的 BotDefinition SetupEntityAccess）；反向查找，不存在时创建。绝不要分配 Access_Agents（员工许可证不支持）。操作说明：references/connect-agentforce-to-slack.md。

分配前提醒用户——用户的邮箱必须与其 Slack 用户的邮箱一致。 权限集仅授予接收通知的能力；Salesforce↔Slack 关联由连接的账户映射字段（默认值为 Email）决定：User.Email 必须与 Slack 账户邮箱一致，否则用户不会映射到任何 Slack 用户，通知也无处可达。步骤 2 中 currentUserMapping.salesforceUserId 为 null 表示未映射。（SAML NameID 也遵循相同规则，即该标识符必须一致。）请在分配权限前说明这一点，以便用户选择邮箱匹配的用户。

流程：查询活跃用户（每页 ≤10 个），使用辅助脚本分类（不要凭直觉判断——前几页往往充斥着系统／集成账户），询问要为哪些用户授予权限，重新查询每个权限集的 Id，为每位用户和每个权限集分别 POST 一个 PermissionSetAssignment，再使用脚本对每个响应进行分类。

→ references/manage-user-access.md — 查询和 POST 请求体、classify-user-access.mjs 的约定、邮箱匹配与许可证注意事项，以及 ItsmPortalUelUserPermset / API Enabled / Agent 访问权限的授予方式。

步骤 5 — 选择要与 Slack 连接的首选 Digital Experience 站点

写入组织值 SLACK_PREFERRED_SITE（跨功能共享——参见注意事项）。

1. 使用步骤 3 中的站点列表。询问要将 Slack 连接到哪个站点；如果用户未作选择，请自行选定一个（只有一个站点时选该站点，否则选择员工门户／最近上线的 Live 站点），并告知用户。
2. 先读取 GET /services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE（stringValue = 当前 Network Id 或 "None"）；如果已经是所选站点的 Id，则跳过写入。
3. 使用 dispatch 将 { "orgValue": "<site Network Id>" } 作为请求体 PATCH 到同一路径；此处填写站点的 Network Id（从 connect/communities 获取的 0DB...，而非 urlPathPrefix）；重新读取以确认。

步骤 5b — 验证站点已启用、已发布，且用户是成员（阻塞 — 必须在报告成功前完成）

SLACK_PREFERRED_SITE 和步骤 4 的权限集写入即使在站点无法为员工提供服务时，也会返回 200/201 — 此时报告“成功”就是错误的：IT Service 列表会返回空结果／拒绝访问。启用、成员身份和发布是三个不同的状态 — 必须逐一验证；任一项失败都属于阻塞问题 — 不要报告设置已完成。 对任何缺失项，都应通过程序处理（移交给负责启用／添加成员／发布流程的 experience-portal-create），以 UI 作为备用方案 — 不能只用 UI：

1. 运行中（启用） — SELECT Status FROM Network WHERE Id = '<site Id>'；如果 != 'Live'，则移交处理。
2. 成员（步骤 4 中的用户）— SELECT Id FROM NetworkMember WHERE NetworkId = '<site Id>' AND MemberId = '<user Id>'；返回 0 行 → 移交处理（将配置文件／权限集添加到 Members）。
3. 已发布 — Network.Status = 'Live' 并不能证明页面已发布（从未发布过的站点会返回 404）；如果站点仅已启用，则移交发布。

→ references/site-membership-verification.md — 其中包含准确的查询、补救方法，以及静默成功的故障模式。

步骤 6 — 为 Slack 配置 Agentforce（可选；先询问用户 — 这是最后一步）

首先让用户确认他们的记录已显示在 Slack 中 — 在配置 Agentforce 前暂停。 在此处发现可见性问题，而不是之后误以为是 Agent 导致的：

Before we (optionally) add the Agentforce agent, verify records show in Slack:
  1. In Slack → Agents & tools → Apps → search "Salesforce" → Open app.
  2. Confirm your self-service records show — Incident, Service Request, Case lists.

Reply "ok" once you see them. If a list says "Nothing turned up", the self-service permset
(ItsmPortalUelUserPermset) or email mapping isn't right — tell me and we'll fix it first.

只有在用户确认记录可见后，才询问他们是否也希望 Agentforce Agent 在 Slack 中回复；如果不需要，则到此为止 — 不配置 Agentforce，设置也已完成。如果需要，Go 页面上的 Configure Agentforce for Slack 组中有两项配置，可让 Agent 在 Slack 中实际回复：

• "Build and Manage Agent" — 构建 Agent；可自动化（委派处理）。
• "Connect Agentforce to Slack" — 连接 + 工作区安装；仅限 UI（引导用户操作）。

先确保 Agent 已存在 — IT Service Employee Agent。检查组织（见下方查询）；如果不存在，移交给 service-itsm-agentic-setup-employee-agent-configure（配置模板、创建并启用），然后返回。（受理人员：service-itsm-agentic-setup-fulfiller-agent-configure。）

mcp__headless-360__dispatch_readonly(
  method: "GET", url: "/services/data/v67.0/query",
  queryParams: { "q": "SELECT Id, DeveloperName, MasterLabel FROM BotDefinition WHERE DeveloperName = 'IT_Service_Employee_Agent'" }
)

连接的写入操作仅限 UI — 先读取并检查状态，再引导用户操作，不要伪造结果。 没有公开 API 能添加 Slack 连接或将 Agent 安装到工作区。将用户引导至 Setup 前，先读取并检查状态：通过步骤 2 的 /connect/slackbridge/connections 检查工作区连接（CONNECTED ⇒ 已生效）。Agent 与 Slack 的连接没有读取接口 — 请在 Builder 的 Connections 节点中目视检查。然后引导用户完成缺少的操作。

如果 Connections 旁边的“+”无法点击，说明版本已 Committed（锁定） — 只能在 Draft 版本中添加连接。先点击 New Version；“+”即可启用（这是版本锁定，不是 Active/Inactive 状态 — 停用不会解锁）。完成 + → Add connection → Slack → Add to agent 后，依次点击 Save → Commit Version → Activate。

→ references/connect-agentforce-to-slack.md — 其中包含逐字照做的点击路径（两端）、安装后的管理操作、前置条件，以及不存在 API 的证据。请向用户展示这些内容。

注意事项

问题	详情
REST 偏好设置名称是 EmployeeServiceSlackEnabled，而不是 Metadata 名称	/setup/org/preferences/{name} 使用 EmployeeServiceSlackEnabled（Metadata 字段 enableEmployeeServiceSlack 与之不同）。写入权限受限（userCanManageEmployees）——在非 ITSM 组织中，PATCH 可能会被拒绝；应显示错误，不要重试。
SLACK_PREFERRED_SITE 组织值	orgValue = 站点的 Network Id（0DB...），而不是 urlPathPrefix。写入后读回确认。
slackbridge/connections 仅显示 CONNECTED 状态——team: null ≠ 不存在连接	GET /connect/slackbridge/connections 仅在激活后才会填充 team；待处理的连接会显示为 {team: null}，但连接确实存在，并会显示在 Setup → Manage Slack Connection 中（仅限 Aura，没有 REST 对应接口）。切勿将 null 报告为“请求未生效”；应说明“API 尚未显示已激活的连接”，并交叉核对 Setup。没有批准/激活端点。详情：references/manage-slack-connection.md。
必须包含版本前缀	headless-360 dispatch/dispatch_readonly 不会解析 API 版本——请传入完整的 /services/data/vXX.0/... 前缀。
步骤 4 权限集——EmployeeSlackNotifications，而不是 SlackServiceUser；可能受许可证限制	分配员工侧的 EmployeeSlackNotifications（+ ItsmPortalUelUserPermset，用于自助服务记录可见性——Incident/Service Request/Case，不包括 Problem/Change）；SlackServiceUser 是履行者侧的权限集，不满足此步骤要求。某些许可证无法分配 PSL（400 FIELD_INTEGRITY_EXCEPTION）——应直接判定为“许可证不匹配”，不要重试。详情：references/manage-user-access.md。
步骤 4 API-Enabled 权限集——复用或创建	Slack 应用调用 Connect API 需要用户拥有带 API Enabled 权限的权限集。复用组织中任何现有的 API-Enabled 权限集；如果没有，则创建一个名称包含 Slack 的最小 PermissionSet（PermissionsApiEnabled = true，例如 Slack_ApiAccess）。详情：references/manage-user-access.md。
写入成功但 Slack 未显示记录 → 站点未激活/未发布，或用户不是成员	即使站点处于 UnderConstruction 状态、页面未发布，或用户没有对应的 NetworkMember 行，SLACK_PREFERRED_SITE 和权限集写入仍会返回 200/201——因此“成功”具有误导性。步骤 5b 会在报告任何成功前验证三种不同状态（激活状态 Network.Status = 'Live'；每位步骤 4 用户都有对应的 NetworkMember；页面发布状态——Live 并不能证明页面已发布）。补救措施应以程序化方式处理——交由 experience-portal-create（负责激活/添加成员/发布）；UI 作为备选方案，不要只使用 UI。详情：references/site-membership-verification.md。

---

验证清单

在输出任何面向用户的摘要之前，请确认以下各项：

• 第 1 步的内容块已显示，且用户明确确认已在任何 API 调用之前发送第 1 部分； 否则，未运行任何步骤，并已告知用户设置尚未完成。
• 第 2 步首先读取了 /connect/slackbridge/connections；若状态为 CONNECTED，则跳过第 2 和第 3 部分；若 team: null，则表述为“API 尚未显示任何已激活的连接”（+ Setup → Manage Slack Connection）， 绝不可说“请求未生效”；仅在未确认时粘贴第 2 部分（批准，不得伪造批准 API）和第 3 部分。
• 输出以 (via service-itsm-slack-itservice-configure) 标记开头；不包含工具名称、错误 代码、端点、开发者名称或记录 Id — 名称应以人类可读的形式呈现。
• 每次写入都单独运行；先检查幂等读取项（EmployeeServiceSlackEnabled、SLACK_PREFERRED_SITE）， 如果已处于所需状态，则跳过写入。
• 第 4 步：行和分配情况由 scripts/classify-user-access.mjs 分类（不可凭目测判断）；对每位确认的 用户始终分配全部三个核心权限集 — EmployeeSlackNotifications（不是 SlackServiceUser）、 ItsmPortalUelUserPermset 和一个 API-Enabled 权限集（复用现有权限集，否则创建）— 不提供“仅通知” 范围；仅在用户需要该 Agent 时分配 Agent_Access（绝不可使用 Access_Agents）；只分配给已确认的用户； 显示 wrong-license，不要重试。
• 第 5b 步在任何成功摘要之前运行：已确认激活（Network.Status = 'Live'）、发布（页面 已发布 — 不能仅凭 Live 推断）以及为每位第 4 步用户创建了一个 NetworkMember（否则阻止后续操作，并将 补救工作交给 experience-portal-create）— 不得因返回 200/201 而跳过。
• 提供任何第 6 步指导之前：用户已确认其记录（Incident / Service Request / Case）显示在 Slack 中； 如果用户回复“没有任何结果”，应先解决该问题。（Problem/Change 为空是预期情况。）
• 如果运行了第 6 步：缺少 Agent 时，已委派执行 Build and Manage Agent；已读取并检查工作区连接； 已将 Connect Agentforce to Slack 指引为仅限 UI 的操作。
• Slack 管理员侧的环节（第 1 步第 1 部分；第 2 步第 3 部分；第 6 步工作区安装）已交由用户处理。

参考文件索引

每个步骤中 → 后的指针都指向其参考文件：

• references/manage-slack-connection.md（第 2 步） · references/manage-user-access.md + references/record-visibility.md（第 4 步） · references/site-membership-verification.md（第 5b 步） · references/connect-agentforce-to-slack.md（第 6 步）。
• scripts/classify-user-access.mjs — flag-users 为 User 行添加标签；classify-assignment 将 PermissionSetAssignment POST 分类为 success/wrong-license/other-error。

---

相关技能

技能	何时改用／同时使用
service-itsm-agentic-setup-employee-agent-configure	构建／激活在第 6 步中连接的 IT Service Employee Agent；委派给此技能。
service-itsm-agentic-setup-fulfiller-agent-configure	构建／激活 Fulfiller Agent — 可替代第 6 步中的 Agent。
experience-portal-create	创建此技能所选的员工 Digital Experience 门户。
service-itsm-channels-coordinate	ITSM 渠道的顶层菜单 — Slack、Swarming、Notifications、Portal。