Enable the Agentforce for IT Service Salesforce Go feature toggles (Agentforce Studio, Einstein Generative AI, the parent umbrella, and the Fulfiller/Employee agent templates) using the Salesforce CLI (sf). Turns ON org prefs via the Setup Discovery feature/{apiName}/enable Connect API route. Write-

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. Step Skill What it does 1. Validate service itsm agentic setup agentforce studio validate Read the toggles → READY / NOT READY (no writes) 2. Configure (this skill) service itsm agentic setup agentforce studio configure Turn the disabled toggles ON 3. Create agent service itsm agentic setup fulfiller agent configure Create + activate the Fulfiller agent 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 Operation Command Returns Read feature toggles sf api request rest ".../connect/setup/discovery/features/status" method POST body '{"featureApiNames":[...]}' target org <alias {items:[{apiName,status,enableBlockedReasons[],dependencyStatuses[]}]} Enable one toggle sf api request rest ".../connect/setup/discovery/feature/{apiName}/enable" method POST body '{}' target org <alias {success:boolean} — endpoint takes no meaningful body, but body '{}' must be passed explicitly (see gotchas) 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 Step What happens Tool used Pick path Determine fulfiller vs employee (ask if unclear) AskUserQuestion Read current state POST the feature status batch for the path's toggles, capture to a file Bash ( sf api request rest ) Plan Run scripts/classify enable plan.mjs <file <agentType [exitStatus] → dependency ordered pending list Bash ( node ) Confirm to write Present the exact pending list and require explicit "yes" AskUserQuestion Enable Re read + reclassify before each apiName in order , POST .../feature/{apiName}/enable when unblocked, record the result Bash ( sf api request rest + node scripts/record enable result.mjs ) Verify Re read /features/status , re run the classifier Bash ( sf + node ) Report Run scripts/classify final report.mjs over the before/results/after files → final verdict Bash ( node ) 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: 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: 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: 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: 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: 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 ): 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 Constraint Rationale Enable via POST /connect/setup/discovery/feature/{apiName}/enable only The IPCManagement updateOrgPref write allow list rejects the agent prefNames ( Invalid prefName ) — this is the only correct write path Read live per feature state from POST /features/status , never a flat catalog list Only /s

service-itsm-agentic-setup-agentforce-studio-configure