• 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

• 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

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

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.

GET /services/data/vXX.X/limits

sf

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.

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

   .

1. 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
2. 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.

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

1. 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.
2. 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.
3. Enable OmniStudio — OmniStudio is included with Education Cloud license. Attempt API call or instruct user to navigate to Setup → OmniStudio Settings → Enable.
4. Enable Business Rules Engine — Business Rules Engine is included with Education Cloud license. Instruct user to navigate to Setup → Business Rules Engine → Enable.
5. 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).

1. 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.
2. 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.
3. 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."
4. 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.
5. 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.

1. Read sub-feature reference — load the selected domain's file under

   references/domain-features/

   to identify available sub-features and their detailed setup steps.
2. 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.
3. 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.
4. 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.

• 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

  .