Configure the "Set Up Salesforce IT Service" checklist for Microsoft Teams Employee Service (ITSM) — the employee side, covering app enablement, marketplace install guidance, user access assignment, and Digital Experience Site selection. Use this for: 'turn on Salesforce IT Service', 'set up IT Serv

Set Up Salesforce IT Service (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 . 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 the TeamsForEmployeeUser permission set 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. Workflow Step 1 — Turn on Salesforce IT Service 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: Expect 200 {"isPreferenceEnabled": true} . Tell the user it's enabled — do not ask them to flip the toggle themselves. Step 2 — Install Salesforce IT Service App on Teams (user's responsibility) 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): 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. Step 3 — Manage User Access "Manage User Access" ("Manage" button on the Go page) assigns the permission set — verified live from the "Manage Microsoft Teams for Employee Service User Access" dialog: TeamsForEmployeeUser (label "Teams for Employee" , backed by PSL TeamsForEmployeePsl ) 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: Who to assign — warn the user up front: the target must be a real employee / UEL user whose email exists on the Azure/Entra side (a Microsoft account in the same tenant). Login is SSO (MS UPN → the Salesforce Username ), so assigning it to a user with no matching Azure account — or a misaligned email/UPN — fails login silently (see the UPN↔ Username note above). State this before assigning; never assign system/integration accounts. Verified gotcha (spotting who NOT to pick): in scratch/test orgs the first page(s) are often dominated by non employee accounts — e.g. Automated Process , Bot User , Insights Integration , .ext integration users, ESW / Site Guest User guests, DigitalAgent. agents — none are employee/UEL users or have an Azure identity. Flag such rows as likely not employee (don't silently filter — call them out); if the user says "not employee users, skip," move to the next page. Once the user confirms specific user(s), look up the permission set's Id (it is stable per org but don't hardcode it — query fresh): Then assign the permission set to each confirmed user via PermissionSetAssignment (one record per user — batch with as many calls as needed, there is no bulk assign endpoint exposed here): Verify by re querying PermissionSetAssignment for that AssigneeId , or simply trust the 201 from the assignment call plus a SELECT ... FROM PermissionSetAssignment WHERE AssigneeId = '<user id ' AND PermissionSetId = '<permset id ' readback. Login prerequisites (required for the user to actually sign in to IT Service in Teams) Assigning the permission set 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: 1. "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). 2. 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. 3. "API Enabled" system permission on the user ( PermissionsApiEnabled = true ) via a permission set — not just the base profile — or the embedded app's API calls are rejected and the user can't sign in. Use the same org wide, created once permset IT Desk uses (commonly Teams Employee ApiAccess ): query PermissionSet WHERE Name = 'Teams Employee ApiAccess' , and if absent create it once ( POST /sobjects/PermissionSet {"Name":"Teams Employee ApiAccess","Label":"Teams Employee API Access","PermissionsApiEnabled":true} ); then assign. Don't create a duplicate. See service itsm teams itdesk configure 's Login prerequisite . 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]( troubleshooting teams for employee service login agent) below. Step 4 — Select a Digital Experience Site This checklist item ("Digital Experience Site Name" dropdown, currently "None" until set) 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 or Azure/Entra credential , so it works independently of the rest of the Teams setup. 1. List all Digital Experience sites in the org: If the org has no Digital Experience site yet (empty list), one must be created before this step can be completed — hand off to experience portal create to provision a new site (an employee service / IT support portal fits this use case), then return here with its Id . 2. 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. 3. Check the current value first (skip the write if already set to the chosen site's Id): stringValue holds the current selection — the chosen site's Id , or "None" . 4. Write the selection using the site's Id (from step 1's connect/communities response — the Network record Id, not urlPathPrefix ): 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. 5. Re run step 3's GET to confirm. Step 5 — Make the embedded Agentforce agent reply in 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. 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 in

service-itsm-teams-itservice-configure