service-itsm-teams-itservice-configure

Salesforce IT Service の設定（Microsoft Teams）

Teams ITSM Go ページ（service-cloud-itsm-teams-integration の機能ページ）で、**「Salesforce IT Service の設定」**チェックリストグループを完了します。これは Teams ITSM 統合の従業員側の設定で、従業員が Teams から自分のチケットを作成、管理できるようにします。すべての操作は headless-360 を通じて実行されます。

対象範囲

• 対象：OrgHasEmployeeServiceTeams 設定を有効にすること、IT Service アプリのインストール用に正確な Teams マーケットプレイスリンクとヘルプドキュメントをユーザーに提供すること、確認済みのユーザーに TeamsForEmployeeUser 権限セットを割り当てること、SLACK_PREFERRED_SITE 組織値を使用して Teams と連携する Digital Experience サイトを選択すること。
• 対象外：Teams Salesforce Go ページの基本トグル（ITSMTeamsEnabled）、Azure／Entra アプリ登録、Named Credential の設定、Teams 拡張機能／優先サイトの登録。これらには service-itsm-teams-configure（このスキルの前提条件）を使用してください。IT Desk／対応担当者側のチェックリストには service-itsm-teams-itdesk-configure を使用してください。

前提条件： 先に（または並行して）service-itsm-teams-configure を実行してください。このスキルでは、service-cloud-itsm-teams-integration Go 機能がすでに有効になっていることを前提とします。

一度に 1 つの手順を実行してください。 これらの手順では、実際に状態を変更する API 呼び出しを行います。操作を 1 つ実行し、結果を表示して成功を確認してから次に進んでください。複数のセットアップ呼び出しを 1 つの並列ブロックにまとめないでください。

---

ワークフロー

手順 1 — Salesforce IT Service を有効にする

これは組織設定の単純なトグルです（ITSMTeamsEnabled とは異なり、直接 PATCH をサポートします）。Setup のトグルをクリックするようユーザーに頼まず、API を使用して自分で有効にしてください。

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

200 {"isPreferenceEnabled": true} が返されることを確認してください。有効になったことをユーザーに伝えてください。ユーザー自身にトグルを切り替えるよう頼まないでください。

手順 2 — Teams に Salesforce IT Service アプリをインストールする（ユーザーの責任）

Salesforce または Microsoft の API で、Teams アプリをテナントのアプリカタログにインストールする方法はありません。これは常に、十分なテナント権限でサインインした人が Microsoft Teams 管理センター／AppSource で「追加」をクリックする必要があります。正確なマーケットプレイスリンクとヘルプドキュメントをユーザーに提供し、この手順を自動化しようとしないでください。

• マーケットプレイス（Go ページの「Microsoft Marketplace に移動」ボタンからライブで確認済み）：

  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 では Microsoft の UPN から Username にマッピングされます。不一致の場合、ログインは失敗しますが、そのことが通知されません）。その後、ユーザーが 「installed」 と返信するまで停止してください。これは人だけが実行できる操作です。先に進んだり、確認を捏造したりしないでください。

ステップ 3 — ユーザーアクセスを管理する

「ユーザーアクセスを管理」（Go ページの「管理」ボタン）では、権限セットを割り当てます。権限セットは「Microsoft Teams for Employee Service ユーザーアクセスを管理」ダイアログでライブに確認済みです。

• TeamsForEmployeeUser（表示名 「Teams for Employee」、PSL TeamsForEmployeePsl によって提供）

有効なユーザー全員に割り当ててはいけません。 アクセスを付与する特定のユーザーを確認してください。 ユーザー名を指定するのではなく、まず一覧を見たいと言われた場合は、ページ分けしてください。組織には数百人、数千人のユーザーがいる場合があるため、1 ページにつき最大 10 人まで表示し、次のページを表示する前に「続きも表示しますか？」と確認してください。

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>" }
)

割り当て対象について、事前にユーザーに注意してください。 対象は、Azure／Entra 側にメールアドレスが存在する（同じテナント内の Microsoft アカウントを持つ）実際の従業員／UEL ユーザーである必要があります。ログインは SSO（MS の UPN → Salesforce の Username）を使うため、対応する Azure アカウントがないユーザーや、メールアドレス／UPN が一致しないユーザーに割り当てると、ログインは失敗しても通知されません（上記の UPN と Username に関する注意を参照）。割り当てる前にこの点を伝えてください。システムアカウントや連携アカウントには決して割り当てないでください。

確認済みの注意点（選んではいけないユーザーの見分け方）： スクラッチ組織やテスト組織では、最初の数ページが従業員以外のアカウント（たとえば Automated Process、Bot User、Insights Integration、*.ext の連携ユーザー、ESW_*／*Site Guest User のゲスト、DigitalAgent.* のエージェント）で占められていることがよくあります。これらは従業員／UEL ユーザーではなく、Azure ID もありません。該当する行は従業員ではない可能性が高いと伝えてください（黙って除外せず、明示してください）。ユーザーが「従業員以外のユーザーはスキップして」と言った場合は、次のページに進んでください。

ユーザーが特定のユーザーを確認したら、権限セットの Id を取得してください（組織ごとに安定していますが、ハードコードせず、都度クエリしてください）。

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

次に、PermissionSetAssignment を使って確認済みの各ユーザーに権限セットを割り当てます（ユーザーごとに 1 レコードです。ここでは一括割り当てエンドポイントが公開されていないため、必要な回数だけ呼び出してまとめてください）。

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

PermissionSetAssignment を再クエリして該当する AssigneeId を確認するか、割り当て呼び出しからの 201 と、SELECT ... FROM PermissionSetAssignment WHERE AssigneeId = '<user id>' AND PermissionSetId = '<permset id>' の読み戻しをもって確認とします。

IT Service に Teams で実際にサインインするためのログイン前提条件（必須）

上記の権限セットの割り当ては必要ですが、それだけでは不十分です。UEL ユーザーが Teams で IT Service アプリを開いても、以下の 3 つの条件がすべて満たされていないと、ログインが通知なく失敗することがあります。ユーザーを有効化する際に、これらも確認（および設定）してください。

1. 従業員ログインプロファイルの「Allow OAuth for employees」（例：Unified Employee）— Setup → Profiles → (profile) → Session Settings → Allow OAuth for employees にチェックを入れます。 この設定は Setup UI で行ってください。 これは Profile SObject のフィールドではなく（Profile の describe に OAuth フィールドは表示されません）、Metadata 要素 Profile.sessionSettings.allowOauthForEmployees でもありません。<sessionSettings><allowOauthForEmployees> を含む Profile メタデータのデプロイは、Element {…}sessionSettings invalid at this location in type Profile というエラーで検証に失敗します（2026 年 8 月に確認）。また、ヘッドレスの 360 Connect／REST／Tooling ディスパッチ経由で読み取り・書き込みすることもできません。Setup UI のチェックボックスを使用してください。確認済みのブロッカーです。この設定がオフだと、埋め込みアプリの OAuth ハンドシェイクが失敗し、ログインが通知なく完了しません。コミュニティへのログインは成功します（LoginHistory の「Employee Login to Community」＝ Success）が、ユーザーの OauthToken は発行されず、Teams アプリに「Single Sign-On / Login with URL」の選択画面が再表示されます（多くの場合、/…/setup/secur/RemoteAccessAuthorizationPage の「Service Not Available」ポップアップが表示されます）。

2. CORS Allowed Origins に 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 の SObject であり、Tooling の型ではありません。Tooling の POST／クエリは NOT_FOUND／INVALID_TYPE を返します）。

   • https://teams.cloud.microsoft
   • https://cdn.scs.static.lightning.force.com — 埋め込みの IT Service サーフェスが読み込む Lightning 静的リソース CDN です。確認済みのブロッカーです。このオリジンがないと、teams.cloud.microsoft が登録済みでも、ブラウザーがアセット／OAuth のプリフライトをブロックし、ログインが通知なく失敗します。追加後、ユーザーに Teams アプリを強制再読み込みするか、キャッシュをクリアしてもらってください。

3. ユーザーに対する 「API Enabled」 システム権限を、ベースプロファイルだけでなく権限セットで付与してください（PermissionsApiEnabled = true）。付与されていないと、埋め込みアプリの API 呼び出しが拒否され、ユーザーはサインインできません。IT Desk が使用する、組織全体で一度だけ作成する同じ権限セット（一般的には Teams_Employee_ApiAccess）を使用してください。PermissionSet WHERE Name = 'Teams_Employee_ApiAccess' をクエリし、存在しない場合は一度だけ作成して（POST /sobjects/PermissionSet {"Name":"Teams_Employee_ApiAccess","Label":"Teams Employee API Access","PermissionsApiEnabled":true}）、その後割り当てます。重複して作成しないでください。service-itsm-teams-itdesk-configure の ログイン前提条件 を参照してください。

ユーザーから「Teams で IT Service にログインできない」と報告があり、手順 1～4 がすべて完了しているように見える場合は、まずこの 3 つの前提条件を確認してください。通知のないログイン失敗の最も一般的な原因です。合否を確認する完全な診断手順（ポータルユーザーの OAuth 失敗を切り分ける OAuth トークン発行チェックを含む）は、以下のトラブルシューティング：従業員向けサービスの Teams ログインとエージェントを参照してください。

ステップ 4 — Digital Experience サイトを選択する

このチェックリスト項目（「Digital Experience Site Name」ドロップダウン。設定されるまでは現在「None」） は、org-value SLACK_PREFERRED_SITE の読み書きを行います。これは Swarming の SWARM_COLLABORATION_TOOL と同じ OrgValueUtil.OrgValues Java enum メカニズムであり、 Teams ライセンスや Azure／Entra 資格情報の有無に左右されないため、Teams 設定のほかの部分とは独立して動作します。

1. 組織内のすべての Digital Experience サイトを一覧表示します：

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

   組織に Digital Experience サイトがまだない場合（リストが空の場合）、このステップを完了する前にサイトを作成する必要があります。experience-portal-create に引き継いで新しいサイトをプロビジョニングします（従業員向けサービス／IT サポートポータルがこの用途に適しています）。その後、サイトの Id を持ってここに戻ります。
2. 完全なリストをユーザーに提示し、1 つ選ぶよう依頼します。ユーザーが選ばない場合は、こちらで 1 つ選びます（サイトが 1 つだけならそのサイト、それ以外の場合は、最終更新日時が最も新しい Live サイトなどの妥当なデフォルト）。どれを選んだかをユーザーに明示的に伝えてください。何も伝えずに先へ進んではいけません。
3. まず現在の値を確認します（選択したサイトの Id がすでに設定されている場合は書き込みを省略します）：

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

   stringValue には現在の選択値、つまり選択したサイトの Id または "None" が格納されています。
4. サイトの Id（ステップ 1 の connect/communities レスポンスに含まれる Network レコードの Id。urlPathPrefix ではありません）を使って選択を書き込みます：

   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 で、同じ値が保持されていることを確認しました。
5. ステップ 3 の GET を再実行して確認します。

ステップ 5 — 埋め込み Agentforce エージェントが Teams で返信するようにする

ステップ 1～4 を完了すると IT Service の画面がプロビジョニングされますが、Teams のカスタムクライアント（「Salesforce Employee Assist」／ 「Ask AI Agent」）内で埋め込み Agentforce エージェントが実際に返信するようにはなりません。これは IT Service エージェント設定の最後の、最も難しい部分であり、専用スキルで説明しています：

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

ユーザーが Teams 内のエージェントによる応答を希望する場合は、ステップ 4 の後にこのスキルを呼び出す（または引き継ぐ）ようにしてください。このスキルでは、検証済みのアーキテクチャ（User Verification が ON で、JWKS_URL Key Set を設定した Web チャネル、Teams_AgentForce デプロイメント、実在する Active エージェントにルーティングする Omni-Flow フロー、ポータルユーザーの Agent Access 権限セット）に加え、「エージェントが参加してすぐに退出する」というよくある症状の診断（認証は ON だが Key Set がない、または Agent Access が不足している場合）を扱います。ここで行うユーザーごとの Agent Access 割り当ては、上記の「Manage User Access」ステップ（ステップ 3）の自然な続きです。

検証済みの注意点 — API 書き込み後も UI には古い「None」が表示されます。 Go ページのドロップダウンは、この org-value を参照する LDS キャッシュです。Connect の PATCH を直接実行しても、キャッシュは無効化されません。書き込み自体は成功しており、値も保持されます（続く GET で確認できます）。Setup ページを開いている場合は、新しい選択内容を表示するためにタブをハードリフレッシュするようユーザーに伝えてください。

名前は誤解を招きます — これは共有設定であり、Teams 専用ではありません。 SLACK_ というプレフィックスは、この org-value がもともと Slack ITSM で使われていた名残です。この値は、Teams ITSM Go ページと同等の Slack ITSM Go ページの両方にある「Select a Digital Experience Site」ピッカーを制御するため、一方の画面から値を書き込むと、もう一方の画面の表示も変わります。ユーザーが Slack ITSM も設定している場合は、これを設定すると Slack の優先サイトも変更されることを伝えてください。

注意点

問題	詳細
先に Teams Salesforce Go ページ機能が必要です	OrgHasEmployeeServiceTeams は ITSMTeamsEnabled を直接制御したり、依存したりしませんが、Go ページのチェックリストは service-cloud-itsm-teams-integration が有効になってから表示されます。先に service-itsm-teams-configure を実行してください。
OrgHasEmployeeServiceTeams を有効にしても ITSMTeamsEnabled は解除されません	これらは別個の設定です。この設定を有効にしても Teams Salesforce Go ページの切り替え設定は解除されません。その逆も同様です。
「Select a Digital Experience Site」は Teams API ではなく、組織値を書き込みます	このチェックリスト項目は、PATCH /services/data/v67.0/setup/org/values/SLACK_PREFERRED_SITE（本文 {"orgValue": "<site Id>"}）を使って組織値 SLACK_PREFERRED_SITE を書き込みます。Azure／Entra の認証情報も Teams ライセンスも必要ありません。実環境で確認済み：サイトの Network Id を指定した PATCH は、他の Teams セットアップとは独立して成功しました（200）。組織に Digital Experience サイトがない場合は、まず experience-portal-create で作成してください。SLACK_ という名前ですが、この組織値は Slack ITSM 統合の同等の選択機能と共有されており、Teams 専用ではありません。
権限セット／PSL	TeamsForEmployeeUser（権限セット）と PSL TeamsForEmployeePsl は、このセッションで機能を有効にした直後に自動プロビジョニングされ、Active（ライセンス 10 個）であることが確認されました。TeamsITSrvcsAddOn と IncidentManagementAddOn のライセンスがあれば、PSL／権限セットを手動で作成する必要はありません。
バージョンプレフィックスが必要です	headless-360 の dispatch／dispatch_readonly は API バージョンを解決しません。必ず /services/data/vXX.0/... の完全なプレフィックスを指定してください。
UEL ユーザーが Teams の IT Service にログインできません	TeamsForEmployeeUser を割り当てるだけでは不十分です。ログインにはさらに 3 つの前提条件があります（Step 3 → Login prerequisites を参照）：ログインプロファイルでの Allow OAuth for employees（Setup UI のみ。Metadata／SObject／Tooling を使った書き込み方法は機能せず、すべて失敗することを確認済み）、https://teams.cloud.microsoft および https://cdn.scs.static.lightning.force.com の両方を含む CORS Allowed Origins、ユーザーの API Enabled システム権限です。それぞれが単独で、確認済みのサイレントログイン阻害要因となります。

---

トラブルシューティング：Teams for Employee Service のログインとエージェント

ユーザーから Teams for Employee Service の問題（ログインできない、「Service Not Available」の ポップアップが表示される、エージェントが応答しない）が報告された場合は、これらの確認を順番に 実行してください。それぞれが正確なクエリと対処方法を伴う合否判定です。最初に失敗した項目で停止します。確認項目は、最も一般的で手軽なものから、より深いものへと並んでいます。

Teams ITSM のあらゆる症状（IT Desk のログイン、機能の有効化、タブの読み込み、サービスカタログ、Agentforce、Swarming、SSO など。IT Service のログインだけではありません）を対象に、より広範なガイド付き診断を行うには、専用の service-itsm-teams-debug スキルを使用してください。報告された問題に対応する合否チェックリストに案内します。以下の手順は、IT Service のログインに焦点を絞ったサブセットです。

読み取り専用の確認には dispatch_readonly を使用してください（クエリで Tooling API が必要な場合は、Tooling オブジェクトの確認として記載しています）。確認を進めながら、プレースホルダーの ID を実際に見つかった ID に置き換えてください。

A. コミュニティへのログイン自体

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

• No community access → 内部ユーザー／UEL ユーザーに対して、サイトの Network.OptionsAllowInternalUserLogin がオフになっています。サイトのログイン設定で「Allow internal users to log in directly」を有効にしてください（ポータル作成スキルの内部ログインフラグを参照）。以下の項目とは異なる問題です。該当する場合は、まずこれを修正してください。
• Employee Login to Community = Success → ログインは機能しています。問題はその後の OAuth またはエージェントのランタイムにあります。B に進んでください。

B. サイレントログインの3つの前提条件（ステップ3 → ログインの前提条件を参照）

1. ログインプロファイルで従業員のOAuthを許可します（Setup UIのみのチェックボックス）。APIで読み取る方法はありません — 実際の症状である、以下のCのOAuthトークンチェックで確認します。
2. CORSの許可済みオリジン — 次の両方のオリジンを含める必要があります。

   SELECT Id, UrlPattern FROM CorsWhitelistEntry
   

   https://teams.cloud.microsoft または https://cdn.scs.static.lightning.force.com がない場合 → 作成して（POST /sobjects/CorsWhitelistEntry {"UrlPattern":"<origin>"}）、ハードリフレッシュします。
3. ユーザーにAPI Enabledシステム権限を付与します（プロファイルだけではなく、権限セットを使用します）。

C. OAuthトークンの発行 — ポータルユーザーの決定的な確認

ポータル／UELのOAuth失敗とログイン失敗を切り分ける確認です。ユーザーが新規Teamsチャットから ログインを再試行した後に確認します。

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

• 失敗したユーザーのトークン行が存在する → OAuthは成功しています。問題はログインではなくエージェントのランタイムにあります — Eに進みます。
• 失敗したユーザーのトークンがないが、コミュニティのログインはSuccessと表示される（B） → OAuthの認可ステップでトークンが発行されていません。これは /<sitePrefix>/setup/secur/RemoteAccessAuthorizationPageに表示される「Service Not Available」ポップアップです。Dを確認します。

診断の手がかり（検証済み）： StandardプロファイルのユーザーはServiceCloudMSTeamsEca トークンを発行できるのに、UEL／ポータルユーザーは発行できない場合 — 権限セットが同一でも — 原因はポータルユーザーのOAuth認可パス（プロファイルのOAuthフラグ、またはコミュニティホストで表示されるセルフ承認ページ）であり、 ECAの権限付与ではありません。検証済みの組織では、StandardユーザーはSetupEntityAccess行が0件でも トークンを発行できた一方、すべての権限を持つUELユーザーは発行できませんでした。そのため、ECAの SetupEntityAccess設定ではこの違いを説明できません。

D. ポータルユーザーのOAuth認可（コミュニティホスト上のセルフ承認ページ）

ServiceCloudMSTeamsEca External Client AppはGoページのトグルによって自動インストールされ、設定は不要です — OAuthポリシーを変更したり、SetupEntityAccess行を追加したりしないでください。症状：Teamsのポップアップ「Service Not Available / An unexpected connection error occurred」が /<sitePrefix>/setup/secur/RemoteAccessAuthorizationPageに表示される、またはストリーミングエンドポイントでアクセスチェックエラーの本文 **{"acc":8}**が返されます。

この失敗はポータル／UEL固有であり、ECAの権限に関する問題ではありません（上記の診断の手がかりのとおり、StandardユーザーはSetupEntityAccess行が0件でもトークンを発行できます）。OAuth認可はコミュニティホスト（https://<org>.my.site.com/<prefix>/setup/secur/...）にルーティングされていますが、そこではセルフ承認ページを表示できません。My Domainにルーティングする必要があります。ECAはパッケージ化されたファーストパーティアプリです。OAuthポリシー、callbackUrl、isFirstPartyAppEnabled、oauthLinkを手動で編集しないでください。まず「Allow OAuth for employees」（B）とAPI Enabled（C）を確認します。それでもポータルトークンが発行されない場合は、ポップアップURLとaccコードがあればそれを記録し、Teams ITSM製品チームにエスカレーションしてください。設定変更で修正できる範囲を超えています。

E. 埋め込みAgentforceエージェントが参加後に退出する（返信なし）

ログインとOAuthは成功するものの、「Ask AI Agent」エージェントが返信しない場合は、 service-itsm-teams-employee-agent-configureに引き継ぎます。検証済みの修正は2つあります。（1）JWKS_URL Key Setに裏付けられた、Teams_AgentForceチャネルのユーザー検証をオンにすること。（2）ポータルユーザーのIT Service Employee Agentを有効にするAgent Access権限セットを付与することです。このスキルのリファレンスには、ランタイムチェーンの診断（scrt2トークン、SSE 401、ConversationEntryクエリ）がすべて記載されています。

---

関連スキル

スキル	代わりに使用する場合／併用する場合
service-itsm-teams-configure	Teams Salesforce Go ページの基本トグルの有効化、Azure／Entra アプリ登録、Named Credential の設定、Teams 拡張機能の登録を行う場合。このスキルの前提条件です
service-itsm-teams-itdesk-configure	チェックリストの IT Desk／フルフィラー側（IT Desk をオンにする、IT Desk アプリをインストールする、ユーザーアクセスを管理する、Swarming のコラボレーションツールとして Teams を設定する）
service-itsm-teams-employee-agent-configure	IT Service エージェントのセットアップの最終段階、つまり、埋め込み型の Agentforce エージェントが Teams カスタムクライアントで実際に返信できるようにする場合（Web チャネル、User Verification をオンにして JWKS_URL Key Set を設定、Teams_AgentForce をデプロイ、実際の Active エージェントにルーティングするフローを設定、Agent Access 権限セットを設定）。ステップ 4 の後に引き継ぎます
service-itsm-teams-debug	ログイン、機能の有効化、タブの読み込み、Agentforce、Swarming、SSO など、Teams ITSM のセットアップで発生するあらゆる問題の診断。問題を合否チェックリストに振り分け、修正方法を提示します
service-itsm-channels-coordinate	Teams、Slack、Swarming、Notifications、Portal を横断する最上位メニュー