/education-cloud-student-recruitment-agent-configure

name: education-cloud-student-recruitment-agent-configure
description: "Use this skill to set up and configure the Education Cloud Student Recruitment Agent (SRA) — the packaged Agentforce agent (namespace sturecruitment) that answers admissions FAQs, captures inquiries, registers campus tours, and files applications for prospective students. TRIGGER when the user wants to: create or configure an admissions, recruitment, or enrollment agent, set up the Student Recruitment Agent, deploy SRA to an Experience Cloud site, clone the SRA flows or permission sets, add the SRA subagents (Admissions and Enrollments FAQ; Admissions Application; Campus Tours, Visits, and Events Registration; Request for Information), wire Learning Program grounding, or build the escalation subagent. Guides platform enablement, permissions, grounding, agent creation, and channel deployment — API-first with UI fallback. DO NOT TRIGGER for the Transfer Credit Agent, generic Agentforce authoring (use agentforce-generate), or base Education Cloud domain enablement."
metadata:
  version: "1.0"
  minApiVersion: "67.0"
  domains: ["Education"]
  relatedSkills:
    - "agentforce-generate"
    - "platform-custom-field-generate"
    - "platform-metadata-deploy"
    - "platform-sharing-owd-configure"
    - "platform-sharing-rules-generate"
  # Runtime tier 1 is the headless `dispatch`/`dispatch_readonly` MCP tools.
  # `sf` is the tier-2 fallback (MDAPI deploy + discovery/aggregate verifies) for
  # runtimes that have a shell. See the three-tier ladder in `references/execution-model.md`.
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"
  accessCheck:
    - type: "license"
      value: "Agentforce"
    - type: "orgPerm"
      value: "EinsteinForEducationCloud"

Configuring the Education Cloud Student Recruitment Agent

Scope

• **In scope**: The full SRA setup sequence — the three platform toggles (Einstein, SRA, Omni-Channel; Agentforce provisioning is a verify-only Step-1 gate, not a toggle the skill flips), the `EducationCloudAiAgentAccess` permission set + OWD/sharing foundation, Learning Program grounding (Data Cloud data stream + hybrid search index + prompt template) and Knowledge/data-library grounding, creating the Service (unauth) and Employee (auth) agents, adding the 4 packaged SRA subagents, building the customer escalation subagent, cloning and configuring the 6 admissions flows (Service path), and deploying to Experience Cloud channels with user verification.
• **Out of scope**: The **Transfer Credit Agent** (separate agent, own perms/help — never include its steps); generic Agentforce agent authoring from scratch (see Cross-Skill Integration below); Data Cloud connector plumbing beyond the SRA grounding path; deciding the substance of Knowledge article content — Claude may draft an article for the customer to review, but the customer owns what it says.
• **The EDU foundation is a checked dependency, not an assumption**: SRA depends on base Education Cloud enablement, Person Accounts, R&A domain objects, and Data Cloud. This skill doesn't re-implement base Education Cloud domain enablement, but verifies each piece concretely (step 2a) and only surfaces a gap to the user to *fill what it detects*.

---

Required Inputs

Gather or infer before starting:

• **Target org**: An Agentforce- and Education-Cloud-provisioned org with admin access — see Workflow step 1 for the gate.
• **Agent path(s)**: Unauthenticated (**Service** agent — the ASA, runs as the Einstein Agent User service account; no guest user), authenticated (**Employee** agent), or both.
• **Which subagents/topics** the customer wants live (default: all 4 packaged subagents + a custom escalation subagent).
• **Whether to add Create Inquiry to the Escalation subagent** (case-adjacent record creation on live-agent handoff) — ask if unspecified; the two outcomes are handoff-only, or handoff-plus-Create-Inquiry.

Defaults unless specified:

• Configure both agent paths if the org has both Service and Employee Agentforce licenses; otherwise the unauth/Service path only.
• Confirmation style: conversational, one-step-at-a-time — never autonomous. See *Talking to the user* below.

---

How this skill runs — read first

**Step 0 resolves the org's current API version; Step 1 is a hard prerequisites gate — clear both before touching anything else.** The rest is a linear, sequential set of steps (0–13); confirm before every irreversible or org-shaping action, and end every step with its verify call. (See *Talking to the user* below.)

**Every org-changing step walks a three-tier ladder, then verifies — tier = what runtime you have:** **T1** headless MCP (`dispatch`/`dispatch_readonly`, no shell) · **T2** `sf` CLI (needs a shell) · **T3** Setup UI. Try T1; drop to T2 on a route/allowlist failure; T3 if no shell. Steps carry a best-tier tag; the verify-only preflight (step 1) uses STOP/ASK-USER labels instead. `references/execution-model.md` has the ladder detail — allowlist, route signals, query-routing, API-version policy; read it whenever a tier or route is unclear.

**Several steps land on T3 with no tier-1/tier-2 write path at all** (hand the user the Setup path, then verify) — each is tagged inline where it occurs (e.g. `[T3 · ...]` on steps 8, 9a, 12); every other action has a tier-1 path.

---

Talking to the user — customer-facing narration (not optional)

**Mandatory, every run: read `references/customer-narration.md` in full before your first message to the customer — this is not background reading, it's the exact wording rules you follow at every step boundary for the entire session.** In short: the step numbers, tier tags (`T1`/`T2`/`T3`), and words like "gate," "the spine," or "per the doc" are internal authoring scaffolding — never say them to the customer, who has no idea this skill file exists. Lead every step boundary with the plain-language outcome, not the internal label; give a manual (UI) hand-off its complete concret