service-itsm-teams-itservice-configure

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Set Up Salesforce IT Service (Microsoft Teams)

设置Salesforce IT服务（Microsoft Teams）

Complete the "Set Up Salesforce IT Service" checklist group on the Teams ITSM Go page (

service-cloud-itsm-teams-integration

's feature page) — the employee side of Teams ITSM integration, for employees to create and manage their own tickets from Teams. Every operation dispatches through headless-360.

完成Teams ITSM Go页面（

service-cloud-itsm-teams-integration

的功能页面）上的**「设置Salesforce IT服务」清单组——这是Teams ITSM集成的员工端部分，供员工在Teams中创建和管理自己的工单。所有操作均通过headless-360**调度执行。

Scope

适用范围

In scope: Turning on the
```
OrgHasEmployeeServiceTeams
```
preference; giving the user the exact Teams marketplace link + help doc for the IT Service app install; assigning
```
TeamsForEmployeeUser
```
/
```
MicrosoftGraphAccess
```
permission sets to confirmed users; selecting the Digital Experience Site to link with Teams via the
```
SLACK_PREFERRED_SITE
```
org value.
Out of scope: The base Teams Salesforce Go page toggle (
```
ITSMTeamsEnabled
```
), Azure/Entra app registration, Named Credential population, and Teams extension/preferred-site registration — use
```
service-itsm-teams-configure
```
(a prerequisite for this skill). The IT Desk/fulfiller half of the checklist — use
```
service-itsm-teams-itdesk-configure
```
.

Prerequisite: run

service-itsm-teams-configure

first (or alongside) — this skill assumes the

service-cloud-itsm-teams-integration

Go feature is already enabled.

Execute one step at a time. These steps make real, state-changing API calls. Run a single operation, show its result, confirm it succeeded, then proceed — do not batch multiple setup calls into one parallel block.

包含内容：开启
```
OrgHasEmployeeServiceTeams
```
组织偏好设置；为用户提供IT服务应用安装的Teams市场链接及帮助文档；为已确认的用户分配
```
TeamsForEmployeeUser
```
/
```
MicrosoftGraphAccess
```
权限集；通过
```
SLACK_PREFERRED_SITE
```
组织值选择要与Teams关联的Digital Experience Site。
排除内容：基础Teams Salesforce Go页面开关（
```
ITSMTeamsEnabled
```
）、Azure/Entra应用注册、命名凭证配置以及Teams扩展/首选站点注册——请使用
```
service-itsm-teams-configure
```
（此技能的前置条件）。清单中的IT服务台/处理人员部分——请使用
```
service-itsm-teams-itdesk-configure
```
。

前置条件：先运行

service-itsm-teams-configure

（或同时运行）——此技能假定

service-cloud-itsm-teams-integration

Go功能已启用。

请分步执行操作。这些步骤会调用真实的、改变系统状态的API。每次仅运行一个操作，展示结果，确认成功后再继续——请勿将多个设置调用批量合并到一个并行块中。

Workflow

工作流程

Step 1 — Turn on Salesforce IT Service

步骤1 — 开启Salesforce IT服务

This is a straight org-preference toggle (unlike

ITSMTeamsEnabled

, this one supports direct

PATCH

) — enable it yourself via API, do not ask the user to click the Setup toggle:

text

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

Expect

200 {"isPreferenceEnabled": true}

. Tell the user it's enabled — do not ask them to flip the toggle themselves.

这是一个直接的组织偏好开关（与

ITSMTeamsEnabled

不同，此开关支持直接

PATCH

调用）——通过API自行启用，无需让用户点击设置界面的开关：

text

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

预期返回结果为

200 {"isPreferenceEnabled": true}

。告知用户已启用该功能——请勿让用户自行切换开关。

Step 2 — Install Salesforce IT Service App on Teams (user's responsibility)

步骤2 — 在Teams上安装Salesforce IT服务应用（用户负责操作）

There is no Salesforce or Microsoft API this skill can call to install a Teams app into a tenant's app catalog — this always requires a human clicking "Add" in the Microsoft Teams admin center / AppSource, signed in with sufficient tenant permissions. Give the user the exact marketplace link and help doc; do not attempt to automate this step.

Marketplace (verified live from the Go page's "Go to Microsoft Marketplace" button):
text
```
https://marketplace.microsoft.com/en-us/product/teams-app/WA200009838?tab=Overview
```

Help doc:

https://help.salesforce.com/s/articleView?id=service.it_srvcs_msteams_config_emplye_srvcs_app.htm&type=5

Print both together. Also tell the user the Microsoft email the employee signs in with must match that Salesforce user's
Username
(SSO maps MS UPN →

Username

; a mismatch fails login silently). Then HALT until the user replies "installed" — a human-only action; do not proceed or fabricate the confirmation.

目前没有Salesforce或Microsoft API可用于将Teams应用安装到租户的应用目录中——此操作始终需要拥有足够租户权限的人员在Microsoft Teams管理中心/AppSource中点击“添加”。为用户提供准确的市场链接和帮助文档；请勿尝试自动化此步骤。

市场链接（从Go页面的“前往Microsoft市场”按钮验证为有效链接）：
text
```
https://marketplace.microsoft.com/en-us/product/teams-app/WA200009838?tab=Overview
```

帮助文档：

https://help.salesforce.com/s/articleView?id=service.it_srvcs_msteams_config_emplye_srvcs_app.htm&type=5

同时展示上述两个链接。还要告知用户员工登录所用的Microsoft邮箱必须与Salesforce用户的
Username
匹配（SSO将MS UPN映射到

Username

；不匹配会导致登录静默失败）。然后暂停操作，直到用户回复**“已安装”**——这是仅能由人工完成的操作；请勿继续或伪造确认信息。

Step 3 — Manage User Access

步骤3 — 管理用户访问权限

"Manage User Access" ("Manage" button on the Go page) assigns two permission sets — verified live from the "Manage Microsoft Teams for Employee Service User Access" dialog:

```
TeamsForEmployeeUser
```
(label "Teams for Employee", backed by PSL
```
TeamsForEmployeePsl
```
)
```
MicrosoftGraphAccess
```
(label "MicrosoftGraphAccess") — assigned alongside it in the same dialog.

Do not just assign every active user. Ask the user which specific user(s) should get access. If they want to see the list of users first (rather than naming them), page it — show at most 10 users per page, then ask "want to see more?" before showing the next page, since orgs can have hundreds or thousands of users:

text

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/query",
  queryParams: { "q": "SELECT Id, Name, Username, Email FROM User WHERE IsActive = true ORDER BY Name LIMIT 10 OFFSET <page * 10>" }
)

Verified gotcha: in scratch/test orgs (and possibly some real orgs), the first page(s) of this query are often dominated by non-employee system/integration accounts — e.g.

Automated Process

Bot User

Insights Integration

*.ext

integration users,

ESW_*

*Site Guest User

guest users, and

DigitalAgent.*

agent users. When presenting a page to the user, flag these as likely-not-employee accounts (don't silently filter them out of the list — the user may still want one assigned — but call out which rows look like system accounts so the user doesn't have to guess). If the user says a listed batch is "not employee users, skip," move on to the next page rather than assigning any of them.

Once the user confirms specific user(s), look up each permission set's

Id

(they are stable per org but don't hardcode them — query fresh):

text

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/query",
  queryParams: { "q": "SELECT Id, Name FROM PermissionSet WHERE Name IN ('TeamsForEmployeeUser','MicrosoftGraphAccess')" }
)

Then assign both permission sets to each confirmed user via

PermissionSetAssignment

(one record per user/permset pair — batch with as many calls as needed, there is no bulk-assign endpoint exposed here):

text

mcp__headless-360__dispatch(
  method: "POST",
  url:    "/services/data/v67.0/sobjects/PermissionSetAssignment",
  body:   { "AssigneeId": "<user id>", "PermissionSetId": "<permission set id>" }
)

Verify by re-querying

PermissionSetAssignment

for that

AssigneeId

, or simply trust the

from the assignment call plus a

SELECT ... FROM PermissionSetAssignment WHERE AssigneeId = '<user id>' AND PermissionSetId = '<permset id>'

readback.

“管理用户访问权限”（Go页面上的“管理”按钮）会分配两个权限集——从“管理Microsoft Teams员工服务用户访问权限”对话框中验证：

```
TeamsForEmployeeUser
```
（标签为**“Teams for Employee”**，由PSL
```
TeamsForEmployeePsl
```
支持）
```
MicrosoftGraphAccess
```
（标签为**“MicrosoftGraphAccess”**）——在同一对话框中一并分配。

请勿为所有活跃用户分配权限。询问用户应为哪些特定用户授予访问权限。如果用户希望先查看用户列表（而非直接指定），请分页展示——每页最多显示10个用户，然后询问“是否查看更多？”再展示下一页，因为组织中可能有数百或数千个用户：

text

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/query",
  queryParams: { "q": "SELECT Id, Name, Username, Email FROM User WHERE IsActive = true ORDER BY Name LIMIT 10 OFFSET <page * 10>" }
)

已验证的注意点：在临时/测试组织（可能也包括部分正式组织）中，此查询的前几页通常以非员工的系统/集成账户为主——例如

Automated Process

、

Bot User

、

Insights Integration

、

*.ext

集成用户、

ESW_*

*Site Guest User

访客用户以及

DigitalAgent.*

代理用户。向用户展示页面时，标记这些账户为“非员工账户”（不要从列表中静默过滤——用户可能仍希望为其中某个账户分配权限——但标注出哪些行看起来是系统账户，以免用户猜测）。如果用户表示列出的批次“不是员工用户，跳过”，则直接进入下一页，不为这些账户分配权限。

用户确认特定用户后，查询每个权限集的

Id

（每个组织中的权限集Id是稳定的，但不要硬编码——请实时查询）：

text

mcp__headless-360__dispatch_readonly(
  method: "GET",
  url:    "/services/data/v67.0/query",
  queryParams: { "q": "SELECT Id, Name FROM PermissionSet WHERE Name IN ('TeamsForEmployeeUser','MicrosoftGraphAccess')" }
)

然后通过

PermissionSetAssignment

为每个已确认的用户分配这两个权限集（每个用户/权限集对对应一条记录——根据需要批量调用，此处没有暴露批量分配的端点）：

text

mcp__headless-360__dispatch(
  method: "POST",
  url:    "/services/data/v67.0/sobjects/PermissionSetAssignment",
  body:   { "AssigneeId": "<user id>", "PermissionSetId": "<permission set id>" }
)

可通过重新查询该

AssigneeId

对应的

PermissionSetAssignment

来验证，或直接信任分配调用返回的

状态码，再通过

SELECT ... FROM PermissionSetAssignment WHERE AssigneeId = '<user id>' AND PermissionSetId = '<permset id>'

查询确认。

Login prerequisites (required for the user to actually sign in to IT Service in Teams)

登录前置条件（用户实际登录Teams中的IT服务所需）

Assigning the two permission sets above is necessary but not sufficient — a UEL user who opens the IT Service app in Teams can still hit a silent login failure unless all three of the following are also in place. Verify (and set) these as part of enabling a user:

"Allow OAuth for employees" on the employee login profile (e.g. Unified Employee) — Setup → Profiles → (profile) → Session Settings → check Allow OAuth for employees. Set this in the Setup UI. It is not a Profile SObject field (no OAuth field appears in
```
Profile
```
describe) and it is not the Metadata element
```
Profile.sessionSettings.allowOauthForEmployees
```
— a Profile metadata deploy containing
```
<sessionSettings><allowOauthForEmployees>
```
fails validation:
```
Element {…}sessionSettings invalid at this location in type Profile
```
(verified Aug 2026). Nor is it readable/writable via the headless-360 Connect/REST/Tooling dispatch. Use the Setup UI checkbox. Confirmed blocker: with it off, the OAuth handshake for the embedded app fails and login silently does not complete — the community login succeeds (LoginHistory "Employee Login to Community" = Success) but no
OauthToken
is ever minted for the user, and the Teams app re-pops its "Single Sign-On / Login with URL" chooser (often with a
```
/…/setup/secur/RemoteAccessAuthorizationPage
```
"Service Not Available" popup).
CORS Allowed Origins must include both Teams origins. Check with
```
dispatch_readonly GET /services/data/v67.0/query
```
on
```
SELECT Id, UrlPattern FROM CorsWhitelistEntry
```
, and create any that are missing with
```
dispatch POST /services/data/v67.0/sobjects/CorsWhitelistEntry
```
body
```
{"UrlPattern": "<origin>"}
```
(this is a data-API sobject, not a Tooling type — a Tooling
```
POST
```
/query returns
```
NOT_FOUND
```
/
```
INVALID_TYPE
```
):
- ```
https://teams.cloud.microsoft
```
- ```
https://cdn.scs.static.lightning.force.com
```
  — the Lightning static-resource CDN the embedded IT Service surface loads from. Confirmed blocker: with this origin missing (even when
```
teams.cloud.microsoft
```
  is present), the browser blocks the asset/OAuth preflight and login silently fails. After adding it, have the user hard-refresh / clear the Teams app cache.
"API Enabled" system permission on the user. The UEL user must have the API Enabled system permission — grant it via a permission set (create/choose a permission set → System Settings → check API Enabled → assign to the user), not just the base profile. Without it the embedded app's API calls are rejected and the user can't sign in.

If a user reports "can't log in to IT Service in Teams" and Steps 1–4 all look done, walk these three prerequisites first — they are the most common silent-login blockers. For the full pass/fail diagnostic sequence (including the OAuth-token-mint check that isolates a portal-user OAuth failure), see Troubleshooting: Teams for Employee Service login & agent below.

分配上述两个权限集是必要条件，但并不足够——UEL用户在Teams中打开IT服务应用时仍可能遭遇静默登录失败，除非同时满足以下三个条件。在启用用户时，请验证（并设置）这些条件：

员工登录配置文件上的“允许员工使用OAuth”（例如Unified Employee配置文件）——设置→配置文件→(目标配置文件)→会话设置→勾选允许员工使用OAuth。请在设置UI中完成此操作。这不是Profile对象的字段（
```
Profile
```
描述中没有OAuth相关字段），也不是元数据元素
```
Profile.sessionSettings.allowOauthForEmployees
```
——包含
```
<sessionSettings><allowOauthForEmployees>
```
的Profile元数据部署会验证失败：
```
Element {…}sessionSettings invalid at this location in type Profile
```
（2026年8月验证）。也无法通过headless-360的Connect/REST/Tooling调度进行读写。请使用设置UI中的复选框。已确认的阻塞问题：如果关闭此选项，嵌入式应用的OAuth握手会失败，登录会静默失败——社区登录成功（LoginHistory中的“Employee Login to Community”=成功）但从未为用户生成
OauthToken
，Teams应用会重新弹出“单点登录/使用URL登录”选择器（通常会伴随
```
/…/setup/secur/RemoteAccessAuthorizationPage
```
的“服务不可用”弹窗）。
CORS允许的源必须包含两个Teams源。通过
```
dispatch_readonly GET /services/data/v67.0/query
```
查询
```
SELECT Id, UrlPattern FROM CorsWhitelistEntry
```
来检查，若有缺失则通过
```
dispatch POST /services/data/v67.0/sobjects/CorsWhitelistEntry
```
，请求体为
```
{"UrlPattern": "<origin>"}
```
来创建（这是数据API对象，不是Tooling类型——Tooling的
```
POST
```
/查询会返回
```
NOT_FOUND
```
/
```
INVALID_TYPE
```
）：
- ```
https://teams.cloud.microsoft
```
- ```
https://cdn.scs.static.lightning.force.com
```
  ——嵌入式IT服务界面加载资源的Lightning静态资源CDN。已确认的阻塞问题：如果缺少此源（即使已添加
```
teams.cloud.microsoft
```
  ），浏览器会阻止资源/OAuth预检请求，导致登录静默失败。添加后，请让用户强制刷新/清除Teams应用缓存。
用户的“API已启用”系统权限。UEL用户必须拥有API已启用系统权限——通过权限集授予（创建/选择一个权限集→系统设置→勾选API已启用→分配给用户），而不仅仅依赖基础配置文件。没有此权限的话，嵌入式应用的API调用会被拒绝，用户无法登录。

如果用户报告“无法登录Teams中的IT服务”且步骤1-4均已完成，请首先检查这三个前置条件——它们是最常见的静默登录阻塞因素。如需完整的通过/失败诊断流程（包括隔离门户用户OAuth失败的OAuth令牌生成检查），请参阅下方的故障排查：Teams员工服务登录与代理。

Step 4 — Select a Digital Experience Site

步骤4 — 选择数字体验站点

This checklist item ("Digital Experience Site Name" dropdown, currently "None" until set) is not the same API as

service-itsm-teams-configure

's Teams extension registration (

/connect/service-itsm-teams/graph-api/extensions

) — that one requires the Azure/Entra credential and is gated by the

MsTeamsAppApiFamily

license blocker (see that skill's Gotchas). This checklist item instead reads/writes the org-value

SLACK_PREFERRED_SITE

— the same

OrgValueUtil.OrgValues

Java-enum mechanism as Swarming's

SWARM_COLLABORATION_TOOL

— and is not gated by any Teams license, so it works even when the extension registration is blocked.

List all Digital Experience sites in the org:

text

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

Present the full list to the user and ask them to pick one. If they don't choose, pick one yourself (the only site if there's exactly one, otherwise a sensible default such as the most recently modified
```
Live
```
site) and explicitly tell the user which one you picked — don't proceed silently.
Check the current value first (skip the write if already set to the chosen site's Id):
text
```
mcp__headless-360__dispatch_readonly(method: "GET", url: "/services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE")
```
```
stringValue
```
holds the current selection — the chosen site's
```
Id
```
, or
```
"None"
```
.

Write the selection using the site's

Id

(from step 1's

connect/communities

response — the

Network

record Id, not

urlPathPrefix

text

mcp__headless-360__dispatch(
  method: "PATCH",
  url:    "/services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE",
  body:   { "orgValue": "<site Id>" }
)

Verified live:

PATCH

with a site's Network

Id

(e.g.

0DBSB000002EYwj4AG

) returned

200 {"stringValue": "<that Id>", ...}

, and a follow-up

GET

confirmed the same value persisted.

Re-run step 3's
```
GET
```
to confirm.

此清单项（“Digital Experience Site Name”下拉菜单，默认显示“None”直到设置）不同于

service-itsm-teams-configure

中的Teams扩展注册API（

/connect/service-itsm-teams/graph-api/extensions

）——后者需要Azure/Entra凭证，并受

MsTeamsAppApiFamily

许可证限制（请参阅该技能的注意事项）。此清单项通过读写组织值

SLACK_PREFERRED_SITE

实现——与Swarming的

SWARM_COLLABORATION_TOOL

使用相同的

OrgValueUtil.OrgValues

Java枚举机制——不受任何Teams许可证限制，因此即使扩展注册被阻止也能正常工作。

列出组织中的所有Digital Experience站点：

text

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

向用户展示完整列表并请其选择一个。如果用户未选择，请自行选择（如果只有一个站点则选该站点，否则选择合理的默认值，例如最近修改的
```
Live
```
站点）并明确告知用户你选择的站点——请勿静默操作。
先检查当前值（如果已设置为所选站点的Id，则跳过写入操作）：
text
```
mcp__headless-360__dispatch_readonly(method: "GET", url: "/services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE")
```
```
stringValue
```
字段保存当前选择值——所选站点的
```
Id
```
，或
```
"None"
```
。

使用站点的

Id

（来自步骤1中

connect/communities

响应的

Network

记录Id，不是

urlPathPrefix

）写入选择：

text

mcp__headless-360__dispatch(
  method: "PATCH",
  url:    "/services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE",
  body:   { "orgValue": "<site Id>" }
)

已验证有效：使用站点的Network Id（例如

0DBSB000002EYwj4AG

）进行

PATCH

调用返回

200 {"stringValue": "<that Id>", ...}

，后续

GET

调用确认该值已持久化。

重新运行步骤3的
```
GET
```
调用以确认设置成功。

Step 5 — Make the embedded Agentforce agent reply in Teams

步骤5 — 让嵌入式Agentforce代理在Teams中回复

Completing Steps 1–4 provisions the IT Service surface, but it does not make the embedded Agentforce agent actually reply inside the Teams custom client ("Salesforce Employee Assist" / "Ask AI Agent"). That is the final, hardest part of IT Service agent setup and is covered by a dedicated skill:

→
service-itsm-teams-employee-agent-configure

Invoke it (or hand off to it) after Step 4 when the user wants the in-Teams agent to respond. It covers the verified architecture — a Web channel with User Verification ON + a
JWKS_URL
Key Set, the

Teams_AgentForce

deployment, an Omni-Flow routing flow to a real, Active agent, and an Agent Access permission set on the portal user — plus the diagnostic for the common "agent joins then leaves" symptom (auth ON but no Key Set, or missing Agent Access). The per-user Agent Access assignment there is the natural follow-on to the Manage User Access step (Step 3) above.

Verified gotcha — UI shows stale "None" after the API write. The Go page's dropdown is a wired LDS cache over this org-value; a raw Connect

PATCH

doesn't invalidate it. The write is real and durable (a follow-up

GET

confirms it) — if the Setup page is open, tell the user to hard-refresh the tab to see the new selection.

Naming is misleading — this is a shared, cross-feature setting, not Teams-exclusive. Despite the

SLACK_

prefix (a holdover from this org-value's original Slack-ITSM use case), it backs the "Select a Digital Experience Site" picker on both the Teams ITSM Go page and the equivalent Slack ITSM Go page — writing it from one surface changes what the other surface shows. If the user has also configured Slack ITSM, flag that setting this will also change Slack's preferred site.

完成步骤1-4后，IT服务界面已配置完成，但不会让嵌入式Agentforce代理在Teams自定义客户端（“Salesforce Employee Assist”/“Ask AI Agent”）中实际回复消息。这是IT服务代理设置的最后也是最复杂的部分，由专门的技能覆盖：

→
service-itsm-teams-employee-agent-configure

当用户希望Teams中的代理能够响应时，在步骤4之后调用（或移交至）该技能。它涵盖了已验证的架构——启用用户验证+
JWKS_URL
密钥集的Web渠道、

Teams_AgentForce

部署、路由至真实活跃代理的Omni-Flow路由流程，以及门户用户的Agent Access权限集——还包括针对常见“代理加入后离开”症状的诊断（已启用验证但缺少密钥集，或缺少Agent Access权限）。该技能中的每用户Agent Access分配是上述管理用户访问权限步骤（步骤3）的自然延续。

已验证的注意点——API写入后UI显示陈旧的“None”。Go页面的下拉菜单基于该组织值的LDS缓存；直接的Connect

PATCH

调用不会使缓存失效。写入操作是真实且持久的（后续

GET

调用可确认）——如果设置页面处于打开状态，请告知用户强制刷新标签页以查看新的选择。

命名具有误导性——这是一个共享的跨功能设置，并非Teams专属。尽管前缀为

SLACK_

（此组织值最初用于Slack-ITSM集成的遗留命名），但它同时支持Teams ITSM Go页面和对应的Slack ITSM Go页面上的“选择数字体验站点”选择器——从一个界面写入该值会改变另一个界面的显示内容。如果用户同时配置了Slack ITSM，请告知用户设置此值也会更改Slack的首选站点。

Gotchas

注意事项

Issue	Detail
Requires the Teams Salesforce Go page feature first	`OrgHasEmployeeServiceTeams` does not gate or depend on `ITSMTeamsEnabled` directly, but the Go page checklist only appears once `service-cloud-itsm-teams-integration` is enabled — run `service-itsm-teams-configure` first.
`OrgHasEmployeeServiceTeams` does not unblock `ITSMTeamsEnabled`	These are separate bits — enabling this preference does not itself unblock the Teams Salesforce Go page toggle preference, and vice versa.
"Select a Digital Experience Site" ≠ Teams extension registration — two different site-related APIs, don't conflate	This checklist item writes the org-value `SLACK_PREFERRED_SITE` via `PATCH /services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE` (body `{"orgValue": "<site Id>"}` ) — not gated by `MsTeamsAppApiFamily` , works with no Azure/Entra credential required. `service-itsm-teams-configure` 's `POST /connect/service-itsm-teams/graph-api/extensions` is a different mechanism (Teams "extension" registration) that does require the Azure credential and is gated by `MsTeamsAppApiFamily` . Verified live: `PATCH .../setup/org/values/SLACK_PREFERRED_SITE` with a site's Network `Id` succeeded ( `200` ) in an org where `post-teams-extension` was still blocked with "Unable to fetch tenant ID." Also note despite the `SLACK_` name, this org-value is shared with the Slack ITSM integration's equivalent picker — not Teams-exclusive.
Permission sets / PSLs	`TeamsForEmployeeUser` , `MicrosoftGraphAccess` (permission sets) and PSL `TeamsForEmployeePsl` auto-provisioned and were confirmed `Active` (10 licenses) immediately after the feature-enable in this session — no manual PSL/permset creation needed once `TeamsITSrvcsAddOn` + `IncidentManagementAddOn` are licensed.
Version prefix required	headless-360 `dispatch` / `dispatch_readonly` do not resolve API versions — always pass the full `/services/data/vXX.0/...` prefix.
UEL user can't log in to IT Service in Teams	Assigning `TeamsForEmployeeUser` / `MicrosoftGraphAccess` is not enough. Three additional prerequisites gate login (see Step 3 → Login prerequisites): Allow OAuth for employees on the login profile (Setup-UI-only — no working Metadata/SObject/Tooling write path; verified all fail), CORS Allowed Origins containing both `https://teams.cloud.microsoft` and `https://cdn.scs.static.lightning.force.com` , and the API Enabled system permission on the user. Each is independently a confirmed silent-login blocker.

问题	详情
需先启用Teams Salesforce Go页面功能	`OrgHasEmployeeServiceTeams` 并不直接限制或依赖 `ITSMTeamsEnabled` ，但Go页面清单仅在 `service-cloud-itsm-teams-integration` 启用后才会显示——请先运行 `service-itsm-teams-configure` 。
`OrgHasEmployeeServiceTeams` 不会解除 `ITSMTeamsEnabled` 的限制	这是两个独立的设置——启用此偏好设置本身不会解除Teams Salesforce Go页面开关偏好的限制，反之亦然。
“选择数字体验站点”≠Teams扩展注册——两个不同的站点相关API，请勿混淆	此清单项通过 `PATCH /services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE` （请求体 `{"orgValue": "<site Id>"}` ）写入组织值 `SLACK_PREFERRED_SITE` ——不受 `MsTeamsAppApiFamily` 限制，无需Azure/Entra凭证即可工作。 `service-itsm-teams-configure` 中的 `POST /connect/service-itsm-teams/graph-api/extensions` 是一种不同的机制（Teams“扩展”注册），需要Azure凭证且受 `MsTeamsAppApiFamily` 限制。已验证有效：在 `post-teams-extension` 仍因“无法获取租户ID”被阻止的组织中， `PATCH .../setup/org/values/SLACK_PREFERRED_SITE` 使用站点的Network Id调用成功（返回 `200` ）。另外请注意，尽管名称带有 `SLACK_` ，此组织值与Slack ITSM集成的对应选择器共享——并非Teams专属。
权限集/PSLs	`TeamsForEmployeeUser` 、 `MicrosoftGraphAccess` （权限集）和PSL `TeamsForEmployeePsl` 在功能启用后会自动配置，并在此会话中确认为 `Active` （10个许可证）——一旦 `TeamsITSrvcsAddOn` + `IncidentManagementAddOn` 已授权，无需手动创建PSL/权限集。
必须指定版本前缀	headless-360的 `dispatch` / `dispatch_readonly` 不会解析API版本——请始终传递完整的 `/services/data/vXX.0/...` 前缀。
UEL用户无法登录Teams中的IT服务	仅分配 `TeamsForEmployeeUser` / `MicrosoftGraphAccess` 权限集是不够的。登录还受三个额外前置条件限制（请参阅步骤3 → 登录前置条件）：登录配置文件上的允许员工使用OAuth（仅能在设置UI中配置——没有可用的元数据/对象/Tooling写入路径；已验证所有尝试均失败）、CORS允许的源包含 `https://teams.cloud.microsoft` 和 `https://cdn.scs.static.lightning.force.com` ，以及用户拥有API已启用系统权限。每个条件都是已确认的静默登录阻塞因素。

Troubleshooting: Teams for Employee Service login & agent

故障排查：Teams员工服务登录与代理

When a user reports a Teams for Employee Service failure (can't log in, "Service Not Available" popup, agent won't reply), run these checks in order — each is a pass/fail gate with an exact query and remediation. Stop at the first one that fails; they are ordered from most-common and cheapest to deepest.

For a broader guided diagnosis across all Teams ITSM symptoms (IT Desk login, feature enablement, tab loading, service catalog, Agentforce, Swarming, SSO — not just IT Service login), use the dedicated service-itsm-teams-debug
skill, which routes the reported problem to the matching pass/fail checklist. The sequence below is the IT-Service-login-focused subset.

Run the read-only checks with
dispatch_readonly
(a Tooling-object check is noted where the query needs the Tooling API). Convert the placeholder ids to the real ones you find as you go.

当用户报告Teams员工服务故障（无法登录、“服务不可用”弹窗、代理不回复）时，请按顺序执行以下检查——每个检查都是通过/失败的关卡，包含精确的查询和修复方法。在第一个失败的检查处停止；检查顺序是从最常见、成本最低到最深入的问题。

如需针对所有Teams ITSM症状（IT服务台登录、功能启用、标签页加载、服务目录、Agentforce、Swarming、SSO——不仅仅是IT服务登录）进行更全面的引导式诊断，请使用专门的**
service-itsm-teams-debug
**技能，它会将报告的问题路由到匹配的通过/失败清单并给出修复建议。以下是针对IT服务登录的子集序列。

使用
dispatch_readonly
执行只读检查（需要Tooling API的查询会特别标注）。在执行过程中将占位符ID替换为实际找到的ID。

A. Community login itself

A. 社区登录本身

text

SELECT LoginTime, Status, LoginType FROM LoginHistory
  WHERE UserId='<userId>' ORDER BY LoginTime DESC LIMIT 5

No community access
→ the site's
```
Network.OptionsAllowInternalUserLogin
```
is off for an internal/UEL user. Enable "Allow internal users to log in directly" on the site's login settings (see the portal-create skill's internal-login flag). Different failure from the ones below — fix this first if present.
Employee Login to Community
=
Success
→ login works; the failure is downstream in OAuth or agent runtime. Continue to B.

text

SELECT LoginTime, Status, LoginType FROM LoginHistory
  WHERE UserId='<userId>' ORDER BY LoginTime DESC LIMIT 5

No community access
→ 针对内部/UEL用户，站点的
```
Network.OptionsAllowInternalUserLogin
```
已关闭。在站点的登录设置中启用“允许内部用户直接登录”（请参阅门户创建技能中的内部登录标志）。与以下故障不同——如果存在此问题，请先修复。
Employee Login to Community
=
Success
→ 登录成功；故障出现在OAuth或代理运行阶段。继续执行检查B。

B. The three silent-login prerequisites (see Step 3 → Login prerequisites)

B. 三个静默登录前置条件（请参阅步骤3 → 登录前置条件）

Allow OAuth for employees on the login profile (Setup-UI-only checkbox). No API read path — verify by the OAuth-token check in C below (its real symptom).

CORS Allowed Origins — must contain both origins:

text

SELECT Id, UrlPattern FROM CorsWhitelistEntry

Missing

https://teams.cloud.microsoft

https://cdn.scs.static.lightning.force.com

→ create it (

POST /sobjects/CorsWhitelistEntry

{"UrlPattern":"<origin>"}

), then hard-refresh.

API Enabled system permission on the user (via a permission set, not just the profile).

登录配置文件上的“允许员工使用OAuth”（仅能在设置UI中勾选）。没有API读取路径——通过下方C中的OAuth令牌检查来验证（这是其真实症状）。

CORS允许的源——必须包含两个源：

text

SELECT Id, UrlPattern FROM CorsWhitelistEntry

缺少

https://teams.cloud.microsoft

或

https://cdn.scs.static.lightning.force.com

→ 创建对应的条目（

POST /sobjects/CorsWhitelistEntry

，请求体

{"UrlPattern":"<origin>"}

），然后强制刷新。

用户的“API已启用”系统权限（通过权限集授予，而非仅依赖配置文件）。

C. OAuth token mint — the decisive portal-user check

C. OAuth令牌生成——门户用户的决定性检查

This is the check that isolates a portal/UEL OAuth failure from a login failure. After the user retries login from a fresh Teams chat:

text

SELECT Id, AppName, UserId, User.Username, CreatedDate FROM OauthToken
  WHERE AppName='ServiceCloudMSTeamsEca'

A token row exists for the failing user → OAuth succeeded; the problem is agent-runtime, not login — jump to E.
No token for the failing user, but community login shows
Success
(B) → the OAuth authorize step never minted a token. This is the "Service Not Available" popup on
```
/<sitePrefix>/setup/secur/RemoteAccessAuthorizationPage
```
. Work through D.

Diagnostic tell (verified): if a Standard-profile user mints a
ServiceCloudMSTeamsEca
token but a Unified Employee (UEL) / portal user does not — even with identical permission sets — the blocker is specific to the portal-user OAuth authorize path (profile OAuth flag, or the ECA self-authorization page being served on the community host), not the ECA authorization grant. In the verified org the Standard user minted a token without even holding the ECA-authorizing permission set, while the UEL user holding everything did not — so an identical permission-set/SetupEntityAccess config does not explain the difference.

此检查用于区分门户/UEL用户的OAuth故障与登录故障。用户从全新的Teams聊天中重试登录后：

text

SELECT Id, AppName, UserId, User.Username, CreatedDate FROM OauthToken
  WHERE AppName='ServiceCloudMSTeamsEca'

存在该故障用户的令牌记录 → OAuth成功；问题出在代理运行阶段，而非登录阶段——跳至检查E。
故障用户无令牌记录，但社区登录显示
Success
（检查B） → OAuth授权步骤从未生成令牌。这会导致在
```
/<sitePrefix>/setup/secur/RemoteAccessAuthorizationPage
```
页面弹出“服务不可用”弹窗。执行检查D。

诊断提示（已验证）：如果标准配置文件用户能生成
ServiceCloudMSTeamsEca
令牌，但Unified Employee (UEL)/门户用户无法生成——即使拥有相同的权限集——阻塞因素是特定于门户用户的OAuth授权路径（配置文件OAuth标志，或ECA自授权页面在社区主机上提供），而非ECA授权授予。在已验证的组织中，标准用户即使没有持有ECA授权的权限集也能生成令牌，而拥有所有权限的UEL用户却无法生成——因此相同的权限集/SetupEntityAccess配置无法解释此差异。

D. ECA (External Client App) OAuth self-authorization

D. ECA（外部客户端应用）OAuth自授权

The

ServiceCloudMSTeamsEca

External Client App gates the OAuth authorize. Symptom: the Teams popup titled "Service Not Available / An unexpected connection error occurred" at

/<sitePrefix>/setup/secur/RemoteAccessAuthorizationPage

, and/or an access-check error body {"acc":8}
on the streaming endpoint.

Policy must be
AdminApprovedPreAuthorized
(not

AllSelfAuthorized

text

SELECT Id, PermittedUsersPolicyType FROM ExtlClntAppOauthPlcyCnfg
  WHERE ExternalClientApplicationId='<ecaId>'   (Tooling)

AllSelfAuthorized

forces every user through the self-approval page, which communities cannot serve (

/setup/secur/*

is a Setup page) → the connection error. Fix by editing the

ExternalClientApplication

's OAuth policy via Metadata (the Tooling object is read-only —

update

→

CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY

): retrieve

ExtlClntAppOauthConfigurablePolicies:<Eca>_oauth_defaultPolicy

, set

<permittedUsersPolicyType>AdminApprovedPreAuthorized</permittedUsersPolicyType>

, redeploy. (Valid enum values are only

AllSelfAuthorized

and

AdminApprovedPreAuthorized

—

AdminApproved

is invalid.)

Pre-authorize the ECA to a permission set the user holds —

AdminApprovedPreAuthorized

denies everyone not explicitly authorized (surfaces as

{"acc":8}

text

SELECT ParentId, SetupEntityType FROM SetupEntityAccess WHERE SetupEntityId='<ecaId>'

If missing, create

SetupEntityAccess {ParentId=<permsetId the user has>, SetupEntityId=<ecaId>}

(no

SetupEntityType

— it auto-resolves to

ExternalClientApplication

If policy is
AdminApprovedPreAuthorized
, the user holds an authorized permission set, and "Allow OAuth for employees" is on — yet the token still doesn't mint for the portal user (per C): the remaining suspect is that the OAuth authorize is being routed to the community host (
```
https://<org>.my.site.com/<prefix>/setup/secur/...
```
), which cannot render the authorization page, rather than to My Domain. This ECA is packaged/first-party — do NOT hand-edit its
```
callbackUrl
```
/
```
isFirstPartyAppEnabled
```
/
```
oauthLink
```
. At this point capture the exact popup URL + any
```
acc
```
code and escalate to the Teams ITSM / ECA product team; it is beyond a configurable-setting fix.

ServiceCloudMSTeamsEca

外部客户端应用控制OAuth授权。症状：Teams弹出标题为**“服务不可用/发生意外连接错误”的弹窗，指向
/<sitePrefix>/setup/secur/RemoteAccessAuthorizationPage
，和/或流端点返回访问检查错误体

{"acc":8}

**。

策略必须为
AdminApprovedPreAuthorized
（而非

AllSelfAuthorized

）：

text

SELECT Id, PermittedUsersPolicyType FROM ExtlClntAppOauthPlcyCnfg
  WHERE ExternalClientApplicationId='<ecaId>'   (Tooling)

AllSelfAuthorized

会强制所有用户通过自授权页面，而社区无法提供该页面（

/setup/secur/*

是设置页面）→ 导致连接错误。通过元数据编辑

ExternalClientApplication

的OAuth策略来修复（Tooling对象是只读的——

update

操作会返回

CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY

）：检索

ExtlClntAppOauthConfigurablePolicies:<Eca>_oauth_defaultPolicy

，设置

<permittedUsersPolicyType>AdminApprovedPreAuthorized</permittedUsersPolicyType>

，重新部署。（有效枚举值仅为

AllSelfAuthorized

和

AdminApprovedPreAuthorized

——

AdminApproved

无效。）

预授权ECA访问用户持有的权限集——

AdminApprovedPreAuthorized

会拒绝所有未明确授权的用户（表现为

{"acc":8}

）：

text

SELECT ParentId, SetupEntityType FROM SetupEntityAccess WHERE SetupEntityId='<ecaId>'

如果缺失，创建

SetupEntityAccess {ParentId=<用户拥有的权限集Id>, SetupEntityId=<ecaId>}

（无需

SetupEntityType

——会自动解析为

ExternalClientApplication

）。

如果策略为
AdminApprovedPreAuthorized
，用户持有授权的权限集，且“允许员工使用OAuth”已开启——但门户用户仍无法生成令牌（检查C）：剩余的可疑点是OAuth授权被路由到社区主机（
```
https://<org>.my.site.com/<prefix>/setup/secur/...
```
），而该主机无法渲染授权页面，而非路由到My Domain。此ECA是打包/第一方应用——请勿手动编辑其
```
callbackUrl
```
/
```
isFirstPartyAppEnabled
```
/
```
oauthLink
```
。此时请捕获准确的弹窗URL + 任何
```
acc
```
代码，并升级至Teams ITSM/ECA产品团队；这超出了可配置设置的修复范围。

E. Embedded Agentforce agent joins then leaves (no reply)

E. 嵌入式Agentforce代理加入后离开（不回复）

If login + OAuth succeed but the "Ask AI Agent" agent won't reply, hand off to

service-itsm-teams-employee-agent-configure

— the two verified fixes are (1) the

Teams_AgentForce

channel's User Verification ON backed by a
JWKS_URL
Key Set and (2) an Agent Access permission set enabling the IT Service Employee Agent on the portal user. That skill's reference has the full runtime-chain diagnostics (scrt2 token, SSE 401,

ConversationEntry

queries).

如果登录+OAuth成功，但“Ask AI Agent”代理不回复，请移交至

service-itsm-teams-employee-agent-configure

——已验证的两个修复方法是（1）

Teams_AgentForce

渠道启用用户验证并配置
JWKS_URL
密钥集，以及（2）为门户用户启用IT服务员工代理的Agent Access权限集。该技能的参考文档包含完整的运行时链诊断（scrt2令牌、SSE 401、

ConversationEntry

查询）。

Skill	When to use instead / alongside
`service-itsm-teams-configure`	Enabling the base Teams Salesforce Go page toggle, Azure/Entra app registration, Named Credential population, and Teams extension registration — a prerequisite for this skill
`service-itsm-teams-itdesk-configure`	The IT Desk/fulfiller half of the checklist (Turn on IT Desk, Install IT Desk app, Manage User Access, Set Teams as Collaboration Tool for Swarming)
`service-itsm-teams-employee-agent-configure`	The final part of IT Service agent setup — making the embedded Agentforce agent actually reply in the Teams custom client (Web channel, User Verification ON + `JWKS_URL` Key Set, `Teams_AgentForce` deployment, routing flow to a real Active agent, Agent Access permission set). Hand off to it after Step 4.
`service-itsm-teams-debug`	Diagnosing a failing Teams ITSM setup across any symptom (login, feature enablement, tab loading, Agentforce, Swarming, SSO) — routes the problem to a pass/fail checklist and reports remediation
`service-itsm-channels-coordinate`	Top-level menu across Teams, Slack, Swarming, Notifications, Portal

技能	替代/配合使用场景
`service-itsm-teams-configure`	启用基础Teams Salesforce Go页面开关、Azure/Entra应用注册、命名凭证配置以及Teams扩展注册——此技能的前置条件
`service-itsm-teams-itdesk-configure`	清单中的IT服务台/处理人员部分（开启IT服务台、安装IT服务台应用、管理用户访问权限、设置Teams为Swarming的协作工具）
`service-itsm-teams-employee-agent-configure`	IT服务代理设置的最后部分——让嵌入式Agentforce代理在Teams自定义客户端中实际回复消息（Web渠道、启用用户验证+ `JWKS_URL` 密钥集、 `Teams_AgentForce` 部署、路由至真实活跃代理的路由流程、Agent Access权限集）。步骤4之后移交至该技能。
`service-itsm-teams-debug`	排查任何Teams ITSM设置故障（登录、功能启用、标签页加载、Agentforce、Swarming、SSO）——将问题路由到通过/失败清单并给出修复建议
`service-itsm-channels-coordinate`	Teams、Slack、Swarming、通知、门户的顶级菜单

service-itsm-teams-itservice-configure

Original

Translation

Set Up Salesforce IT Service (Microsoft Teams)

设置Salesforce IT服务（Microsoft Teams）

Scope

适用范围

Workflow

工作流程

Step 1 — Turn on Salesforce IT Service

步骤1 — 开启Salesforce IT服务

Step 2 — Install Salesforce IT Service App on Teams (user's responsibility)

步骤2 — 在Teams上安装Salesforce IT服务应用（用户负责操作）

Step 3 — Manage User Access

步骤3 — 管理用户访问权限

Login prerequisites (required for the user to actually sign in to IT Service in Teams)

登录前置条件（用户实际登录Teams中的IT服务所需）

Step 4 — Select a Digital Experience Site

步骤4 — 选择数字体验站点

Step 5 — Make the embedded Agentforce agent reply in Teams

步骤5 — 让嵌入式Agentforce代理在Teams中回复

Gotchas

注意事项

Troubleshooting: Teams for Employee Service login & agent

故障排查：Teams员工服务登录与代理

A. Community login itself

A. 社区登录本身

B. The three silent-login prerequisites (see Step 3 → Login prerequisites)

B. 三个静默登录前置条件（请参阅步骤3 → 登录前置条件）

C. OAuth token mint — the decisive portal-user check

C. OAuth令牌生成——门户用户的决定性检查

D. ECA (External Client App) OAuth self-authorization

D. ECA（外部客户端应用）OAuth自授权

E. Embedded Agentforce agent joins then leaves (no reply)

E. 嵌入式Agentforce代理加入后离开（不回复）

Related Skills

相关技能