Service Itsm Agentic Setup Cmdb Discovery Configure

Enable CMDB Asset Discovery (Service Cloud ITSM)

Turns on Asset Discovery for CMDB by enabling the service-cloud-itsm-discovery-integration feature, then grants a user access to the Discovery page by assigning the IT Service Discovery Manager permission set (and its permission-set license). This is the final layer of CMDB setup — it runs only after the base CMDB feature is enabled, users have CMDB access, and the CMDB Foundation content bundle is installed. Every call runs through the Salesforce-hosted Headless-360 MCP server (server key headless-360) via its four meta-tools (discover, describe, dispatch_readonly, dispatch). The org is derived from the OAuth JWT bound to the current MCP session — the skill never handles an org id, alias, or credentials — so this works identically against production and sandbox with no per-user MCP install.

This skill covers the Discovery layer only — enabling the feature and granting Discovery page access to a user. The earlier CMDB layers are separate skills — see the end of this file.

Where this sits in the CMDB stack

CMDB is enabled in ordered layers, each gated on the prior one:

Layer 0  Org SKU / license      Org perm ITSrvcsCnfgMgmnt (verify only — no API can set it).
Layer 1  Tenant provisioning    CMDB tenant must reach status PROVISIONED (async).
Layer 2  CMDB feature           Enable service-cloud-itsm-cmdb-integration (lifts the 403 gate).
Layer 3  User access            Assign the PSL + CMDB permission sets to the user(s).
Layer 4  Content bundle         Install the CMDB Foundation (base) content bundle.
Layer 5  Asset Discovery        Enable service-cloud-itsm-discovery-integration + assign the
                                IT Service Discovery Manager permission set  ← THIS SKILL

Discovery is recommended last, but it does not require the base CMDB feature to already be on: the enable cascade-enables its dependency (the base CMDB feature) as part of turning Discovery on, provided that feature's own prerequisites (e.g. a provisioned CMDB tenant) are met. The enableBlockedReasons array in the pre-check is the authoritative blocker signal — a base CMDB feature that is merely NOT_ENABLED appears under dependencyStatuses with empty enableBlockedReasons and is not a blocker. So never tell the user a direct enable "will error out"; tell them it will turn on CMDB first, then Discovery. Only a non-empty enableBlockedReasons (e.g. tenant not provisioned) is a genuine unmet prerequisite that stops the enable.

Enabling the feature lifts the org-level gate; the Discovery permission set gives a user the Discovery page. This skill does both: it turns Discovery on for the org (Step 2) and then assigns the target user the license-backed `ItSrvcDscvrMgrPermissionSet` ("IT Service Discovery Manager", backed by PSL `ItSrvcDscvrMgrPsl`) so they can actually open and use the Discovery page (Steps 4–7). That permission set is distinct from the four Configuration-Item permission sets (Reader / Owner / Type Reader / Type Manager) that service-itsm-agentic-setup-cmdb-access-assign assigns for CMDB data — a user holding only those will not have Discovery page access. The assignment step is idempotent: if the user already holds the Discovery permission set and its license, it is skipped and reported as already-done.

Scope

• In scope: pre-checking, enabling, and verifying the service-cloud-itsm-discovery-integration feature; and — as a follow-up — assigning the IT Service Discovery Manager permission set (and its permission-set license) to the target user so they can access the Discovery page.
• Out of scope: enabling the base CMDB feature / provisioning the CMDB tenant (Layer 2 — service-itsm-agentic-setup-cmdb-configure), assigning the four Configuration-Item permission sets for CMDB data access (Layer 3 — service-itsm-agentic-setup-cmdb-access-assign), bundle installation (Layer 4 — service-itsm-agentic-setup-cmdb-bundle-deploy), CMDB record CRUD, Service Graph Connector configuration, identification rules, creating or editing permission sets.

Mechanism

All operations dispatch through headless-360 MCP tools. Reads go through mcp__headless-360__dispatch_readonly, writes through mcp__headless-360__dispatch — both take raw HTTP: {"url": "<path>", "method": "GET|POST", "body"?: {...}, "queryParams"?: {...}} — not {operation_id, arguments}. See references/mcp-invocation.md for the exact url / method / body of every call. The four tools:

• mcp__headless-360__discover — semantic search over the indexed operation catalog. The Setup/Connect routes and the /query / /sobjects/... REST routes this skill uses are not always ranked first (or indexed), so a miss does not mean the route is absent — dispatch the exact path directly (see references/mcp-invocation.md).
• mcp__headless-360__describe — pull the full input schema and canonical route before any POST.
• mcp__headless-360__dispatch_readonly — the dispatcher for every read (GET).
• mcp__headless-360__dispatch — the dispatcher for every write (POST/PATCH).

The skill never handles credentials — the org is bound to the current OAuth session. If a dispatch* call returns an auth error, tell the user to re-authenticate the headless-360 MCP connection (and confirm the session points at the intended org), then stop.

The Discovery permission set

Resolve the permission set's Id and its LicenseId at runtime (Step 5) rather than hardcoding IDs — IDs differ per org.

Clarifying questions

Ask only what you cannot infer from conversation:

• Which org? Confirm the target org and state plainly that this org will be modified (enabling the discovery feature is a write). For production, get explicit confirmation.
• Which user gets Discovery page access? The user to assign the IT Service Discovery Manager role. If the request is "enable discovery for me" / "set up discovery", default to the current (running) user. Accept a username/email for someone else.

Do not re-ask for anything the user already provided; pre-populate and note "(from conversation)".

Workflow

All steps are sequential and gated — do not advance past a failed check. Always read before you write: run the read-only pre-check before the enable, and the assignment checks before the assign.

Step 1 — Pre-check discovery feature status (read)

The feature api name is service-cloud-itsm-discovery-integration.

dispatch_readonly({ "url": "/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-discovery-integration/status", "method": "GET" })

• status == ENABLED → feature already on; skip to verification (Step 3), then proceed to the access follow-up (Steps 4–7).
• status == NOT_ENABLED with enableBlockedReasons: [] → clear to enable (Step 2). Before confirming, inspect `dependencyStatuses`: if the base CMDB feature (service-cloud-itsm-cmdb-integration) is listed there as NOT_ENABLED, that is not a blocker — enabling Discovery will cascade-enable the base CMDB feature first, then Discovery. Tell the user exactly that ("this will turn on CMDB first, then Asset Discovery"). Do not warn that it "will error out" or offer to "let it report the dependency error" — neither happens.
• enableBlockedReasons non-empty → STOP and relay each reason to the user in plain language. These are genuine unmet prerequisites the org still needs (e.g. the CMDB tenant is not provisioned,