Service Itsm Agentic Setup Agentforce Studio Validate

Validate Agentforce for IT Service Prerequisites

Readiness check for Agentforce for IT Service, for either the Fulfiller or the Employee agent path. Before an ITSM agent can be created, the org must have the right Salesforce Go feature toggles turned on (the ones on the Agentforce for IT Service setup page). This skill reads those toggles through the Salesforce CLI (`sf`) — a single authenticated Connect API call via sf api request rest — and a helper script classifies the chosen agent path into a READY / NOT-READY verdict.

This is the read-only step in a three-skill flow. It never enables anything; turning toggles on is a separate write-capable skill:

On NOT-READY this skill names each disabled toggle and hands off to service-itsm-agentic-setup-agentforce-studio-configure to enable them — it does not POST an enable itself.

The feature toggles and their real featureApiNames:

All are Connect API features (/connect/setup/discovery/...) — the read goes through sf api request rest, no Headless360 dispatcher required. The classification is deterministic and lives in scripts/classify-readiness.mjs (invoked via Bash), not in prose.

Scope

• In scope: Reading the Agentforce-for-IT-Service Go feature toggles via connect/setup/discovery/features/status; classifying the fulfiller or employee path into a per-feature + overall READY / NOT-READY verdict via a helper script; on NOT-READY, naming each disabled toggle and handing off to service-itsm-agentic-setup-agentforce-studio-configure to enable it.
• Out of scope: Enabling / turning on any toggle — that write is owned by service-itsm-agentic-setup-agentforce-studio-configure (this skill is read-only and never POSTs an enable); creating, committing, or activating an agent (handled by service-itsm-agentic-setup-fulfiller-agent-configure); the org-wide multi-agent orchestration toggle (that is a Headless360-only pref, not an ITSM Connect feature, and is not one of the setup-page toggles); assigning permission sets; CMDB CRUD.

Which path?

Determine whether the user is setting up the fulfiller agent (the IT-fulfiller-facing agent) or an employee agent (the employee-facing / NGA agent). If it is not clear from the request, ask (AskUserQuestion). The path selects which toggles are required:

• fulfiller → sales-cloud-agent-studio + service-cloud-agentforce-for-itsm + service-cloud-it-fulfiller-agent
• employee → sales-cloud-agent-studio + service-cloud-agentforce-for-itsm + service-cloud-requestor-agent + service-cloud-it-service-employee-agent

Preconditions

Before the skill can read anything, the CLI and target org must be configured. If any of these are unmet, sf surfaces an auth error or a 401/403/404; do not fabricate state — surface the raw error and stop.

1. `sf` CLI installed and authenticated to the target org (sf org display -o <alias> shows Connected). All calls use --target-org <alias>; never extract or pass the access token by hand.
2. API v67.0+: the connect/setup/discovery feature APIs are available at v67.0. The version is pinned in the URL path; do not hand-edit it below the minimum.
3. `node` ≥ 18 on PATH (runs the classifier script).

If a precondition fails, sf returns one of:

• Auth error / 401 Unauthorized → session expired or wrong alias; re-run sf org login web.
• 403 Forbidden → the user/org lacks the required access (missing Agentforce license).
• 404 Not Found → the feature-discovery surface is not wired on this org tier — the classifier maps a missing/error body to CANNOT-CONFIRM, not a hard failure.

Operations at a glance

This skill makes only the read above — it is read-only. Enabling a toggle (.../feature/{apiName}/enable) is out of scope: hand off to service-itsm-agentic-setup-agentforce-studio-configure. sf api request rest prints the raw response body (JSON) to stdout — capture it to a file and hand it to the classifier. Full command shapes and the error taxonomy live in references/cli-invocation.md.

Never extract the access token. Use sf api request rest directly — it uses the CLI's stored session for the target org. Do not pull the accessToken out of sf org display and hand-build an HTTP request with it; that bypasses the CLI session and leaks a bearer token into shell context.

Architecture — How the check works

The skill is read-only — it never enables a toggle.

Workflow

Substitute <alias> with the target org alias (ask the user, or use the default org from sf config). <agentType> is fulfiller or employee.

Phase 1 — Read the feature toggles

1. POST the feature-status batch for every toggle the chosen path needs (safe to always request all five — the classifier only judges the ones the path requires), capturing stdout to a file. Do not add --json:

   sf api request rest "/services/data/v67.0/connect/setup/discovery/features/status" \
     --method POST \
     --body '{"featureApiNames":["sales-cloud-agent-studio","service-cloud-agentforce-for-itsm","service-cloud-it-fulfiller-agent","service-cloud-requestor-agent","service-cloud-it-service-employee-agent"]}' \
     --target-org <alias> > /tmp/features-status.json 2>/tmp/features-status.err
   echo $? > /tmp/features-status.exit

Capture the command's exit status ($?) so the classifier can tell a confirmed 404 (gate not wired) apart from an auth/permission/transport failure. Do not swallow the exit with || true — pass it to the classifier in Phase 2.

Phase 2 — Classify (helper script)

1. Run the classifier over the captured file, the chosen agent type, and the captured exit status. Use the skill's absolute directory for the script path: