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. 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).