Create and activate an IT Service Employee agent as a Next-Gen Authoring (NGA) native agent from an ITSM Employee agent template's Agent Script, via the Salesforce CLI (sf): read the template, check idempotency, create the NGA bundle then publish and activate, verify live. Defaults to the broad IT S

Create an IT Service Employee Agent (broad or specialized) Create and activate an IT Service Employee Agent as a Next Gen Authoring (NGA) native agent — Agent Script based ( AiAuthoringBundleDefVer /bundle), appearing natively in Agentforce Studio's Agents list with no external link icon — entirely through the Salesforce CLI ( sf ) . This skill does not call the legacy /connect/service itsm/createAgent ; instead it reuses a shipped ITSM Employee template's agentScript field and feeds it into the NGA bundle pipeline: POST /nextgen authoring/bundles → POST /nextgen authoring/bundle versions/{id}/publish → POST /nextgen authoring/bundle versions/{id}/activate . Commands: sf api request rest for Connect API GET/POST; sf data query for the SOQL idempotency + verify reads. GET /connect/service itsm/agent templates?agentType=AgentforceEmployeeAgent returns the broad IT Service Employee template plus ~47 specialized Employee templates under the svc emp intelligence namespace as siblings in data[] . Every specialized template ships the same agentScript shape with the same config.developer name / config.agent label substitution points, so the same NGA sequence works for any of them — only the masterLabel that Phases 1 and 4 pin against changes. Full catalog + namespace filter + disambiguation rules live in references/specialized templates.md . Helper scripts (invoked via Bash ) hold every JSON parsing / decision rule so the model never eyeballs a response body (A9): classify preflight.mjs , classify agent existence.mjs , build create body.mjs (HTML decodes + substitutes the template's agentScript and writes the body to a JSON file so large content and free text quotes never hit an inline shell string), render report.mjs (deterministic report renderer). Template selection (before Phase 1). Resolve the <masterLabel this run pins: (1) no specialization named ⇒ pin IT Service Employee (id svc emp intelligence ItEmployeeAssistance ) — the backwards compatible default; (2) user names a specialization ⇒ keyword match against references/specialized templates.md , single unambiguous match ⇒ pin that masterLabel and derive developerName from id after (snake cased); ambiguous ⇒ AskUserQuestion keyed on id ; (3) filter data[] to svc emp intelligence only — svc itsm intelligence (Fulfiller) redirects to service itsm agentic setup fulfiller agent configure , other namespaces are out of scope. The resolved <masterLabel is the single knob passed to classify preflight.mjs (Phase 1) and build create body.mjs (Phase 4). Prerequisites. Creation assumes the org level Agentforce for IT Service prerequisites are already satisfied (Agentforce Studio access + service cloud requestor agent + service cloud it service employee agent ). If Phase 1 detects Studio is not accessible — or if any write returns 403 FUNCTIONALITY NOT ENABLED — this skill offers to delegate to service itsm agentic setup agentforce studio validate (employee path) then resume; on "no", stops. This skill never enables features itself — enablement is a Setup UI/admin action. Scope In scope : Reading agent templates ; extracting an Employee template's Agent Script (broad default or a user named specialization from references/specialized templates.md — all under svc emp intelligence ); creating the Employee agent as an NGA native agent via createBundleWithVersion → publish → activate ; SOQL verifying live; idempotent skip on duplicate developer name — all via sf . Out of scope : The Fulfiller agent ( service itsm agentic setup fulfiller agent configure ); enabling org level feature toggles (validated by service itsm agentic setup agentforce studio validate ); low level topic/action authoring; perm set assignment; content bundle deployment; CMDB CRUD; Discovery / Service Graph; the legacy createAgent route; any data[] entry outside svc emp intelligence . Preconditions If any of these are unmet, sf surfaces an auth error or a 401 / 403 / 404 ; surface the raw error verbatim and stop — do not fabricate state . 1. sf CLI authenticated to the target org ( sf org display o <alias shows Connected). All calls use target org <alias ; never extract the access token by hand. 2. API v67.0+ — pinned in the URL path; do not hand edit below the minimum. 3. ITSM features + templates provisioned — resolved template must be present. If agent templates returns nothing or the routes 404, run service itsm agentic setup agentforce studio validate (agent path employee ). 4. node ≥ 18 on PATH. Operations at a glance Concern Command Notes Studio access (precondition read) sf api request rest "/services/data/v67.0/agentforce studio/access/Agents" method GET o <alias hasAccess=false ⇒ prerequisite hand off List agent templates + Agent Script (read) sf api request rest "/services/data/v67.0/connect/service itsm/agent templates?agentType=AgentforceEmployeeAgent" method GET o <alias agentType=AgentforceEmployeeAgent required; confirms resolved <masterLabel template + non empty agentScript Enumerate existing agent + latest version status (read) sf data query q "SELECT Id,DeveloperName,MasterLabel,AgentTemplate,(SELECT Id,Status FROM BotVersions ORDER BY VersionNumber DESC LIMIT 1) FROM BotDefinition WHERE Id='<botDefinitionId ' OR AgentTemplate='<agentTemplate ' OR DeveloperName='<developerName '" o <alias json Keyed PRIMARILY on the template's botDefinitionId (Phase 1 row); OR AgentTemplate= is the first fallback that catches the pre provisioned broad IT Service Employee agent by its OOTB namespaced source template ( svc emp intelligence ItEmployeeAssistance = Phase 1 template.id ) regardless of the collected DeveloperName guess; OR DeveloperName= is the last fallback for self created agents (null AgentTemplate ) and the guard for a dangling Id link (deleted target). Classified by scripts/classify agent existence.mjs ; Active latest ⇒ ALREADY CREATED; Inactive latest ⇒ offer reactivation Create the NGA bundle (write) sf api request rest "/services/data/v67.0/nextgen authoring/bundles" method POST body @<body file o <alias Body built by scripts/build create body.mjs ; response id = the bundle version Id Publish the bundle version (write) sf api request rest "/services/data/v67.0/nextgen authoring/bundle versions/<bundleVersionId /publish" method POST body '{}' o <alias Returns publishedBotId / publishedBotVersionId — creates the underlying BotDefinition / BotVersion Activate the bundle version (write) sf api request rest "/services/data/v67.0/nextgen authoring/bundle versions/<bundleVersionId /activate" method POST body '{}' o <alias Empty response on success; agent is now live and NGA native Activate an existing inactive version (write) sf api request rest "/services/data/v67.0/connect/bot versions/<latestVersionId /activation" method POST body '{"status":"Active"}' o <alias Reactivation path only (Phase 2b) — skips create/publish Verify agent is live (read) sf data query q "SELECT ... FROM BotDefinition WHERE Id='<verifyId '" o <alias json <verifyId = create path's publishedBotId (Phase 5) or the Phase 2 classifier's returned live matched Id (its botDefinitionId / agentId ) on ALREADY CREATED / reactivation — not the null Phase 1 template botDefinitionId , never the collected developerName; confirm BotDefinition present + latest version Active Full command shapes and the ITSM Connect API reference live in references/cli invocation.md ; the reactivation path call + idempotency verdict table live in references/reactivation.md ; the response body error codes and recurring gotchas live in references/error taxonomy.md . Never extract the access token. Use sf api request rest / sf data query directly — they use 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. json rule. sf data query takes json (results come back in a .result.records[] envelope — that's what the classifier expects). sf api request rest does not — omit json there; its raw stdout body is already JSON. Clarifying Questions Collect from the user (ask only what is not already in conversation context): Field Default Target org Default org ( sf config get target org ) Template ( masterLabel ) IT Service Employee (broad umbrella, id svc emp intelligence ItEmployeeAssistance ). If the user hints at a specialization (password manager, certificate, onboarding, hardware request, etc.), resolve via references/specialized templates.md ; ambiguous ⇒ AskUserQuestion keyed on id Developer name Broad: IT Service Employee Agent . Specialized: substring after in the picked id , snake cased (e.g. PasswordManagerAssistance → Password Manager Assistance ) Label Broad: IT Service Employee Agent . Specialized: the picked template's masterLabel verbatim (e.g. Password Manager Assistance ) Confirm the write REQUIRED — present resolved template + developerName + label, then require "yes" via AskUserQuestion The collected <masterLabel , <developerName , <label are threaded through every call — <masterLabel selects the row in agent templates.data[] (which also carries the botDefinitionId idempotency key); <developerName / <label are used in the createBundleWithVersion body (both outer apiName / label AND the substituted internal config.developer name / config.agent label ). The idempotency + verify reads key PRIMARILY on the template's botDefinitionId (or, after a fresh create, the publish response's publishedBotId ) and fall back to the BotDefinition's AgentTemplate (the OOTB source template = Phase 1 template.id ), then to the collected <developerName , when that is null. A hardcode/collect mismatch on the create body diverges the bundle's outer identity from the script's internal identity. Idempotency : keyed PRIMARILY on the template's botDefinitionId (Phase 1 agent templates row — the platform's authoritative template→ BotDefinition link), FALLING BACK first to the BotDefinition's AgentTemplate (the OOTB namespaced source template = Phase 1 template.id ) and then to the collected <developerName . The Phase 2 read is BotDefinition WHERE Id='<botDefinitionId ' OR AgentTemplate='<agentTemplate ' OR DeveloperName='<developerName ' (the OR AgentTemplate= half catches the broad pre provisioned agent by its platform stamped source template regardless of what DeveloperName it carries; the OR DeveloperName= half is both the last fallback for self created agents — whose AgentTemplate is null — AND the guard for a dangling Id link whose target BotDefinition was deleted), + latest BotVersion.Status . Outcomes: no match on any key ⇒ create; Active ⇒ ALREADY CREATED (skip write); Inactive ⇒ Phase 2b reactivation offer. Why the fallback keys: the broad agent ships pre provisioned as IT Service Employee ≠ the guess IT Service Employee Agent (a null botDefinitionId template row too), so neither the primary key nor the developerName guess catches it — its AgentTemplate ( svc emp intelligence ItEmployeeAssistance ) is the reliable, rename immune key that matches it; and for an agent this skill creates (which back fills neither botDefinitionId nor AgentTemplate ), the developerName fallback is what catches a repeat run. The server does reject a duplicate DeveloperName at publish (unique constraint → bundle cleanup), but only this read turns a repeat into a graceful skip instead of a DUPLICATE VALUE . Workflow Substitute <alias with the collected target org and <developerName / <l

service-itsm-agentic-setup-employee-agent-configure