Service Itsm Agentic Setup Agentforce Studio Configure

Enable Agentforce for IT Service Prerequisites

Enable the Agentforce for IT Service Salesforce Go feature toggles — Einstein Generative AI, Agentforce Studio, the parent umbrella, and the path-specific agent template (Fulfiller or Employee) — entirely through the Salesforce CLI (`sf`). These toggles are the prerequisites for creating the Fulfiller/Employee agent; this write-capable step turns them on via the Setup Discovery POST /connect/setup/discovery/feature/{apiName}/enable Connect API route. Each toggle is enabled idempotently (skipped if already ENABLED), dependencies are enabled first, and explicit confirmation is required before any write.

This skill is typically reached via hand-off from the validate skill's NOT-READY report, but can also be run directly.

A helper script — scripts/classify-enable-plan.mjs — reads the batched /features/status response and deterministically computes the dependency-ordered enable plan (before writing) and the final per-feature verdict (after writing). This mirrors the validate skill's classify-readiness.mjs contract (authoring standard A9): the decision logic lives in a script, not in prose.

Scope

• In scope: Enabling Einstein Generative AI (sales-cloud-einstein-generative-ai), Agentforce Studio (sales-cloud-agent-studio), the parent umbrella (service-cloud-agentforce-for-itsm), and the path-specific template (service-cloud-it-fulfiller-agent for fulfiller; service-cloud-requestor-agent + service-cloud-it-service-employee-agent for employee) via POST .../feature/{apiName}/enable; reading live per-org state from /features/status before and after each write; enabling dependencies first; confirming enablement stuck via re-query; surfacing an ENABLED / ALREADY-ENABLED / FAILED verdict per feature. Writes are idempotent — skip if already ENABLED.
• Out of scope: Provisioning Agentforce licenses (Setup > Company Information > Permission Set Licenses); assigning permission sets to users; creating, configuring, or activating an agent (service-itsm-agentic-setup-fulfiller-agent-configure); read-only prerequisite validation without writes (service-itsm-agentic-setup-agentforce-studio-validate); the org-wide multi-agent orchestration toggle (a Headless360-only pref, not a Connect feature).

Which path?

Determine whether the user is enabling prerequisites for the fulfiller agent or an employee agent. If unclear, ask (AskUserQuestion) — same path selection the validate skill uses:

• fulfiller → sales-cloud-einstein-generative-ai → sales-cloud-agent-studio → service-cloud-agentforce-for-itsm → service-cloud-it-fulfiller-agent
• employee → sales-cloud-einstein-generative-ai → sales-cloud-agent-studio → service-cloud-agentforce-for-itsm → service-cloud-requestor-agent → service-cloud-it-service-employee-agent

Einstein Generative AI is a dependency of Agentforce Studio and is not one of the toggles the validate skill reports on directly, but it must be enabled first if it is off — the classifier includes it in the enable plan for both paths.

Preconditions

Same as the validate skill (they share the target org and API surface). If 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).
4. Agentforce license on the org (accessCheck) — a missing license surfaces as 403 or as enableBlockedReasons on the read.

Operations at a glance

Both are Connect API routes reachable via sf api request rest — no Headless360 dispatcher required. Full command shapes, the response envelope, 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.

CRITICAL: DO NOT use IPCManagement `updateOrgPref` to flip agent prefs. That controller's write allow-list rejects the agent prefNames (Invalid prefName, 500). The Setup Discovery POST /feature/{apiName}/enable endpoint is the only correct write path for these toggles.

Architecture — How enablement works

Workflow

Substitute <alias> with the target org alias. <agentType> is fulfiller or employee.

Phase 1 — Read Current State

1. POST the feature-status batch for every toggle the chosen path needs, capturing stdout to a file. Do not add --json. Write the request body once to a temp file and reuse it verbatim in Phases 1, 4, and 5 via --body "$(cat ...)" — never retype it, substitute a placeholder like [...], or rely on a shell variable, since each Bash invocation may run in a fresh shell where a plain variable would be unset:

   cat > /tmp/feature-status-body.json <<'EOF'
   {"featureApiNames":["sales-cloud-einstein-generative-ai","sales-cloud-agent-studio","service-cloud-agentforce-for-itsm","service-cloud-it-fulfiller-agent","service-cloud-requestor-agent","service-cloud-it-service-employee-agent"]}
   EOF

   sf api request rest "/services/data/v67.0/connect/setup/discovery/features/status" \
     --method POST \
     --body "$(cat /tmp/feature-status-body.json)" \
     --target-org <alias> > /tmp/enable-status-before.json 2>/tmp/enable-status-before.err
   echo $? > /tmp/enable-status-before.exit

Capture the exit status — do not swallow it with || true.

Phase 2 — Plan (helper script)