• 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).

AskUserQuestion

• 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

sf

401

403

404

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.

sf api request rest ".../connect/setup/discovery/features/status" --method POST --body '{"featureApiNames":[...]}' --target-org <alias>

{items:[{apiName,status,enableBlockedReasons[],dependencyStatuses[]}]}

sf api request rest ".../connect/setup/discovery/feature/{apiName}/enable" --method POST --body '{}' --target-org <alias>

{success:boolean}

--body '{}'

sf api request rest

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.

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:
   bash

   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

   .

1. 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:
   bash

   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.

1. 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.

1. 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:
   bash

   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:
     bash

     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.

1. 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:
   bash

   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).

1. 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

   ):
   bash

   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.

• 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.