Enable Swarming for Employee Service (ITSM)
Enable the Salesforce Go feature "Swarming" (service-cloud-swarming) — the feature that
helps service reps pull in the right collaborators and subject-matter experts to resolve
incidents in real time. Every operation dispatches through headless-360.
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.
Scope
- In scope: Enabling the
service-cloud-swarmingGo feature via its feature-enablement Connect API; verifying feature state afterward; setting the "Select a Collaboration Tool" picklist (the API-level target of the "Set Teams as Collaboration Tool for Swarming" checklist item) toTeamsvia the org-values Connect API. - Out of scope: The base Microsoft Teams ITSM Salesforce Go page toggle (
ITSMTeamsEnabled) and Azure/Entra app registration — useservice-itsm-teams-configure(Swarming requires Teams to already be set up as a prerequisite, per the Go page). Notification-channel preferences (Notifications/TeamsNotifications) — a separate concern from this feature. Portal/site creation — useexperience-portal-create.
The problem this skill solves
"Set Teams as Collaboration Tool for Swarming" is one item in the "Set Up Salesforce IT Desk"
checklist on the Teams ITSM Go page (service-cloud-itsm-teams-integration's feature page) — but
it is gated behind a separate Go feature, service-cloud-swarming, which must be turned on
first. This skill is the dedicated place to turn Swarming on, so service-itsm-teams-configure
can delegate to it instead of duplicating feature-enablement logic.
Workflow
Step 1 — Check current feature status
Response shape:
Note: this endpoint is POST-only despite being a status read — a GET with queryParams
returns 405 METHOD_NOT_ALLOWED "Allowed are POST".
If status is already "ENABLED", skip to Step 3 (verification) — do not re-enable.
If enableBlockedReasons is non-empty, surface those reasons to the user before attempting Step 2.
Step 2 — Enable the feature
Verified live: returns 201 {"success":true} cleanly (unlike the Teams feature-enable, this call
did not exhibit the "500 that still succeeds" gotcha in testing — but re-check status afterward
regardless, since Go feature-enable calls can be flaky in general).
Step 3 — Verify
Expect status: "ENABLED".
Step 4 — Check current collaboration tool value
Response shape — exactly one of the four value fields is populated:
stringValue holds the current picklist selection: "None", "Slack", or "Teams". This is
the same Java enum-gated org-value endpoint family described in setup-connect-api's
get-org-value/update-org-value/verify-org-value-update steps — valueName must be the
literal Java enum constant name (SWARM_COLLABORATION_TOOL, SCREAMING_SNAKE_CASE), not a
camelCase guess like SwarmCollaborationTool.
If already "Teams", skip to Step 6 (report) — do not re-issue the write.
Step 5 — Set the collaboration tool to Teams
Verified live: returns 200 { "stringValue": "Teams", ... }. This is the API-level write behind
the Swarming Go feature page's "Select a Collaboration Tool" dropdown — the same control the
Teams ITSM Go page's "Set Teams as Collaboration Tool for Swarming" checklist item deep-links to
via its "Go to Feature Page" button. Valid orgValue strings are "None", "Slack", "Teams".
Re-run Step 4's GET afterward to confirm stringValue == "Teams".
Step 6 — Report to the user
Report both the service-cloud-swarming feature status and the SWARM_COLLABORATION_TOOL
value, confirming "Set Teams as Collaboration Tool for Swarming" is now fully automated —
enabling the feature is the prerequisite, and the org-value PATCH is the actual checklist-item
write.
Disabling (if requested)
Re-run Step 1 afterward to confirm.
To also reset the collaboration tool selection (optional — disabling the feature does not reset it automatically):


