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)

2. Run the classifier over the captured file to compute the dependency-ordered enable plan, saving its output — Phase 6 consumes this file, not the raw /features/status response:

   node "<skill_dir>/scripts/classify-enable-plan.mjs" /tmp/enable-status-before.json <agentType> "$(cat /tmp/enable-status-before.exit)" > /tmp/enable-plan-before.json
   

   It prints { agentType, readState, features, order, alreadyEnabled, pending, blocked, unconfirmed, verdict, reasons, rawError }. verdict: "ALL-ENABLED" means nothing to do — skip to Phase 6. verdict: "NEEDS-ENABLE" means pending (in order) lists what to enable. blocked lists any pending toggle whose enableBlockedReasons is non-empty as of this read — a toggle blocked only on an earlier dependency in order becomes enable-able once that dependency is on, so Phase 4 re-checks each toggle immediately before attempting it rather than trusting this snapshot for the whole loop. unconfirmed lists any required toggle missing from the response or carrying a status this classifier doesn't recognize — verdict: "CANNOT-CONFIRM" (not "ALL-ENABLED") when unconfirmed is non-empty and pending is empty. readState: "error" ⇒ surface rawError and stop; readState: "not-wired" ⇒ report CANNOT-CONFIRM and stop.

Phase 3 — Confirm-to-Write Checkpoint (REQUIRED)

3. Present the exact pending list (excluding anything in blocked) and require an explicit "yes" from the user via AskUserQuestion before proceeding. Enabling org prefs mutates org state. Proceed to Phase 4 ONLY on an explicit "yes". On "no", stop and report the current state without any writes.

Phase 4 — Enable (Dependencies First, Re-Checked Before Each Toggle)

4. Iterate order in sequence (Einstein GenAI → Studio → parent → child template(s)). Before attempting to enable each <apiName>, re-read and reclassify — this is what lets a child that was blocked in Phase 2 (only because Studio/parent was still off) become enable-able once that dependency's own enable has landed, instead of being permanently written off from the Phase-2 snapshot:

   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-loop.json 2>/tmp/enable-status-loop.err
   echo $? > /tmp/enable-status-loop.exit
   node "<skill_dir>/scripts/classify-enable-plan.mjs" /tmp/enable-status-loop.json <agentType> "$(cat /tmp/enable-status-loop.exit)"
   

   Inspect features["<apiName>"].signal from that output:

   • PASS → already ENABLED; nothing to do, move to the next apiName in order.

   • FAIL with an empty enableBlockedReasons → enable it now:

     sf api request rest "/services/data/v67.0/connect/setup/discovery/feature/<apiName>/enable" \
       --method POST \
       --body '{}' \
       --target-org <alias> > /tmp/enable-<apiName>.json 2>/tmp/enable-<apiName>.err
     node "<skill_dir>/scripts/record-enable-result.mjs" /tmp/enable-<apiName>.json <apiName> /tmp/enable-results.json
     

     The /enable endpoint itself takes no meaningful body, but sf api request rest --method POST with no --body flag at all fails with Error (SfError): No 'mode' found in 'body' entry — always pass --body '{}' explicitly. record-enable-result.mjs reads the response, classifies it ENABLED/FAILED, and accumulates it into /tmp/enable-results.json keyed by apiName — the deterministic per-toggle bookkeeping Phase 6 consumes.

   • FAIL with a non-empty enableBlockedReasons → still blocked even after this iteration's re-check (a real, not merely-sequential, blocker — e.g. unlicensed) — do not POST; move to the next apiName in order and let Phase 6 report the blocker verbatim.

   • CANNOT-CONFIRM / ERROR on this specific apiName's read → stop the loop and surface the read failure; do not guess at remaining toggles.

   One failed toggle does not block the rest of the plan — continue the loop.

Phase 5 — Verify Enablement

5. Re-run the Phase 1 read (same /tmp/feature-status-body.json) into a fresh file, and re-run the classifier over it, saving its output for Phase 6:

   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-after.json 2>/tmp/enable-status-after.err
   echo $? > /tmp/enable-status-after.exit
   node "<skill_dir>/scripts/classify-enable-plan.mjs" /tmp/enable-status-after.json <agentType> "$(cat /tmp/enable-status-after.exit)" > /tmp/enable-plan-after.json
   

   verdict: "ALL-ENABLED" ⇒ every toggle in order is confirmed ENABLED — success. Anything still in pending/blocked/unconfirmed needs Phase 6 to classify it precisely (FAILED vs CANNOT-CONFIRM).

Phase 6 — Aggregate Verdict (helper script)

6. Run the final aggregator over the Phase-2 classifier output (/tmp/enable-plan-before.json, not the raw /features/status response), the Phase-4 accumulated results (or - if Phase 2 was already ALL-ENABLED/CANNOT-CONFIRM/ERROR and Phase 4 never ran), and the Phase-5 classifier output (/tmp/enable-plan-after.json):

   node "<skill_dir>/scripts/classify-final-report.mjs" /tmp/enable-plan-before.json /tmp/enable-results.json /tmp/enable-plan-after.json
   

   It prints { features: { <apiName>: { finalStatus, reason } }, order, overall, reasons } where finalStatus is ALREADY-ENABLED | ENABLED | FAILED | CANNOT-CONFIRM | ERROR and overall is SUCCESS | PARTIAL | FAILED | CANNOT-CONFIRM | ERROR. Render this directly into the Output Format — do not re-derive the per-feature verdict or the overall summary in prose (authoring standard A9). On overall: "SUCCESS", point the user at service-itsm-agentic-setup-fulfiller-agent-configure (fulfiller) or service-itsm-agentic-setup-employee-agent-configure (employee) to proceed.

Rules / Constraints

Gotchas

Verification Checklist

• The agent path (fulfiller / employee) was determined (asked if unclear).
• Phase 1 read /features/status via sf api request rest, captured to a file, with its exit status captured.
• scripts/classify-enable-plan.mjs computed the pending (dependency-ordered), blocked, and unconfirmed lists before any write.
• The user explicitly confirmed the exact pending list at the Phase-3 checkpoint before any /enable POST.
• Phase 4 re-read and reclassified before each toggle, not once for the whole loop — so a child unblocked by an earlier dependency's enable was still attempted.
• Each attempted /enable POST's response was recorded via scripts/record-enable-result.mjs, accumulated across the loop.
• /features/status was re-read after enablement and the classifier re-run to confirm the final per-feature verdict.
• scripts/classify-final-report.mjs (not prose) computed the final per-feature status and overall summary from the before/results/after files; the access token was never extracted.

Output Format

Emit the report as live Markdown — never inside a code fence (a fenced table shows raw | pipes, not a table). This is Stage 1 (Foundation) that Stage 2 (install & activate the agent) builds on; each Status is ENABLED / ALREADY-ENABLED / FAILED / CANNOT-CONFIRM. Lay it out exactly like this:

Agentforce for IT Service — Stage 1: Enable Platform Features (via service-itsm-agentic-setup-agentforce-studio-configure)

• Org: <org-alias> (API v67.0)
• Agent path: fulfiller | employee

Verdict: SUCCESS | PARTIAL | FAILED | CANNOT-CONFIRM | ERROR

Next steps:

• If SUCCESS: "Stage 1 (foundation) complete — proceed to Stage 2: install + activate the <path> agent via service-itsm-agentic-setup-fulfiller-agent-configure (fulfiller) / the employee-agent skill."
• If PARTIAL/FAILED/CANNOT-CONFIRM/ERROR: list the affected toggle(s) + reason (enableBlockedReasons, unconfirmed status, or read error) + remediation steps

Substitute overall and each feature's finalStatus from scripts/classify-final-report.mjs into the <status> cells verbatim — do not recompute. No files are produced beyond the classifiers' temporary response captures.

Label rows exactly as the classifier emits them — never add Requestor, Specialized, or parent.

Reference File Index