@salesforce/afv-skills 1.47.0 → 1.48.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@salesforce/afv-skills",
-  "version": "1.47.0",
+  "version": "1.48.0",
   "description": "Salesforce skills for Agentforce Vibes",
   "license": "CC-BY-NC-4.0",
   "files": [

package/skills/education-cloud-domain-configure/SKILL.md

@@ -0,0 +1,234 @@
+---
+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.0"
+  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:
+    - type: "license"
+      value: "Education Cloud"
+---
+
+# 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`.** `GET /services/data/vXX.0/query` (or `/tooling/query`) with `queryParams: {"q": "SELECT ..."}` returns records normally; putting `?q=...` directly in the `url` string 404s (`ROUTE_NOT_FOUND`) — a call-shape mistake, not a platform limitation. `?fields=` on a plain sObject GET is still not supported (router treats it as an external-id path segment) — use `/describe` for field lists instead. Prefer a direct SOQL existence/Id lookup over asking the user to supply a record Id; where no REST route exists at all (license/permission provisioning UI-only), ask the user or confirm in Setup UI.
+
+---
+
+## Workflow
+
+### Phase 0 — Foundation Prerequisites (Org-Level)
+
+All Education Cloud domains require these foundation settings. Verify before proceeding to domain configuration.
+
+1. **Check org edition** — query `GET /services/data/v68.0/query` with `queryParams: {"q": "SELECT OrganizationType FROM Organization"}` (singleton, no Id needed), then pipe the record into `scripts/check_org_edition.py --allowed "Enterprise Edition,Performance Edition,Unlimited Edition,Developer Edition"` (stdin: `{"records": [...]}`). `eligible: false` → warn user Education Cloud requires Enterprise+ edition.
+
+2. **Check Lightning Experience** — verify Lightning Experience is enabled. If not enabled, instruct user to navigate to Setup → User Interface → Enable Lightning Experience.
+
+3. **Check Education Cloud license** — permission set names vary by org/release (neither of two confirmed orgs shipped `EducationCloudUser`; look for `%EducationCloud%` matches instead). Query `GET /services/data/v68.0/query` with `queryParams: {"q": "SELECT Id, Name FROM PermissionSet WHERE Name LIKE '%EducationCloud%'"}` and `GET /services/data/v68.0/sobjects/BusinessProfile/describe` (capture `createable`, or `null` if it 404'd), then pipe both into `scripts/check_license_provisioned.py` (stdin: `{"permissionSets": [...], "businessProfileDescribe": {...}}`). `provisioned: false` → not provisioned, tell the user and stop. `provisioned: true` with empty `matchingPermissionSets` → treat as provisioned but note the mismatch.
+
+4. **Assign Education Cloud Full Access** — resolve the running user's Id (ask for their username if unknown), query `GET /services/data/v68.0/query` with `queryParams: {"q": "SELECT Id, PermissionSet.Name FROM PermissionSetAssignment WHERE AssigneeId='<running user Id>' AND PermissionSet.Name LIKE '%EducationCloud%'"}`, and pipe the result into `scripts/check_permission_assigned.py` (stdin: `{"records": [...]}`). `assigned: false` → instruct user to assign the org's actual permission set (from step 3's `matchingPermissionSets`) via Setup → Permission Sets → Manage Assignments.
+
+   > **No Bash tool available on this surface?** These scripts are local data transforms only — no org call, no credentials. Perform the equivalent comparison inline instead of skipping the check.
+
+5. **Enable Education Cloud Foundation** — **IRREVERSIBLE — warn the user before flipping; do NOT promise a revert.** This does NOT go through the metadata PUT path (confirmed silent no-op on `enableEducationCloud`) — it needs the dedicated invoke endpoint. Read `references/toggle-write-path.md` ("Enabling the foundation") for the READ → WRITE → cold-VERIFY sequence and the UI fallback. Proceed to step 6 once cold-verify shows `true`.
+
+### Phase 1 — Enable Person Accounts
+
+6. **Confirm domain choice** — ask user which domain to configure if not already specified. Present list:
+   - Student Success
+   - Recruitment & Admissions
+   - Academic Operations
+   - Alumni Relations
+   - Student Management
+   - Mentoring
+
+7. **Explain Person Accounts** — explain: "Person Accounts are required for Education Cloud. They allow individuals (students, applicants, alumni) to be tracked as both Accounts and Contacts in a unified record."
+
+   > **WARNING**: Person Accounts cannot be disabled once enabled. Confirm user understands this is irreversible before proceeding.
+
+8. **Enable Person Accounts (UI)** — Person Accounts has no supported org-preferences write API (the `setup/org/preferences/{name}` endpoint returns 404). Instruct user to navigate to Setup → Quick Find → "Account Settings" → Select Account Settings → Turn on "Enable Person Accounts" → Click Save. Wait for user confirmation toggle is ON and saved, then proceed to Phase 1.5.
+
+    To verify: `GET /services/data/v68.0/sobjects/Account/describe` and confirm `IsPersonAccount`/`Person*` fields are present in the `fields` array; if headless routing is unavailable, fall back to `sf sobject describe -s Account` and grep for the same. This describe call is the ONLY valid verification method — do NOT run any SOQL query against `IsPersonAccount` or Person-Account fields (on `Account`, `Organization`, or any object) to check enablement status; SOQL on an unrecognized field returns `INVALID_FIELD`/"No such column", and that failure does NOT mean Person Accounts is off — it means you used the wrong check.
+
+### Phase 1.5 — Setup Basics: Dependent Features & Data Space Mapping
+
+This mirrors Setup's own "Setup Basics" grouping (Person Accounts, Dependent Features, Data Space Mapping) that sits before the domain sections. Several dependent features are referenced by more than one domain's sub-features, so configuring them here avoids re-discovering them mid-domain.
+
+9. **Present Dependent Features** — read `references/dependent-features.md` and present the full list to the user, grouped by category (confirmed API toggle / manual-UI-only / untested), leading with feature name + one-line "what it does", not the API element name. **Always present this list and ask which to enable now**, even if the user declines all of them — record that decision explicitly and proceed to Phase 2 rather than skipping the step. Anything declined can be revisited later.
+
+10. **Configure each selected Dependent Feature** — `references/dependent-features.md` categorizes every feature into one of four shapes; look up the selected feature there for its exact element names, DurableIds, and gotchas:
+    - **Confirmed `IndustriesSettings` toggle** — IRREVERSIBLE, warn user. Use the **Domain & Feature Toggle Write Path**: READ → WRITE (`PUT /services/data/v68.0/headless/metadata`) → cold-VERIFY.
+    - **Confirmed toggle via a different mechanism** (e.g. Einstein Generative AI master toggle) — a Setup-Connect **org preference**, not `IndustriesSettings`: `GET /services/data/v68.0/setup/org/preferences/<PrefName>` → `PATCH` same path with `{"desiredState": true|false}` → cold-VERIFY. Some of these are reversible — check the reference before assuming one-way.
+    - **Overlaps a domain sub-feature** (several toggles are shared with Student Success and/or Mentoring sub-features) — cold-read first; if already `true` from a prior domain's configuration, report as already enabled rather than re-writing.
+    - **Manual UI only, no API route** — instruct user to the Setup path in the reference. Flag where a custom permission set / object permissions are also required, not just a toggle — surface as manual follow-up.
+
+11. **Enable OmniStudio** — OmniStudio is included with Education Cloud license. Attempt API call or instruct user to navigate to Setup → OmniStudio Settings → Enable.
+
+12. **Enable Business Rules Engine** — Business Rules Engine is included with Education Cloud license. Instruct user to navigate to Setup → Business Rules Engine → Enable.
+
+13. **Data Space Mapping** — via the `DataSpaceFeatureMappings` Setup Operation Recipe (`/headless/invoke/platform/data-space-feature-mappings`). Unlike most toggles in this skill, it's **reversible** (delete supported). Full pre-flight/READ/WRITE/cold-VERIFY/undo sequence, valid feature values, and status-code handling are in `references/dependent-features.md` ("Data Space Mapping" section). If the pre-flight check fails or any invoke call errors, fall back to manual UI (Setup → "Set Up Education Cloud" → Data Space Mapping).
+
+### Phase 2 — Enable Target Domain
+
+14. **Explain domain purpose** — look up the selected domain in `references/domain-features.md`'s index and open the linked per-domain file (e.g. `references/domain-features/student-success.md`) to explain to user what the domain provides, including prerequisites.
+
+15. **Check domain-specific prerequisites** — beyond OmniStudio/Business Rules Engine (already enabled in Phase 0), most domains need an added license: Experience Cloud (Recruitment & Admissions, Mentoring, and portals generally), Salesforce Scheduler (Student Success, Recruitment & Admissions), Fundraising (Alumni Relations, if using gift management), or a prior domain (Student Management requires Academic Operations already configured). See the selected domain's file under `references/domain-features/` for the full list. If prerequisites are missing, warn user and ask whether to continue with available features or provision prerequisites first.
+
+16. **Confirm domain enablement** — **IRREVERSIBLE — one-way by design (`false → true` only).** Warn the user explicitly and do NOT promise a revert/rollback. Ask: "Ready to enable [Domain Name]? This activates domain-specific objects, fields, and setup features and CANNOT be turned off afterward."
+
+17. **Enable the domain toggle** — each domain is an `enableXXX` field on `IndustriesSettings`. Follow the **Domain & Feature Toggle Write Path**: READ (tooling GET via DurableId) → WRITE (`PUT /services/data/v68.0/headless/metadata` with the single `<enableXXX>true</enableXXX>` element in `xmlRep`, via the `dispatch` write tool) → VERIFY (tooling GET shows `true`).
+
+    Toggle field per domain:
+
+    | Domain | `IndustriesSettings` field |
+    |--------|----------------------------|
+    | Student Success | `enableStudentSuccess` |
+    | Academic Operations | `enableAcademicOperations` |
+    | Mentoring | `enableMentoring` |
+    | Alumni Relations | `enableAlumniRelations` |
+    | Recruitment & Admissions | **No master toggle** — configured via 2 independent sub-feature settings (`enableApplnDecStdSharing`, `enableAppMaterialsProtection`); skip this step, go to `references/domain-features/recruitment-admissions.md` "Enablement & Toggles" |
+    | Student Management | `enableStudentManagement` |
+
+    On success (`200 { success: true }`, synchronous, no polling), proceed to step 18. On failure, instruct user to navigate to Setup → "Set Up Education Cloud" → the domain section (e.g., "Set Up the Student Success App") → turn on the domain toggle → Save, and wait for confirmation.
+
+18. **Verify domain active** — the step-17 cold-verify (`Is<Domain>Enabled` = `true`) already confirms the toggle. To confirm object provisioning, `GET /services/data/v68.0/sobjects/CaseTeamTemplate/describe`: 200 means the object exists (domain active); 404/NOT_FOUND → wait 1-2 minutes for async provisioning and retry. A SOQL `SELECT count() FROM <Object>` via `queryParams` also works.
+
+### Phase 3 — Configure Sub-Features
+
+19. **Read sub-feature reference** — load the selected domain's file under `references/domain-features/` to identify available sub-features and their detailed setup steps.
+
+20. **Present sub-feature options** — list the sub-features available for the domain (per the domain's `references/domain-features/` file) and ask user which to configure. Student Success has a required execution order (Support Process → Case Record Types → Success Teams → Care Plans → Support Programs → Salesforce Scheduler → consoles/portal); the other domains' sub-features are independent of each other.
+
+21. **Configure each selected sub-feature** — explain what it does, warn if irreversible, confirm with user, then follow the exact setup path in the domain's `references/domain-features/` file (covers all five shapes: record creation via Data/Tooling API, `IndustriesSettings` toggles via the Toggle Write Path, app/console setup, Experience Cloud portal setup, OmniStudio activation — with endpoints, body shapes, gotchas, and verification per sub-feature). Toggles follow the same IRREVERSIBLE + READ→WRITE→cold-VERIFY rule as domain toggles; cold-read first if already set from Phase 1.5. On API failure, fall back to the Setup UI path in the reference.
+
+22. **Summary** — after all sub-features configured, list what was enabled via which method (API, UI, OmniStudio). Report any failures or manual steps required. If suggesting next steps, limit them to genuine blockers/dependencies actually surfaced during this session (e.g. a prerequisite that's still off, a sub-feature the user asked about but deferred) — not a generic list of every related feature or domain regardless of relevance.
+
+---
+
+## Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Foundation, Person Accounts, OmniStudio, and Business Rules Engine must be enabled before any domain | Domains depend on these foundation objects/settings, and on OmniStudio/BRE for portal components and policy rules |
+| Always confirm with user before each step and explain what a feature does first | Conversational workflow pattern — no commands without explicit user approval or understanding |
+| Wait for user confirmation after UI fallback steps, and cold-verify after every enablement | Never assume success — re-read state (tooling GET, describe, record GET, or `SELECT ...` via `queryParams`) |
+| Check domain-specific prerequisites before domain enablement | Some domains need added licenses or a prior domain already configured |
+| Use the `scripts/` helpers for Phase 0 checks, not inline prose logic | Deterministic, fast, no org call/credentials — run the equivalent comparison inline only if no Bash tool is available |
+
+---
+
+## Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| Education Cloud license not provisioned | Contact Salesforce account team to provision the license before proceeding |
+| Person Accounts, Education Cloud Foundation, and domain toggles cannot be disabled once ON | Warn user before attempting enablement — this is a one-way operation |
+| `setup/org/preferences/{name}` returns 404 for EDU toggles | Not in the ORG_PREFERENCES allowlist — write via `PUT /services/data/v68.0/headless/metadata` instead |
+| Tooling sObject `PATCH` on `IndustriesSettings` returns 400 `JSON_PARSER_ERROR` | complexvalue fields reject PATCH — use the headless metadata PUT path; tooling GET is for read/verify only |
+| Tooling GET needs the real `DurableId`, not `000000000000000AAA` | Query `SELECT Id,DurableId FROM IndustriesSettings` first |
+| Domain/sub-feature enablement may take 1-2 minutes to propagate | If verification returns nothing right after the API call, wait 2-3 minutes and retry |
+
+See `references/toggle-write-path.md` for the AURA-IS-CANONICAL silent no-op, cold-verify 500, and license-gating failure classes, and `references/gotchas-extended.md` for lower-frequency gotchas.
+
+---
+
+## Final Verification Checklist (Irreversible Writes)
+
+Before reporting any of the following as complete, confirm both boxes for that write:
+
+- [ ] **Education Cloud Foundation** — user was warned it cannot be turned off, and cold-verify (`educationCloudEnabled: true` on a fresh read) passed after enabling.
+- [ ] **Person Accounts** — user was warned it cannot be disabled once enabled, and `Account` describe confirms `IsPersonAccount`/`Person*` fields are present.
+- [ ] **Each domain toggle enabled this session** — user confirmed "cannot be turned off afterward" before the write, and the tooling GET cold-verify shows `Is<Domain>Enabled: true`. (Object-describe in step 18 confirms object provisioning only — not a substitute for this cold-verify.)
+- [ ] **Each irreversible sub-feature/dependent-feature toggle enabled this session** — user confirmed before the write, and cold-verify shows the field is `true`.
+
+Do not include a feature in the final summary as "enabled" unless both its approval and cold-verify boxes are checked.
+
+---
+
+## Output Expectations
+
+This skill produces no files — configuration happens via Setup navigation, CLI commands, or API calls. Expected outputs: conversational confirmation after each step, verification results showing configuration is active, error messages with suggested fixes on failure, and a final summary listing all configured features.
+
+---
+
+## Cross-Skill Integration
+
+| Need | Delegate to |
+|------|-------------|
+| Create custom objects for Education Cloud | `platform-custom-object-generate` |
+| Create custom fields on Education Cloud objects | `platform-custom-field-generate` |
+| Generate validation rules | `platform-validation-rule-generate` |
+| Configure permission sets | `platform-permission-set-generate` |
+| Deploy metadata packages | `platform-metadata-deploy` |
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `references/domain-features.md` | Index of per-domain reference files — start here to find the right file for the selected domain |
+| `references/domain-features/<domain>.md` | Phase 2 step 14 (explain domain purpose), Phase 3 step 19 (identify sub-features), Phase 3 step 21 (sub-feature configuration setup paths and API preference names) |
+| `references/dependent-features.md` | Phase 1.5 steps 11-12 (Setup Basics — present and configure Dependent Features before any domain), and whenever the user asks about a cross-product feature not owned by one domain — surface as "Set Up Dependent Features" and note domain overlap where relevant |
+| `references/gotchas-extended.md` | When an error doesn't match one of the 10 entries in the Gotchas table above |
+| `scripts/check_org_edition.py` | Phase 0 step 1 (org edition check) |
+| `scripts/check_license_provisioned.py` | Phase 0 step 3 (Education Cloud license check) |
+| `scripts/check_permission_assigned.py` | Phase 0 step 4 (Education Cloud Full Access assignment check) |

package/skills/education-cloud-domain-configure/references/dependent-features.md

@@ -0,0 +1,198 @@
+# Set Up Dependent Features — Cross-Product Toggles
+
+"Set Up Dependent Features" in Setup → Set Up Education Cloud enables and configures cross-product features that make the most of Education Cloud. These are **not owned by a single domain** — some overlap with sub-features referenced in the per-domain files under `domain-features/` (noted per feature below). Present these to the customer as their own group, separate from the 6 domains, but cross-reference domain overlap when relevant.
+
+This is part of Setup's own "Setup Basics" grouping (Person Accounts → Dependent Features → Data Space Mapping) that sits before the domain sections. Configuring Dependent Features is **recommended, not required**, before enabling a domain — **always ask the user which of these they want enabled**, since most are optional and several only matter once a specific domain sub-feature needs them.
+
+Same method as everywhere else in this skill: READ (tooling GET by `DurableId`) → WRITE (`PUT /services/data/v68.0/headless/metadata`, via the write-enabled `dispatch` tool) → cold-VERIFY (repeat GET — `success:true` alone is not proof).
+
+---
+
+## Clean wins — `IndustriesSettings`, first-try, no gotcha
+
+Same object/DurableId as domain toggles (`IndustriesSettings`, DurableId `bWRjLzBIRS9JbmR1c3RyaWVzU2V0dGluZ3M=`, `fullName: Industries`). IRREVERSIBLE — warn before flipping.
+
+| Feature | What it does | Metadata element | Flat read field | Notes |
+|---------|---------------|-------------------|------------------|-------|
+| Care Plans | Lets staff create structured plans (goals, tasks, barriers) to support a student's wellbeing or case, tracking progress over time | `enableCarePlansPreference` (NOT `enableCarePlans` → `FIELD_INTEGRITY_EXCEPTION`) | `IsCarePlansPreferenceEnabled` | Same toggle as Student Success Step 4 (`domain-features/student-success.md`) — run AFTER Success Teams, BEFORE Support Programs per executed order |
+| Case Proceedings | Manages formal hearings/proceedings tied to a case (e.g., disciplinary hearings), tracking participants, decisions, and outcomes | `enableCaseProceedingsPref` | `IsCaseProceedingsPrefEnabled` | Overlaps Student Success case workflows |
+| Case Referral | Lets staff refer a case/student to another team, department, or service provider for additional support | `enableCaseReferralPref` | `IsCaseReferralPrefEnabled` | Overlaps Student Success case workflows |
+| Einstein Academic Insights | AI-driven insights (built on Data Cloud) highlighting academic risk factors or trends for students, helping advisors intervene early | `enableAcademicInsightsAI` | `IsAcademicInsightsAiEnabled` | License-gated (Einstein GenAI) — write succeeds regardless of license; feature itself won't function without the license |
+| Einstein Advising Summary | Uses generative AI to summarize a student's advising history/interactions so advisors get up to speed quickly | `enableAdvisingSummaryAI` | `IsAdvisingSummaryAiEnabled` | Overlaps Student Success (Advisor Console); license-gated same as above |
+| Turn On Record Alert Access | Displays contextual alerts/banners on records (e.g., "Student on academic probation") to flag important info to staff | `enableRecordAlertCustomSharingPref` | `IsRecordAlertCustomSharingPrefEnabled` | Overlaps Student Success Performance Alerts |
+| Program and Benefit Management (4 toggles) | Manages enrollment in programs and benefits (e.g., financial aid, services), including eligibility and assignment | `enableBenefitManagementPreference`, `enableBenefitAndGoalSharingPref`, `allowBenefitAssignmentWithInactiveProgramEnrollment`, `enableProgramCohorts` | `IsBenefitManagementPreferenceEnabled`, `IsBenefitAndGoalSharingPrefEnabled`, `AllowBenefitAssignmentWithInactiveProgramEnrollment`, `IsProgramCohortsEnabled` | Same 4 toggles as Student Success "Support Programs" (`domain-features/student-success.md` Step 5) and Mentoring "Set Up Mentoring Programs" (`domain-features/mentoring.md` Step 2) — idempotent, cold-read first and skip any already `true` |
+| Salesforce Scheduler for Education Cloud (org prefs only) | Lets students/staff book appointments (advising, tutoring) directly with the right staff member based on availability | `enableEventManagementOrgPref`, `enableShareSaWithArOrgPref` | `IsEventManagementOrgPrefEnabled`, `IsShareSaWithArOrgPrefEnabled` | **Partial** — same 2 API-writable prefs as Student Success Scheduler step (`domain-features/student-success.md` Step 6); the Scheduler master enable itself is license-gated (Field Service) and manual/UI only |
+
+**API call** (one PUT can flip several at once):
+```http
+PUT /services/data/v68.0/headless/metadata
+```
+```json
+{
+  "type": "IndustriesSettings",
+  "fullName": "Industries",
+  "xmlRep": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><IndustriesSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><enableCaseProceedingsPref>true</enableCaseProceedingsPref><enableCaseReferralPref>true</enableCaseReferralPref><enableAcademicInsightsAI>true</enableAcademicInsightsAI><enableAdvisingSummaryAI>true</enableAdvisingSummaryAI><enableRecordAlertCustomSharingPref>true</enableRecordAlertCustomSharingPref></IndustriesSettings>"
+}
+```
+
+**Verification** (cold read): `GET /services/data/v68.0/tooling/sobjects/IndustriesSettings/bWRjLzBIRS9JbmR1c3RyaWVzU2V0dGluZ3M=` — confirm each `.Metadata.<element>` and its flat `Is*Enabled` read `true`.
+
+---
+
+## Different sObject — own `DurableId`/`fullName`, not `IndustriesSettings`
+
+These live on their own settings sObjects. Same PUT/GET shape, but different `type`, `fullName`, and `DurableId` — do not use the `IndustriesSettings` DurableId for these.
+
+### Checklist Items w/ Attachments — `DocumentChecklistSettings`
+
+- **What it does**: lets staff define required documents/items for a process (e.g., admissions) and track submission status, including attachments per checklist item.
+- **Setup label**: Checklist Items w/ Attachments
+- **sObject / fullName**: `DocumentChecklistSettings`, `fullName: DocumentChecklist`
+- **Metadata element**: `deleteDCIWithFiles` — exact case matters (two wrong-case guesses failed before this one landed)
+
+```http
+PUT /services/data/v68.0/headless/metadata
+```
+```json
+{
+  "type": "DocumentChecklistSettings",
+  "fullName": "DocumentChecklist",
+  "xmlRep": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><DocumentChecklistSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><deleteDCIWithFiles>true</deleteDCIWithFiles></DocumentChecklistSettings>"
+}
+```
+
+**Verification** (cold read, own DurableId — resolve it first with a SOQL query via `queryParams`, no need to ask the user):
+```http
+GET /services/data/v68.0/tooling/query
+```
+`queryParams: {"q": "SELECT Id, DurableId FROM DocumentChecklistSettings"}`
+```http
+GET /services/data/v68.0/tooling/sobjects/DocumentChecklistSettings/<DurableId>
+```
+
+### Interest Tagging — `InterestTaggingSettings`
+
+- **What it does**: lets you tag records with interests (e.g., programs, majors) to support personalization and segmentation.
+- **Setup label**: Interest Tagging
+- **sObject / fullName**: `InterestTaggingSettings`, `fullName: InterestTagging`
+- **Metadata element**: `enableInterestTagging`
+
+```http
+PUT /services/data/v68.0/headless/metadata
+```
+```json
+{
+  "type": "InterestTaggingSettings",
+  "fullName": "InterestTagging",
+  "xmlRep": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><InterestTaggingSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><enableInterestTagging>true</enableInterestTagging></InterestTaggingSettings>"
+}
+```
+
+**Verification** (cold read, own DurableId — resolve via SOQL first):
+```http
+GET /services/data/v68.0/tooling/query
+```
+`queryParams: {"q": "SELECT Id, DurableId FROM InterestTaggingSettings"}`
+```http
+GET /services/data/v68.0/tooling/sobjects/InterestTaggingSettings/<DurableId>
+```
+
+---
+
+## Not writable via this API surface at all — manual UI only
+
+Feature confirmed to have no working API toggle (tested this session) — different from "not yet tested." Present these with a one-line "what it does" and the Setup path; do not attempt an API write for rows with no failure detail (Action Launcher through Accounting Subledger below) — go straight to manual UI.
+
+| Feature | What it does | Setup label | What happens | Resolution |
+|---------|---------------|-------------|--------------|------------|
+| Industries Cloud Common Decision Tables Access | Business Rules Engine feature letting admins define decision logic in a spreadsheet-like table instead of code, used to drive automation (e.g., eligibility rules) | Decision Tables | `BREDecisionTableAccess` — backing call is an internal Aura action; no REST/Tooling/MDAPI route exists | Manual UI only — do not keep probing endpoints |
+| Intelligent Question Generation | AI-generated follow-up questions within the Discovery Framework to dynamically tailor assessments/questionnaires | Intelligent Question Generation | `enableSmartAsmtQstnGeneration` — field exists, name correct, write returns `INSUFFICIENT_ACCESS_OR_READONLY: "cannot be accessed using the API."`. Setup surfaces this under Discovery Framework settings, but it is an independent `IndustriesSettings` field, not a sub-toggle of `enableIndustriesAssessment` | Manual UI only |
+| Discovery Framework | Guided, dynamic questionnaires/assessments to gather structured information from students or applicants (e.g., needs assessments) | Discovery Framework | `enableIndustriesAssessment` — `true→false` returns HTTP 500 `UNKNOWN_EXCEPTION`. One-way confirmed; enable path (`false→true`) untested since it was already `true` in this org | Treat `true→false` as blocked; if enabling from `false`, try the standard write path first |
+| Omnistudio Metadata | Low-code tools (OmniScripts, FlexCards, DataRaptors) for building guided processes and dynamic UI without heavy custom code | OmniStudio Settings | `OmniStudioSettings`, `fullName: OmniStudio` (name guessed by analogy to other settings types, confirmed working for write) — PUT succeeds, but no GET/verify path found via Tooling or EntityDefinition | Write succeeds; **parked** — confirm success via Setup UI only. Open item: find a GET/verify API for `OmniStudioSettings` — still unresolved |
+| Timeline | Shows a chronological, unified view of all activities and interactions related to a record | Timeline | `TimelineSettings` — PUT returns HTTP 400 `UNSUPPORTED_OPERATION: "MetadataCrud does not support UPDATE on type: Timeline"`. Block is on the whole type — no `fullName` variant fixes it | Manual UI only |
+| Video Calls | Enables built-in video calling directly from Salesforce records (e.g., for advising sessions) without leaving the platform | Video Calls | `VideoCallsSettings` — same HTTP 400 `UNSUPPORTED_OPERATION` type-level block as Timeline | Manual UI only |
+| Action Launcher | Presents users with a guided list of contextual actions/tasks (e.g., macros, flows, quick actions) relevant to a record, so staff know what to do next | Action Launcher | No toggle found on `IndustriesSettings` or any tested settings sObject | Manual UI only — Setup → Quick Find → "Action Launcher" |
+| Actionable Relationship Center | Visualizes relationships between records (e.g., student, household, program) as an interactive graph so users can navigate and act on related records | Actionable Relationship Center | No toggle found | Manual UI only — Setup → Quick Find → "Actionable Relationship Center" |
+| Actionable Segmentation | Lets you build and act on dynamic segments of records (e.g., students meeting certain criteria) for targeted outreach or processes | Actionable Segmentation | No toggle found; enabled per linked-doc segment configuration, not a single flip | Manual UI only — see Setup Help doc for per-segment setup |
+| Clause Management | Manages standardized legal/policy clause text (e.g., for contracts or agreements) so they can be reused and inserted consistently | Clause Management | No toggle found; configured via clause category setup | Manual UI only |
+| Contacts to Multiple Accounts | Allows a single Contact (e.g., a student) to be associated with more than one Account (e.g., household + employer), reflecting real-world relationships | Contacts to Multiple Accounts | No toggle found; set up per linked Setup Help doc | Manual UI only |
+| Disclosure and Compliance Hub | Centralizes compliance disclosures and regulatory documentation (e.g., consumer/financial disclosures) for tracking and audit | Disclosure and Compliance Hub | No toggle found; set up per linked Setup Help doc | Manual UI only |
+| Group Membership | Tracks a person's membership in groups (e.g., clubs, cohorts, teams) and manages associated roles/status | Group Membership | No toggle found; set up per linked Setup Help doc | Manual UI only |
+| Intelligent Document Reader | Uses AI/OCR to extract data from uploaded documents (e.g., transcripts, IDs) and populate Salesforce records automatically | Intelligent Document Reader | No toggle found | Manual UI only — flag the Government Cloud data-boundary caution from the Setup doc before enabling |
+| Marketing Cloud for Education | Integrates Education Cloud data with Marketing Cloud for targeted recruitment/engagement campaigns | Marketing Cloud for Education | No toggle found; external product connection, not an org preference | Manual UI only — see Setup Help doc |
+| Outcome Management | Tracks measurable outcomes/goals tied to programs or cases, letting staff manage and report on progress against defined outcomes | Outcome Management | No toggle found | Manual UI only. **Also requires a permission set** — create/assign one granting "Manage Outcomes" and "Run Flows" |
+| Stage Management | Visualizes and automates a record's progress through defined stages/fulfillment plans (e.g., admissions pipeline), tracking steps and dependencies | Stage Management | No toggle found | Manual UI only. **Also requires a custom permission set** — Dynamic Common Orchestrator User plus object permissions on Fulfillment Plans, Fulfillment Steps, Fulfillment Dependencies, Fulfillment Sources, and Stage Transition Entries |
+| Accounting Subledger | Tracks detailed financial transactions (tuition, fees, payments) tied to student accounts, giving institutions a sub-ledger view feeding into general accounting | Accounting Subledger | No toggle found | Manual UI only. **Also requires**: add users, set up data pipelines, create/assign permission sets — flag all three as separate manual follow-ups, not a single step |
+
+---
+
+## Confirmed — org preference API (different write mechanism, not `IndustriesSettings`)
+
+Not every toggle lives on `IndustriesSettings`. This one is a **Setup-Connect org preference**, a different API surface entirely — no metadata `type`/`fullName`/`xmlRep`, just a named preference path.
+
+### Einstein Generative AI (master toggle) — `EinsteinGPTCopilotEnabled`
+
+- **What it does**: enables generative AI features platform-wide (e.g., drafting emails, summarizing records) within Education Cloud.
+- **Setup label**: Set Up Einstein for Education Cloud → Einstein Generative AI
+- **Reversible — confirmed by live test.** `PATCH` with `{"desiredState": false}` succeeds and cold-verifies `false`. Unlike most `IndustriesSettings` toggles in this skill, this one is a genuine two-way org preference.
+
+```http
+GET /services/data/v68.0/setup/org/preferences/EinsteinGPTCopilotEnabled
+```
+Returns `{"isPreferenceEnabled": <bool>}`.
+
+```http
+PATCH /services/data/v68.0/setup/org/preferences/EinsteinGPTCopilotEnabled
+```
+```json
+{ "desiredState": true }
+```
+Response echoes the post-write state directly — `{"isPreferenceEnabled": true}`. Cold-verify with a repeat GET anyway (same discipline as everywhere else in this skill).
+
+---
+
+## Confirmed — Setup Operation Recipe (Aura-backed controller, not a simple metadata toggle)
+
+### Data Space Mapping — `DataSpaceFeatureMappings`
+
+- **Setup label**: Setup Basics → Data Space Mapping
+- Binds an Education Cloud feature (`Student Success` / `STUDENT_SUCCESS` or `Financial Aid` / `FINANCIAL_AID` — the only two valid for this workflow) to a Data Cloud Data Space. **Reversible** — delete is supported, unlike most toggles in this skill.
+- Requires Data Cloud (CDP) provisioned + user has Data Cloud app access. Pre-flight check tells you which.
+
+```http
+GET /headless/invoke/platform/data-space-feature-mappings
+```
+Returns `true`/`false` (Data Cloud provisioned + accessible). `false` → stop, fall back to manual Setup UI.
+
+```http
+GET /headless/invoke/platform/data-space-feature-mappings/get-data-spaces
+GET /headless/invoke/platform/data-space-feature-mappings/get-data-space-features
+```
+First returns candidate Data Spaces (`devName`); second returns the two EDU-scoped feature choices (`{label, value}`).
+
+```http
+PATCH /headless/invoke/platform/data-space-feature-mappings/create-data-space-feature-mapping
+```
+```json
+{ "feature": "STUDENT_SUCCESS", "dataSpace": "<devName>" }
+```
+HTTP is always 200 — check `body.status`: `'200'` success (includes `mappingId`), `'400'` duplicate (a mapping for that feature already exists — not an error), `'500'` other failure.
+
+**Verification** (cold read):
+```http
+GET /headless/invoke/platform/data-space-feature-mappings/get-data-space-features-mapping
+```
+Confirm the new row; its `id` is the `mappingId` for delete.
+
+**To undo** (this one supports it):
+```http
+DELETE /headless/invoke/platform/data-space-feature-mappings/delete-data-space-feature-mapping
+```
+`queryParams: {"mappingId": "<id>"}`. Not idempotent — re-deleting an already-gone `mappingId` returns `status:'500'` with a "doesn't exist" message; treat that as already-deleted, not a real error.
+
+---
+
+## Explicitly out of scope for this skill
+
+- **Managed Package Runtime** — skipped at user's explicit request; do not attempt to enable.
+- **Deploy Custom LWC in Standard Runtime** — skipped at user's explicit request; do not attempt to enable.