education-cloud-domain-configure

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 conversationally. Re-render after each enable.

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

   Render HxlSetupIntent with these six domains and their status.

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. This describe call is the ONLY valid check; never run SOQL against IsPersonAccount or Person-Account fields (see references/gotchas-extended.md, "Person Accounts verification").

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 ("Configuration shapes") categorizes every feature into one of four shapes (IndustriesSettings toggle, org-preference toggle, overlap with a domain sub-feature, manual UI only); look up the selected feature there for its exact element names, DurableIds, and gotchas. Toggles are IRREVERSIBLE unless the reference says otherwise: warn, then READ → WRITE → cold-VERIFY.

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 (Phase 0), most domains need an added license or a prior domain; the per-domain list is in references/domain-features.md ("Domain prerequisites"). If prerequisites are missing, warn user and ask whether to continue with available features or provision prerequisites first. Render HxlSetupReview with these domain prerequisites.

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: references/domain-features.md ("Domain toggle fields"). Recruitment & Admissions has no master toggle; skip this step and go to references/domain-features/recruitment-admissions.md "Enablement & Toggles".

    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. Render HxlSetupPlan once the selection is known.

21. Configure each selected sub-feature — explain what it does, warn if irreversible, confirm with user (a click on the row's widget button counts as that confirmation), 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. Render HxlSetupApply and re-render it after each item's cold-verify.

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. Render HxlSetupVerify with one row per cold-verified write.

---

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, HXL Setup widgets (Intent, Review, Plan, Apply, Verify via display_widget) reflecting live state where the host and org support them, 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/setup-widgets.md	Steps 6, 15, 20, 21, 22 and the Phase 0 review (prop contracts and Education Cloud mapping for the 5 HXL Setup widgets)
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)