/education-cloud-domain-configure

name: education-cloud-domain-configure
description: "Use this skill to configure Education Cloud domains (Student Success, Recruitment & Admissions, Academic Operations, Alumni Relations, Student Management, or Mentoring) through conversational setup. Triggers when a user wants to enable or configure Education Cloud features. Guides step-by-step: enables Person Accounts prerequisite, activates target domain, then configures domain sub-features. Covers support processes, case record types, success teams, care plans, applications, admissions, course catalog, alumni engagement, fundraising, enrollment, programs, and mentoring. Explains each feature, confirms before proceeding, verifies every change took effect, and warns that domain and feature toggles are IRREVERSIBLE. DO NOT TRIGGER for metadata generation, custom objects, or package deployment — this configures existing platform features via org settings, not metadata files."
metadata:
  version: "1.1"
  minApiVersion: "60.0"
  domains:
    - "Education"
  cliTools:
    - tool: ["python3"]
      semver: ">=3.9.0"
    - tool: ["sf"]
      semver: ">=2.0.0"
  relatedSkills:
    - "platform-custom-field-generate"
    - "platform-custom-object-generate"
    - "platform-metadata-deploy"
    - "platform-permission-set-generate"
    - "platform-validation-rule-generate"
  accessCheck: "OrgPermissions.EducationCloud"

Configuring Education Cloud Domains

Guide users through conversational setup of Education Cloud domains. Enable Person Accounts prerequisite, activate target domain via Setup, and configure domain-specific sub-features with user confirmation at each step.

Scope

• **In scope**: Education Cloud domain configuration (Student Success, Recruitment & Admissions, Academic Operations, Alumni Relations, Student Management, Mentoring), Person Accounts enablement, sub-feature configuration, API-first with UI fallback
• **Out of scope**: Generating custom metadata or objects (delegate to `platform-custom-object-generate`), deploying managed packages, data migration, EDA (Education Data Architecture) configuration — native Education Cloud only

---

Required Inputs

Gather before starting:

• **Target domain**: Which Education Cloud domain to configure (Student Success, Recruitment & Admissions, Academic Operations, Alumni Relations, Student Management, or Mentoring)
• **Target org**: Active Salesforce org with admin access
• **Sub-features** (optional): Specific sub-features the user wants enabled within the domain

Defaults:

• Confirmation style: Ask before each step
• Error handling: Explain errors, suggest fixes, wait for user decision

---

Domain & Feature Toggle Write Path (authoritative)

Every domain/sub-feature toggle lives on the `IndustriesSettings` settings file (NOT Core's `ORG_PREFERENCES` allowlist) and is **IRREVERSIBLE** (`false → true` only — warn before flipping, never promise a revert). Write sequence is always **READ (tooling GET by DurableId) → WRITE (`PUT /services/data/v68.0/headless/metadata` via the write-enabled `dispatch` tool) → cold-VERIFY (repeat the GET — `success:true` alone is not proof)**. Read `references/toggle-write-path.md` before any toggle write for the full endpoint table, exact `xmlRep` shape, the `DurableId` constant, and the confirmed failure classes (silent no-op, cold-verify 500s, license-gating).

---

Authoring conventions

1. **Feature-first framing.** Lead with the FEATURE NAME and a plain-language description of what it does for the customer (e.g. "Enforce Time Conflicts — prevents learners registering for course offerings with conflicting schedules") — not the toggle's API element name (`enableCosConflicts`). Keep the element name only in the technical/API-call subsection. 2. **Describe before toggling.** For every feature and sub-feature, include a one-line "What it does" so the customer understands what's being enabled before confirming. 3. **List sub-features + confirm.** When a domain has sub-features, enumerate all of them and ask the customer to confirm or exclude before proceeding. 4. **Announce every C/U/D.** Before any create/update/delete, state the operation and offer approve / reject / modify. 5. **Flag manual steps.** If a step can't be done via API, note it as manual and surface it at the end of the domain's configuration. 6. **Always cold-verify.** `success:true` on a write is not proof. Re-read state (GET on the record or settings object) and confirm the intended field/element value.

---

Execution Transport

Before first call, probe transport health: `GET /services/data/vXX.X/limits` via headless-360 dispatch. 2xx → route all calls through it. On absent/4xx/5xx → probe other available transports (other Salesforce MCP, authenticated `sf` CLI, custom MCP) with the same read, use first healthy, announce it. None healthy → stop, ask user to connect one; never fabricate.

> **SOQL routes via headless-360 — pass the query through `queryParams`, NOT inline `?q=` in `url`** (inline 404s with `ROUTE_NOT_FOUND`). Call-shape detail: `references/gotchas-extended.md` ("Transport call shapes").

---

Setup Widgets

Five HXL widgets (`display_widget`: Intent, Review, Plan, Apply, Verify) visualize the workflow. Render each automatically at its checkpoint; never ask whether to show one. They are visual aids, never gates: if the host or org cannot paint them, continue in text. Compute every prop from live reads. A click on a row's action button (for example Enable) is the user's approval of that one item: no separate confirmation turn. Checkpoints, prop contracts, render call, and fallback: `references/setup-widgets.md`.

---

Workflow

Phase 0 — Foundation Prerequisites (Org-Level)

All Education Cloud domains require these foundation settings. Verify before proceeding to domain configuration.

> **Visual review.** After the Phase 0, 1, and 1.5 reads, render the 8 prerequisites once with `HxlSetupReview` (see Setup Widgets), then walk the pending items