@salesforce/afv-skills 1.46.0 → 1.47.0

package/skills/education-cloud-student-recruitment-agent-configure/references/flows.md

@@ -0,0 +1,82 @@
+# Admissions flows — inventory & clone recipe
+
+Read at Workflow step 11 (the last of the agent-build block, after the agent is committed in step 9a and right before channel deploy — unauthenticated/Service path only, **not** the foundation phase). Package flows live in the `eduadmissions` namespace.
+
+The whole flow lifecycle is **tier 1**: inventory, retrieve, clone (as override or from template), and edit run over the Connect-REST `/flowbuilder/*` surface (`dispatch`/`dispatch_readonly`); **activation** is the tier-1 Tooling `FlowDefinition` PATCH (step 4 below), and verify is a tier-1 `/query`. No tier-2/tier-3 fallback is needed for the clone itself.
+
+> **WARNING: Sequencing — do this with the unauthenticated-agent build, not in the foundation phase.** This entire file is **unauthenticated/Service (ASA) agent path ONLY** — skip it entirely if you're only building the authenticated/Employee agent. The flows have no ordering dependency on the *agent* build (the override links by reference to the managed original, so packaged subagent actions keep resolving through it, and the only user-ish input is `DefaultUserOwnerId` = a System Admin Id, resolved inline from the running user (below) — not any agent's running user). But do not front-load it into the early permissions/OWD foundation block — it belongs with unauthenticated-agent creation and channel deploy. In a partial build, defer it until the ASA agent is actually being built.
+
+## The two clone mechanisms (one endpoint, one linkage key apart)
+
+Every clone is the **same** call — `POST /services/data/vXX/flowbuilder/flow/actions/save` (note the `/actions/` segment — the bare `/flowbuilder/flow/save` path 405s `METHOD_NOT_ALLOWED`, GET/HEAD only) with `saveType:"createNewFlow"`, fed the platform's own retrieved flow JSON. The mechanisms differ **only** by which key you add to `metadata`:
+
+| Mechanism | Source flow property | Key you add to `metadata` | Populates | Runtime behavior |
+|---|---|---|---|---|
+| **Override** | `isOverridable:true` | `overriddenFlow: "<managed ApiName>"` **and set `isOverridable:false`** on the clone itself | `FlowDefinitionView.OverriddenFlowId` | Intercepts the managed original at runtime |
+| **Create-from-template** | `isTemplate:true` | `sourceTemplate: "<template ApiName>"` + `isTemplate:false` | `FlowDefinitionView.SourceTemplateId` | Standalone new flow seeded from the template |
+
+> **CRITICAL: an override clone must flip `isOverridable` to `false` on itself.** The retrieved managed source carries `isOverridable:true`; saving the clone as-is with that flag still `true` fails `FLOW_OVERRIDABLE_CANNOT_BE_OVERRIDE` ("a flow that overrides another can't itself be overridable"). Only the managed original stays overridable — the override clone must set `isOverridable:false` alongside adding `overriddenFlow`.
+
+Do **not** use `POST /flowbuilder/flow/actions/clone` on a managed source — it tries to modify the managed `InteractionDefinitionVersion` and fails `MANAGED_INSTALLED`. `save createNewFlow` creates a *new* unmanaged flow and is the one recipe for both buckets.
+
+> **CRITICAL: An overridable flow accepts only ONE override — a pre-existing override blocks a fresh clone.** If the managed original is already overridden (by a customer's own customization, or a prior/partial SRA build), a second override `save` still returns `201 isSuccess:true` but with `status:"InvalidDraft"` and a `FLOW_ALREADY_OVERRIDDEN` warning — activation-blocking, not a hard error. **WARNING: The step-1 `FlowDefinitionView.OverriddenFlowId` read does NOT reliably detect this** — an inactive/Draft override leaves `OverriddenFlowId` null yet still blocks a new one. So on a `FLOW_ALREADY_OVERRIDDEN` warning, the existing override named in the message is the one to reuse or remove — do not create a duplicate; adopt the existing override clone (or delete it first if it's a stale partial), rather than assuming a null `OverriddenFlowId` means the slot is free.
+
+## Flow inventory & the 2-wave ordering
+
+The 6 flows fall into three roles: **reusable subflows** (called by others), **consumers** (which call those subflows), and one **standalone** (`GetPlnCampaigns` — no dependencies, rides in wave 1 only because nothing blocks it). The dependency is between subflows and consumers, creating a hard producer→consumer ordering: **clone AND activate the wave-1 flows first** (the 2 subflows + the standalone), then clone the wave-2 consumers and re-point them at the active subflow clones. (If a consumer references a still-Draft subflow clone, its save returns a `SUBFLOW_NO_ACTIVE_VERSION` warning that blocks activation.)
+
+| Wave | Flow (label) | Package API name | Role | Mechanism |
+|---|---|---|---|---|
+| **1** | EDU Admissions: Get Planned Campaigns | `GetPlnCampaigns` | standalone (unauthenticated campaign read) | override, no edits |
+| **1** | EDU Admissions: Process Person Account | `ProcPersAcct` | reusable subflow | create-from-template |
+| **1** | EDU Cloud: Inquiry: Academic Interest Processing | `InquiryAIProcessing` | reusable subflow | create-from-template |
+| **2** | EDU Admissions: Create Campus Tour Registration | `CreateCampusTourRgstr` | consumer | override + subflow edits |
+| **2** | EDU Admissions: Process Academic Interest | `ProcessAcademicInterest` | consumer | override + subflow edits |
+| **2** | EDU Admissions: Create Inquiry | `CreateInquiry` | consumer | override + subflow edits |
+
+> The two create-from-template flows ship **Draft-only** (no active version) — expected, since a template is instantiated rather than run directly. Their clones must be activated for wave 2 to reference them.
+>
+> `CreateInquiry` ships wired to **no** packaged subagent by design — it gets wired into the customer-built escalation subagent, added by the customer in step 9a (see `agent-and-subagents.md`). It creates Case + Educational Info Request + Academic Interest.
+
+## The clone lifecycle (tier 1, per flow)
+
+All calls over Headless `dispatch`/`dispatch_readonly`; substitute the org's current API version for `vXX` (the flow verify `/query` needs **v62.0+** as a minimum — see the API version policy in `execution-model.md`).
+
+1. **Retrieve the managed source** (`dispatch_readonly`): `GET /services/data/vXX/flowbuilder/flow/{activeVersionId}` (or `{ApiName}-{versionNumber}`, or `LatestVersionId` for a Draft-only template) → `body.flow.metadata` is the flow body to edit. (Managed flows ARE readable here.)
+2. **Edit the metadata** (no call — mutate `flow.metadata` in place): add the linkage key for the mechanism (`overriddenFlow`, or `sourceTemplate` + `isTemplate:false`). **For an override clone, also set `isOverridable:false`** on the clone's own metadata — the retrieved source carries `isOverridable:true`, and saving it unchanged fails `FLOW_OVERRIDABLE_CANNOT_BE_OVERRIDE`. For every cloned flow set the run mode to system context (below). Consumers additionally swap subflows + set the owner constant (below).
+3. **Save as new flow** (`dispatch`): `POST /services/data/vXX/flowbuilder/flow/actions/save` (the `/actions/` segment is required — the bare `/flowbuilder/flow/save` path returns `405 METHOD_NOT_ALLOWED`, GET/HEAD only) body `{ "saveType":"createNewFlow", "builderType":"FlowBuilder", "flow": { "fullName":"{newUnmanagedApiName}", "metadata": { ...edited... } } }` → `201 { isSuccess:true, status:"Draft", versionNumber:1, definitionId, flowId, errors:[], warnings:[...] }`. Inspect `warnings[]` even on success — `SUBFLOW_NO_ACTIVE_VERSION` / `SUBFLOW_DIFFERENT_RUNMODE` are activation-blocking and mean a wave-1 clone isn't active yet or a run-mode is mismatched; `FLOW_RUN_AS_SYSTEM_MODE_WITH*_CONTEXT_WARNING` is benign for a system-context flow on the unauthenticated path. (To edit an existing clone → same call with `"saveType":"saveAsNewVersion"` + `"currentFlowId":"{priorVersionFlowId}"`.)
+4. **Activate** (`dispatch`): the working path is a Tooling `FlowDefinition` PATCH — query `FlowDefinition` by DeveloperName for the `300`-prefix def Id, then `PATCH /services/data/vXX/tooling/sobjects/FlowDefinition/{defId}` `{"Metadata":{"activeVersionNumber":N}}` (N = version number, 0 to deactivate) → **204**. This activates a version *by number* without rewriting it. **WARNING:** Do **not** use `PATCH /tooling/sobjects/Flow/{flowId}` `{Metadata:{status:'Active'}}` — it overwrites the version body and 400s `INVALID_STATUS` once a version has been active. The native `POST /flowbuilder/flow/{flowId}/actions/activate` endpoint is not reliably available (it 404s on some orgs) — attempt only if preferred, falling back to the FlowDefinition PATCH on a 404. Read `FlowDefinitionView.IsActive` first and only activate if false.
+5. **Cold-verify** (`dispatch_readonly`): re-run the inventory query (below), don't trust the activate response alone.
+
+### Common edit for every cloned flow — system-context run mode
+
+Set `metadata.runInMode = "SystemModeWithoutSharing"` (the UI's *Show Advanced → How to Run the Flow → "System Context Without Sharing – Access All Data"*). **Mandatory** for the unauthenticated/Service path, not optional polish.
+
+### Consumer edits (wave 2) — subflow swap + owner constant
+
+For each wave-2 consumer, before `save`: repoint each subflow element's `flowName` to your **active** wave-1 clone (keep the element `name` unchanged so downstream dotted references like `{subflowName}.incomingPersonAccount.PersonContactId` stay valid), and set the `DefaultUserOwnerId` constant's `value.stringValue` to a System Admin user Id. **Always ask the customer** whether that owner should be the current (running) user or someone else — don't silently default. The running user is already required to be a System Administrator (see `prerequisites.md`), so offer it as the default: reuse the Id already resolved at Step 4a (`permissions.md`) — no need to re-derive it. If that Id isn't available, resolve it via `SELECT Id FROM User WHERE Username='<current user>'` over `dispatch_readonly`, then confirm before using it; if they name a different owner, look that user up instead (`SELECT Id FROM User WHERE …`).
+
+- **`CreateCampusTourRgstr`** — swap the one `Process Person Account` subflow → active `ProcPersAcct` clone; input `incomingPersonAccount = {!PersonAccountDetails}`.
+- **`ProcessAcademicInterest`** — swap TWO subflows: (a) `Process Person Account` → active `ProcPersAcct` clone, `incomingPersonAccount = {!PersonAccountDetails}`; (b) `Academic Interest Processing` → active `InquiryAIProcessing` clone, inputs `academicTermId = {!AcademicInterestDetails}`, `incomingPersonAccount = {!ProcessPersonAccount.incomingPersonAccount}`, `isNewPersonAccount = {!ProcessPersonAccount.isNewPersonAccount}`, `selectedLearningProgramIds = {!learningProgramIds}`; manually-assigned output `newAcademicInterestIds = {!academicInterestIds}`.
+- **`CreateInquiry`** — same pattern as `ProcessAcademicInterest`.
+
+## Verify (concrete call — run after cloning each wave)
+
+Use the Data-API **`FlowDefinitionView`** (backs the Setup → Flows list) over `dispatch_readonly` — **not** Tooling `FlowDefinition`, which is blind to package-namespaced flows and returns 0 rows for these. Presence of the packaged flows is gated on `NamespacePrefix='eduadmissions'`, **not** on `InstalledSubscriberPackage` (which does not register these feature packages).
+
+```text
+GET /services/data/vXX/query/?q=
+  SELECT ApiName, Label, NamespacePrefix, ManageableState, IsActive,
+         ActiveVersionId, LatestVersionId, OverriddenFlowId, SourceTemplateId
+  FROM FlowDefinitionView
+  WHERE NamespacePrefix='eduadmissions'
+    AND ApiName IN ('GetPlnCampaigns','ProcPersAcct','InquiryAIProcessing',
+                    'CreateCampusTourRgstr','ProcessAcademicInterest','CreateInquiry')
+```
+
+Notes: `FlowDefinitionView` has **no `Status` field** (use `IsActive`); the field is **`ApiName`**, not `DeveloperName`; the WHERE clause does **not** support OR/disjunctions — use `IN (...)` or split into separate queries. To confirm a clone: query it by its new `ApiName` and check `ManageableState='unmanaged'`, `IsActive=true`, and the linkage field (`OverriddenFlowId` = the managed original, or `SourceTemplateId` = the template). This `/query` read is the tier-1 normal path; keep the `sf data query` (tier 2) / UI fallback ready for a transient `/query` outage window (see `execution-model.md` on the query-family caveat).
+
+## Notes
+
+- Help ref: `sfdo.ec_inquiry_flows_setup.htm`.
+- These flows run in system context (`SystemModeWithoutSharing`, above) under the ASA's **Einstein Agent User** service account — there is no guest user (see `permissions.md`). Object access (e.g. Create on `Account`) comes from that account's `SRA_AI_Agent_Access` clone (of `EducationCloudAiAgentAccess`, built step 4b), not a guest profile.

package/skills/education-cloud-student-recruitment-agent-configure/references/grounding.md

@@ -0,0 +1,199 @@
+# Grounding — two independent mechanisms
+
+Read at Workflow steps 7–8 and 9. SRA grounding is **two separate mechanisms — do not conflate them.**
+
+1. **Knowledge grounding** (FAQ subagent) — answers over published Knowledge articles via a Knowledge-sourced **data library**. No Data Cloud involved. **Fully TIER 1** — article create/publish/verify and data-library create/index/verify all route over `dispatch`/`dispatch_readonly`.
+2. **Data Cloud grounding** — structured Education Cloud data (Learning Program, Academic Term, PTAT) surfaced through **Data Cloud + hybrid-search indexes + retrievers + prompt templates**: 3 grounded objects/DMOs/prompt templates, but only **2** physical search-index/retriever builds (Academic Term shares the PTAT build; Application Timeline rounds out the data spine as a relationship source only, with no index/retriever/prompt template of its own — see Mechanism 2 below). **The data spine is TIER 1** (Connect REST over `dispatch`); the **index build, retriever create, and prompt-template edit are TIER 3 (Setup UI)** — no supported public API. There is **NO tier-2 `sf`-deploy path** for grounding metadata.
+
+> **WARNING: Two mechanisms, do not conflate.** Mechanism 1 (Knowledge) is **fully tier 1** — article create/publish + data-library create over `dispatch`. Mechanism 2 (Data Cloud) is **three prompt-template-backed retrieval actions** (Learning Program, Academic Term, Program Term Application Timeline), not one — but only 2 of those 3 have their own search-index/retriever build; Academic Term grounds on the PTAT retriever. The data spine underneath maps a 4th DMO, Application Timeline, alongside those three — it backs 3 of the PTAT retriever's return fields by relationship but is never itself indexed or retrieved. Every verify below is a **tier-1 `/query`/`/tooling/query` attempt first**, `sf` as fallback — both route over `dispatch_readonly`.
+
+---
+
+## Mechanism 1 — Knowledge grounding (step 7 + step 9 wiring) — FULLY TIER 1
+
+The `AnswerQuestionsWithKnowledge` action (`EmployeeCopilot__AnswerQuestionsWithKnowledge`) answers over **published Knowledge articles** surfaced through a **Knowledge-sourced data library**. Articles must be **Published (Online)** and cover the 4 areas: **learning programs, support programs, application processes, campus & support information**. No specific article type/data category is mandated.
+
+- **WARNING:** The FAQ action is **public** → articles must contain **NO non-public data**.
+- Draft articles cause the agent to answer "no information" — the classic failure mode. Publish before testing.
+- A Knowledge-sourced library indexes the **live** Knowledge object: once wired (step 9), newly **Published (Online)** articles matching the library's filters are picked up automatically on the index's refresh cycle — **no re-wiring or re-publish of the agent**. Drafts, archived, and filtered-out articles are excluded. So after the one-time wiring, ongoing article authoring alone keeps the agent current — tell the customer this so they don't expect to re-touch the agent per article.
+
+### 7a — Author + publish a Knowledge article — 🟢 TIER 1
+
+Content authoring is a human decision — **never auto-create articles.** Check first, then ask:
+
+1. **Check for existing coverage first.** Query `Knowledge__kav` for `PublishStatus='Online'` (and `'Draft'`, to show what's in progress) and skim titles against the 4 required areas — **learning programs, support programs, application processes, campus & support information**. Do this **before** proposing any create.
+2. **Always ask the customer — do not draft anything until they answer.** Report what you found (e.g. "You already have 6 Online articles; they look like they cover learning programs and application processes, but I don't see anything on campus & support info") and offer exactly one of three choices per gap, resolved on the spot rather than left open:
+   - **Draft placeholder content now**, for the customer to edit and finalize later.
+   - **The customer supplies the content now**, for you to create as draft articles.
+   - **Defer entirely** — the customer authors and publishes their own articles later, on their own schedule.
+
+   Only proceed to step 3 for the gaps where the customer picked the first or second option. Whichever way each gap resolves, **move on to 7b (the data library) immediately after** — library creation never waits on article content existing; anything published later is picked up automatically (see the Wiring note below).
+3. **Prereq (once the customer has asked for a draft):** Lightning Knowledge enabled. Read the createable fields off `GET /services/data/vXX/sobjects/Knowledge__kav/describe` first — the required, non-defaulted fields are `Title` (string 255), `UrlName` (string 255, must be **unique**), and `Language` (picklist, e.g. `en_US`); the **body field API names are org/article-type-specific** (e.g. `Answer__c`, `Question__c`, `Detail__c`) — take them from describe (§7a step 1), do **not** hardcode. If the org's Knowledge object is a custom type, the `*__kav` API name differs too.
+4. **Create the draft** — `POST /services/data/vXX/sobjects/Knowledge__kav` body `{"Title":"...","UrlName":"<unique-slug>","Language":"en_US","<bodyField__c>":"<html>"}` → 201 `{"id":"ka0…","success":true}`. New article starts `PublishStatus:"Draft"`, `VersionNumber:0`, with a `KnowledgeArticleId` (the `kA0…` durable id grouping versions).
+5. **Publish** — `PATCH /services/data/vXX/knowledgeManagement/articleVersions/masterVersions/<articleVersionId>` body `{"publishStatus":"Online"}` → **204 No Content** (success). The `<articleVersionId>` is the `ka0…` `Knowledge__kav` row Id (the draft version), **NOT** the durable `KnowledgeArticleId`. (Add `"flagAsNew":true` for a major version on republish.) Publishing mutates the version row in place (Draft/v0 → Online/v1). Draft→Online is fully API-driven over `dispatch`; no UI needed. (Do **not** use a `publishKnowledgeArticles` invocable/Apex action — use the masterVersions PATCH.)
+6. **Verify (attempt T1 `/query` → `sf` fallback):**
+```bash
+# Tier 1 first (dispatch_readonly): GET /services/data/vXX/query?q=<URL-encoded SOQL below>
+# Tier 2 fallback:
+sf data query -q "SELECT PublishStatus, COUNT(Id) total FROM Knowledge__kav GROUP BY PublishStatus" --target-org <alias>
+sf data query -q "SELECT Id, Title, PublishStatus, KnowledgeArticleId FROM Knowledge__kav WHERE PublishStatus='Online'" --target-org <alias>
+```
+`PublishStatus='Online'` = live articles the FAQ action can read; `Draft` articles are invisible to the agent. (The aggregate `GROUP BY` read routes at tier 1.)
+
+### 7b — Create the Knowledge-sourced data library — 🟢 TIER 1
+
+The FAQ subagent grounds on a **data library** whose source is Knowledge (NOT Data Cloud — do not conflate with Mechanism 2). Creating it **auto-provisions the backing stream + search index + retriever** — no separate index-build step, no agent needed until the wiring at step 9.
+
+- **Preconditions:** Data 360 (Data Cloud) set up; the running user needs **Data Cloud Admin AND System Administrator**; the org-access check on the create op is "Generative AI Setup enabled." Library indexing consumes Data 360 credits.
+- **Tier 1 create:** `POST /services/data/vXX/einstein/data-libraries` over `dispatch`, body:
+  ```json
+  {
+    "masterLabel": "Student Recruitment Knowledge Library",
+    "developerName": "SRA_Knowledge_Library",
+    "description": "<desc>",
+    "groundingSource": {
+      "sourceType": "KNOWLEDGE",
+      "knowledgeConfig": {
+        "primaryIndexField1": "Title",
+        "primaryIndexField2": "Summary",
+        "contentFields": ["<bodyField__c>"]
+      }
+    }
+  }
+  ```
+  → **201** returning `libraryId`, `dataSpaceScopeId`, `sourceType:"KNOWLEDGE"`, `status:"IN_PROGRESS"`, `featureAssignments:[]`. Use the **fixed `developerName` `SRA_Knowledge_Library`** (never a per-org-run name) so the step-9 wiring can re-find the library deterministically — by that exact developerName, not by `sourceType` (the org may already have other KNOWLEDGE libraries) and never by asking the customer what it was called. Re-running create with the same developerName returns a `DUPLICATE`-class error → treat as "already exists, read it back," not a failure. **BOTH `primaryIndexField1` AND `primaryIndexField2` are mandatory** (the UI's two "identifying fields" — text/textarea, keep ≤255 chars to stay under the 512-token cap); the create 400s naming each missing field in turn until both are present. **Content is the array key `contentFields`** (NOT `contentField1` — a singular key is silently dropped); the `*__kav` field API names come from describe (§7a step 1). Optional Knowledge filters live in `knowledgeConfig`: `isRestrictToPublicArticle`, `isDataCategoryRuleEnabled` + `dataCategorySelectionIds`/`Names` (SRA needs neither for the basic path). The KNOWLEDGE source skips the file-upload chain (`file-upload-urls`/`add-files`) — create alone kicks indexing.
+- **Tier 3 fallback:** Setup → Agentforce → Data Library → New → Knowledge source, if the Connect call 403/404/501s on the org.
+- **Verify (T1 readonly):** `GET .../einstein/data-libraries/<libraryId>` returns the full config — confirm `sourceType:"KNOWLEDGE"` and `contentFields` is non-empty; `GET .../einstein/data-libraries` lists all. **Don't wait on indexing to finish here** — wiring the library into the agent (step 9) only needs the `libraryId`, not a completed index, and indexing runs on its own async schedule (large sets can take 30 min–several hours) with nothing in this flow gated on it.
+
+### Wiring (step 9) — attach the data library to the agent — 🟢 TIER 1 (T3 fallback)
+
+Grounding is **one agent-level field**, not a per-subagent link. In the agent's NGA bundle AFScript, the top-level `knowledge:` block carries the binding:
+
+```yaml
+knowledge:
+    rag_feature_config_id = "ARFPC_<libraryId>"
+    citations_enabled: True
+```
+
+- **`rag_feature_config_id`** = the literal string `ARFPC_` + the data library's `libraryId` verbatim (e.g. library `1JDVW000001KWPl4AO` → `ARFPC_1JDVW000001KWPl4AO`). `ARFPC` = *Agent RAG Feature Config*; the id is derived from the library itself — you do **not** query a separate config object for it (`GenAiFeatureConfig`/`AiFeatureConfiguration` etc. are not valid sobjects here). **Re-read the `libraryId` here, don't rely on carrying it from step 7** — `GET /services/data/vXX/einstein/data-libraries` (readonly) lists all libraries with their Ids; match the row by the **exact `developerName` `SRA_Knowledge_Library`** (the fixed name from step 7b — not `sourceType`, which won't disambiguate from pre-existing KNOWLEDGE libraries).
+- This one field grounds Knowledge **agent-wide**: every packaged subagent's existing `AnswerQuestionsWithKnowledge` action (source `EmployeeCopilot__AnswerQuestionsWithKnowledge`, target `standardInvocableAction://streamKnowledgeSearch`) reads `@knowledge.rag_feature_config_id`. There is **nothing to add per subagent** — the FAQ subagent's action list is byte-identical before and after wiring.
+- **Fold it into step 9's initial bundle-create pass** — set the two lines above in the AFScript alongside the subagent edits. No `validate`/`publish` needed here (no new action target is being added); publish stays reserved for the customer's single Commit Version at step 9a (see `agent-and-subagents.md`).
+- **The data library's own `featureAssignments` stays `[]`** — it is **not** the link (it's an output-only feature-family field; `PATCH /einstein/data-libraries/{id}` won't accept it). Do not treat a link as a `featureAssignments` write, and don't promise a `DataLibrary` MDAPI `sf project deploy` — there is no such metadata type.
+- **Tier 3 fallback:** the Agentforce Builder data-library UI on the agent (Setup → the agent → connect data library) sets the same field — use it if the NGA lifecycle 403/404/501s.
+- **Verify wiring:** re-GET the bundle version and confirm `knowledge.rag_feature_config_id` is `ARFPC_<libraryId>` (was `""`); the step-13 conversational smoke test (user-run in the deployed channel) then returns article-grounded, cited answers.
+
+---
+
+## Mechanism 2 — Data Cloud grounding (step 8) — 3 retrieval actions, 2 retriever builds
+
+Step 8 wires **3** prompt-template-backed retrieval actions — one per grounded object/DMO/prompt template, genuinely 3 of each. But only **2 physical search-index/retriever builds** back them, because Academic Term has no search index or retriever of its own — its prompt template grounds directly on the PTAT retriever:
+
+| # | Retrieval action (retriever-backed) | Grounded object | DMO | Base prompt template (dev name) | Search index / retriever build |
+|---|---|---|---|---|---|
+| 1 | Get Learning Program Data | Learning Program | `ssot__LearningProgram__dlm` | `sturecruitment__getLearningPrograms` | **Learning Program build** |
+| 2 | Get Academic Term Data | Academic Term | `ssot__AcademicTerm__dlm` | `sturecruitment__getAcademicTerms` | **PTAT build** (shared — see below) |
+| 3 | Get Application Timeline Data | **Program Term Application Timeline** | `ssot__ProgramTermApplicationTimeline__dlm` | `sturecruitment__getApplicationTimelines` | **PTAT build** (shared — see below) |
+
+> **CRITICAL: Academic Term has no dedicated search index/retriever — by design, not a gap to fill.** Its prompt template's own Data Model Object field is **Program Term Application Timeline**, not Academic Term, and its `GROUNDING_DATA` line reads `Retrievers:Program Term Application Timeline Retriever`. Do not build a separate Academic Term index/retriever — there's nothing to wire it to; both the Academic Term and PTAT rows above share the one PTAT retriever build (see the retriever field config below).
+>
+> **CRITICAL: Row 3's retrieval action grounds Program Term Application Timeline (PTAT), NOT ApplicationTimeline.** `GetApplicationTimelineData` (template `sturecruitment__getApplicationTimelines`) has **source object/DMO `ssot__ProgramTermApplicationTimeline__dlm`** — a different object than `ApplicationTimeline`. The retriever/index may be **labeled** "Application Timeline" or "PTAT" (matches the template's user-facing output), but the underlying object/DMO is PTAT. If a target org's field set ever looks off, the authoritative source is the base template's own `resultFieldApiKey=` references (`GET /einstein/prompt-templates/<devName>`), not the step's display name. **`ApplicationTimeline` itself still needs its own DMO mapped into the spine below** — the PTAT retriever's return fields reach 3 of its fields (Application Open/Close Date, Application Category) through a relationship lookup, and that lookup only resolves once `ApplicationTimeline` is mapped; it never gets a search index or retriever of its own.
+
+> **CRITICAL: `GetProgramTermApplicationTimelineData` is a SEPARATE, deterministic STANDARD_INVOCABLE action — do NOT confuse it with the retriever-backed `GetApplicationTimelineData` above.** It invokes packaged flow/apex (complex active-program-term filtering retrievers don't support) and is **not** retriever-backed — do not wire a retriever/prompt template for it. (Naming collision, not a typo: the retriever action is `GetApplicationTimelineData`; the invocable action is `GetProgramTermApplicationTimelineData`.) The perm-set/OWD API name for the object is the truncated `ProgramTermApplnTimeline` — different surface, different spelling again.
+
+> **Prompt-template scope — exactly 3 base-SRA templates, exclude the 2 Transfer Credit ones.** Five `promptTemplate/sturecruitment/` YAMLs exist, but namespace path alone does NOT prove SRA membership. In scope: `getLearningPrograms`, `getAcademicTerms`, `getApplicationTimelines`. **Out of scope (Transfer Credit Agent only, gated `orgHasTransferCreditEquivalencyAccess`): `getInstitutionData`, `getExternalLearningData`** — do NOT wire retrievers for these (consistent with the "do NOT include TransferCreditEquivalency" rule in `agent-and-subagents.md`).
+
+> **Create-action types (not all flows):** `CreateAdmissionsApplication` is an **API** action (ConnectApi `Industries-Education.postPreliminaryApplicationReferences`) — currently deleted from the Admissions Application subagent at step 9a, see `agent-and-subagents.md`; `CreateCampusTourRegistration`, `CreateAcademicInterest`, and `GetCampusTourCampaigns` are **FLOW**. These read/grounding actions apply to **both** agent paths (auth/AEA + unauth/ASA), unlike the flow surgery (unauth-only — see `flows.md`).
+
+> **Scope — the Learning Program *source records* are not this skill's job.** The programs, courses, academic calendar/terms, and campus hierarchy the agent retrieves are created by other Education Cloud skills (Academic Operations setup) and seeded as demo/customer data (same rule as the R&A domain objects — see `prerequisites.md` F-iii). This skill wires the *grounding* over that data; it does **not** create those records. Confirm the source data exists, but do not create it here.
+
+### The tier split — data spine is T1, index/retriever/prompt are T3
+
+- 🟢 **TIER 1 — prereq (separate from the agent-user perm-set clone) — grant 3 EDU system perms to the Data Cloud *Salesforce Connector* permission set.** The **Platform Integration User** that Data 360 uses to read CRM data authenticates through this permission set — it comes bundled with connecting the org to Data Cloud itself, not a separate grant to create. Before any EDU object ingests, enable System Permissions **Access Education Cloud Components** (`PermissionsUseEducationCloudComp`), **Access Education Cloud Objects** (`PermissionsAccessEducationCloud`), and **Access Education Cloud Review Features** (`PermissionsAccessEducationCloudReview`) — ref KB 001983512. This is separate from the Einstein-Agent-User clone in `permissions.md`; without it, the data streams silently ingest nothing for EDU objects.
+  - **CRITICAL:** `PATCH /services/data/vXX/sobjects/PermissionSet/<Id>` (standard Data API — `/tooling/sobjects/` accepts the same body but doesn't apply these 3 fields) body `{"PermissionsAccessEducationCloud":true, "PermissionsUseEducationCloudComp":true, "PermissionsAccessEducationCloudReview":true}`. Find `<Id>` by **Label**, not a hardcoded `Name` — some orgs show a legacy label (*Salesforce CDP Salesforce Connector Integration*, *Customer Data Platform Salesforce Connector Integration*, *Customer 360 Audiences Salesforce Connector Integration*) instead of "Data Cloud Salesforce Connector."
+  - **Verify (T1 `/query` → `sf` fallback):** `SELECT Id, Label, PermissionsAccessEducationCloud, PermissionsUseEducationCloudComp, PermissionsAccessEducationCloudReview FROM PermissionSet WHERE Label LIKE '%Salesforce Connector%'` — confirm all three read `true`.
+- 🟢 **TIER 1 (Connect REST over `dispatch`) — the Data Cloud data spine, in order:**
+  1. **Verify the 4 standard DMOs are pre-provisioned** — do NOT create them. `GET /services/data/vXX/ssot/data-model-objects/ssot__<Object>__dlm` (`ssot__LearningProgram__dlm`, `ssot__AcademicTerm__dlm`, `ssot__ProgramTermApplicationTimeline__dlm`, `ssot__ApplicationTimeline__dlm`) → 200, `creationType:Standard`. An unmapped DMO reads `isEnabled:false`; a mapped one flips to `isEnabled:true` with `isMapped:true` on each mapped field.
+  2. **Create the CRM data stream per object** — `POST /services/data/vXX/ssot/data-streams`, one object per call. Body:
+      ```json
+      {
+        "name": "<Object>_Home",
+        "connectorInfo": {
+          "connectorType": "SalesforceDotCom",
+          "connectorDetails": { "name": "SalesforceDotCom_Home", "sourceObject": "<CRMObjectApiName>" }
+        },
+        "dataLakeObjectInfo": {
+          "category": "Other",
+          "label": "<Object>_Home",
+          "name": "<Object>_Home__dll",
+          "dataspaceInfo": [ { "name": "default" } ]
+        }
+      }
+      ```
+      → 201; the DLO field list **auto-derives** from `sourceObject` (do not author fields). **Naming: use the connector default `<Object>_Home` / DLO `<Object>_Home__dll`** (NOT a custom `_SRA` suffix) so API-created and UI-created streams match and downstream references line up. **PTAT is the one exception — create it as `"name": "ProgramTermApplnTimeline_Home"`, `dataLakeObjectInfo.label`/`name`: `"ProgramTermApplnTimeline_Home"` / `"ProgramTermApplnTimeline_Home__dll"`** (the truncated CRM object spelling, not the full `ProgramTermApplicationTimeline`): Data Cloud provisions this one DLO under the truncated spelling regardless of what's requested, so asking for it directly keeps the name it's created under identical to the name every later step needs to reference. **Attempt create directly for each of the 4 objects — don't page through the existing streams list first.** The fixed naming above makes this safe: a duplicate-name error on create means that stream already exists → read it back, don't treat it as a failure (same idiom as the PermissionSet clone and Knowledge-library create above). **Body gotchas (each is a real 400):** no top-level `dataStreams` array wrapper; `connectorType` goes **inside** `connectorInfo`; do NOT include `connectorDetails.type` (output-only); exactly one of `dataLakeObjectInfo`/`existingDataLakeObjectInfo`; the dataspace key is `dataspaceInfo` (input side, entries take only `name` — the read side spells it `dataSpaceInfo` with `{label,name}`). `connectorDetails.name` `"SalesforceDotCom_Home"` is the OOTB CRM connector — if the org's differs, `GET /ssot/data-streams` and copy an existing SalesforceDotCom stream's `connectorDetails.name`.
+  3. **Never wait on `PROCESSING` here — always defer, unconditionally, with no status check at all yet.** A stream can only be PATCHed (step 4) while Active/Error/Inactive — `PROCESSING` happens right after creation, and again briefly after the step-4 PATCH — and how long it takes to clear scales with how much data is already in the org, so it's never safe to assume a quick check will catch it ready. **Move straight into step 9 (agent creation) without checking status even once here** — checking now only means polling in a loop or gambling on timing, and neither is worth it; narrate the deferral to the customer first, per SKILL.md's *Talking to the user*. **Steps 9 and 9a are one continuous unit for the customer (headless creation straight into their one Builder session) — don't break that up to check in between.** Check status for the first time at the end of step 9a, once that whole unit is done; if still `PROCESSING`, check again at the end of each subsequent step (10, 11, 12) — this must be complete, including the T3 index/retriever/prompt-template build, before step 13's final verify, which depends on it. Once all 4 read Active/Error/Inactive at one of those checkpoints, continue to step 4 then. **Do not attempt step 4 or step 5 in the same pass as creation, even opportunistically** — a stream created this turn is almost always still `PROCESSING`, and jumping ahead to `auto-map-dlos` (step 5) against it returns a not-found on the DLO. That not-found means "not ready yet," never "wrong name" — see the note on step 5 below.
+  4. **Fix Boolean/Date type mismatches (`AcademicTerm_Home` / `LearningProgram_Home` / `ApplicationTimeline_Home`).** The CRM connector always derives a source Boolean field as DLO type **Text** and a source Date field as DLO type **DateTime** — never the DMO's actual Boolean/Date. DMO mapping needs an exact type match, so these fields won't map until cast. Fix: `PATCH /services/data/vXX/ssot/data-streams/<streamName>` (write `dispatch`) with body `{"mappings":[{"targetFieldName":"<Name>__c","transformationFormula":"<expr>","targetFieldReturntype":"Boolean"|"Date"}, ...]}` — batch every field for a stream into the one array in a single PATCH. Two templates cover every field: **Boolean** — `IF(ISEMPTY(sourceField['<SourceField>']),null,IF(sourceField['<SourceField>'] == 'true', true, false))`; **Date** — `IF(ISEMPTY(sourceField['<SourceField>']),null,DAYPRECISION(sourceField['<SourceField>']))`. Apply:
+
+      | Stream | Target field | Type | Source field |
+      |---|---|---|---|
+      | `AcademicTerm_Home` | `Is_Active_Transformed__c` | Boolean | `IsActive` |
+      | `AcademicTerm_Home` | `Start_Date_Transformed__c` | Date | `StartDate` |
+      | `AcademicTerm_Home` | `End_Date_Transformed__c` | Date | `EndDate` |
+      | `LearningProgram_Home` | `Is_Active_Transformed__c` | Boolean | `IsActive` |
+      | `LearningProgram_Home` | `Is_Top_Level_Program_Transformed__c` | Boolean | `IsTopLevelProgram` |
+      | `LearningProgram_Home` | `Does_Create_Opportunity_Transformed__c` | Boolean | `DoesCreateOpportunityRecord` |
+      | `LearningProgram_Home` | `Active_From_Date_Transformed__c` | Date | `ActiveFromDate` |
+      | `LearningProgram_Home` | `Active_To_Date_Transformed__c` | Date | `ActiveToDate` |
+      | `ApplicationTimeline_Home` | `Application_Open_Date_Transformed__c` | Date | `ApplicationOpenDate` |
+      | `ApplicationTimeline_Home` | `Application_Close_Date_Transformed__c` | Date | `ApplicationCloseDate` |
+      | `ApplicationTimeline_Home` | `Decision_Release_Date_Transformed__c` | Date | `DecisionReleaseDate` |
+      | `ApplicationTimeline_Home` | `Graduation_Appln_Deadline_Transformed__c` | Date | `GraduationApplnDeadline` |
+      | `ApplicationTimeline_Home` | `Early_Action_Open_Date_Transformed__c` | Date | `EarlyActionOpenDate` |
+      | `ApplicationTimeline_Home` | `Early_Action_Close_Date_Transformed__c` | Date | `EarlyActionCloseDate` |
+      | `ApplicationTimeline_Home` | `Early_Application_Open_Date_Transforme__c` | Date | `EarlyApplicationOpenDate` |
+      | `ApplicationTimeline_Home` | `Early_Application_Close_Date_Transform__c` | Date | `EarlyApplicationCloseDate` |
+      | `ApplicationTimeline_Home` | `Early_Appln_Dec_Rel_Date_Transformed__c` | Date | `EarlyApplnDecisionRelDate` |
+
+      `ApplicationTimeline_Home` has no Boolean fields needing the cast — Date only, 9 fields, same template. **Only `Application_Open_Date_Transformed__c` and `Application_Close_Date_Transformed__c` back a return field the PTAT retriever actually uses** (Application Category, the 3rd return field sourced from Application Timeline, is a picklist and needs no cast); the other 7 exist on the object but aren't wired to a retriever field today — fix all 9 in the one PATCH regardless, so the mapping isn't left partially fragile.
+
+      `auto-map-dlos` (step 5) needs no further wait once this PATCH itself returns 200 — the brief `PROCESSING` it triggers (per step 3) clears on its own.
+  5. **Map the DLO to its standard DMO — all 4 in one pass, after step 4 lands for `AcademicTerm_Home`/`LearningProgram_Home`/`ApplicationTimeline_Home`.** Two Connect calls over the **write `dispatch`** (they are writes, so NOT `dispatch_readonly` — a `ROUTE_NOT_FOUND` here means the readonly dispatcher, not a version issue; use the org's current `vXX`, unless it's below this surface's documented floor — see `execution-model.md`):
+      1. Precheck: `POST /services/data/vXX/ssot/simple-start/sobject-recommendations` body `{"sobjectNames":["LearningProgram","AcademicTerm","ProgramTermApplnTimeline","ApplicationTimeline"]}` → 201, each returns `category:"Related"` (confirms they're opinionated/auto-mappable objects). **WARNING:** `sobjectNames` takes **source platform sObject** API names (like `LearningProgram`/`AcademicTerm`), so the PTAT entry is the **truncated** `ProgramTermApplnTimeline` — NOT the DMO's full-spelling `ssot__ProgramTermApplicationTimeline__dlm` (different surface — see `permissions.md`); `ApplicationTimeline` needs no such truncation. The full spelling does **not** error: the call still returns 201 but that object comes back **without a `category` field** (unrecognized), so it silently drops from the mapping. Send the truncated PTAT name and confirm every object echoes `category:"Related"`.
+      2. Map: `POST /services/data/vXX/ssot/simple-start/auto-map-dlos` body `{"dloNames":["<Object>_Home__dll"]}` → 201 `{"mappedDloNames":[...]}`. **CRITICAL: ONE DLO per call** — passing 2+ names → 500 INTERNAL_ERROR. Loop the objects, including `ProgramTermApplnTimeline` — it needs no step 4, but map it in this same pass rather than earlier; nothing downstream needs it before the other three are ready. **If a call 404s / reports the DLO not found, use the exact name each stream was created under in step 2** (PTAT's is the truncated `ProgramTermApplnTimeline_Home__dll` — see step 2) — there's nothing else to look up. A not-found on the right name means that stream is still `PROCESSING` (step 3) and hasn't materialized yet; re-verify with `GET /ssot/data-streams/<name>` if needed, then defer this one DLO's mapping to the next status checkpoint (per step 3) rather than paging through the streams list.
+  - Together, steps 1–5 = the **complete T1 grounding spine** — the bundle-deploy UI path is NOT required for these opinionated EDU objects. The mapping lands as `isMapped:true` on the DMO field metadata (the stream's `mappings[]` stays `[]` even when fully mapped — don't check there).
+- **CRITICAL: TIER 3 (Setup UI) — no supported public API.** This whole leg is a hand-off: walk the customer through the Setup UI screen by screen rather than handing them this section's API/DMO vocabulary — name what a screen or field does for the agent ("this is the field the agent uses to tell students the term name"), not its dev name, matching the register in SKILL.md's *Talking to the user*. The exact field lists and filter below are what to translate live, not a script to read verbatim.
+  - **Build the hybrid-search index — 2 builds, not 3.** Data Cloud → Search Index → New → **Easy Setup** → pick the DMO → Save. Easy Setup ⇒ Search Type = **HYBRID**, auto-creates the chunk DMO + vector/index DMO, and auto-selects the fields to chunk — but **filtering fields are a separate, manual pick on this same Easy Setup screen, not automatic**, and there is no supported way to add one after Save. Set every filtering field listed below for the DMO being built, in this pass — an index saved without one can't be retro-fitted, so the retriever built on top of it will be permanently missing that filter option. Builds on Save — no separate build action. (A raw `POST /ssot/search-index` route exists but requires pre-authoring the chunk DMO/vector DMO/chunking config/embedding model Easy Setup derives in one click, and 500s if those don't pre-exist — not worth it vs. the 3-click UI; treat index create as **T3 Easy Setup**.) Field configuration, both hybrid, both embedding model **E5 Large V2**:
+    - **Learning Program** (DMO `ssot__LearningProgram__dlm`): 8 chunked/text fields (Passage Extraction) — Name, Academic Level, Cip Code, Description, Duration Unit, Learning, Provider, Short Description; 1 filtering field — Data Source.
+    - **Program Term Application Timeline** (DMO `ssot__ProgramTermApplicationTimeline__dlm`): 4 chunked fields — Academic Term Id, Application Timeline Id, Learning Program Id, Name; 3 filtering fields — Academic Term > Is Active, Learning Program > Learning Program Id, Data Source.
+    - Academic Term gets **no index of its own** — do not build one; its template grounds on the PTAT retriever below.
+  - **Create the retriever — 2 builds, not 3 — Einstein Studio Individual Retriever.** Retriever create/read has **NO API surface** (every `/ssot/retrievers`, `/connect/retrievers`, and `AiRetriever` tooling route 404s), so this is T3-only with no API existence check. Click-path: Data Cloud → **Einstein Studio → Retrievers tab → New Retriever → Individual Retriever** → Next → source = **Data Cloud**, data space = **default**, DMO + search index from the matching build above → Next → filters (see below) → **Configure Retriever Results** (see below) → Save → name it → **Activate** (quick action, upper-right). **CRITICAL: Retriever API names are auto-generated and non-deterministic** (pattern `<Name>_1Cx_yZB<8 hex>`) — cannot be hardcoded; read the API Name back from the retriever detail page (Overview → Retriever Details → API Name) to wire the template. Configuration:
+    - **Learning Program Retriever**: DMO Learning Program, no filters, 20 results, citations Off. Return fields (Direct Attributes → Learning Program): **Name, Learning Program Id**.
+    - **Program Term Application Timeline Retriever**: DMO PTAT, filter **`Is Active` Equal To `TRUE`** AND **`Learning Program Id` Equal To `{!$Learning_Program_Id}`** (the 2nd condition is marked **Dynamic**), 20 results, citations Off. Return fields (6, several via related-object lookups): **Academic Term Name** (Academic Term → Name), **Program Term Application Timeline Id**, **Application Open Date** (Application Timeline → Application Open Date), **Application Close Date** (Application Timeline → Application Close Date), **Application Category** (Application Timeline → Application Category), **Academic Term Id** (Academic Term → Academic Term Id). This one retriever backs both the Academic Term and PTAT rows in the table above.
+  - **Edit the prompt template to wire each retriever (T3 manual) — 3 templates, 2 retrievers.** Open each of the 3 base templates in Prompt Builder — **editing a managed `sturecruitment` template spawns a local `*_Override` template** (e.g. `getLearningPrograms_Override`, `IsOverride:true`, `ManageableState:unmanaged`); the base stays managed/read-only and gets `OverriddenTemplates:[...]`. Wire the retriever at its `PLACEHOLDER_FOR_DATA_RETRIEVER` line via **Insert Resource → Search → `<object>` → `<retriever>`** — the picker resolves the retriever **by label** so the customer never types the non-deterministic API suffix. If the picker isn't used, paste the API Name copied from the retriever detail page. Wiring per template:
+    - `getLearningPrograms` → **Learning Program Retriever**; Data Model Object **Learning Program**; search text `Input:learningProgramName`.
+    - `getAcademicTerms` → **Program Term Application Timeline Retriever**; Data Model Object **Program Term Application Timeline**; search text `Input:academicTermName`; pre-filter `Learning Program.Learning Program Id` Equal `Input:learningProgramId`.
+    - `getApplicationTimelines` → same retriever, DMO, and pre-filter as `getAcademicTerms`; search text `Input:academicTermName`.
+    Save & Activate. The wiring produces two changes: the Content placeholder becomes `{!$EinsteinSearch:<RetrieverApiName>.results}`, and a `GenAiPromptTemplateDataProvider` child is added (params `searchText` = `{!$Input:<inputParam>}`, `outputFieldNames` = JSON array of the retriever's return fields, `resultCount`). Sequence: build+activate the retriever FIRST, then wire the template(s) that use it — build the PTAT retriever once, then wire both `getAcademicTerms` and `getApplicationTimelines` to it. (No viable clone/create-automation for the override — the create body schema is unpublished; do it in Prompt Builder.)
+
+> **WARNING: There is NO tier-2 `sf project deploy` path for grounding metadata** — `DataLibrary`/`SearchIndex`/`AIRetrieverDefinition`/`DataSemanticSearch`/`GenAiPromptTemplate`-retriever-wiring are not in the supported-metadata-type index, and MDAPI deploy does NOT build the index. Do not present tier 2 as a path for Mechanism 2. Attempt T1 for the data spine; everything downstream is T1-verify-only around a T3 UI build.
+
+### T1 verify — per leg (each has a different surface; the retriever has NONE)
+
+Most of the spine is verifiable at tier 1, but the surfaces differ by leg — do not use one query for all:
+
+- **DMO mapped (data spine):** `GET /services/data/vXX/ssot/data-model-objects/ssot__<Object>__dlm` (dispatch_readonly) → assert `isEnabled:true` and the required fields show `isMapped:true`.
+- **Search index built:** `GET /services/data/vXX/ssot/search-index` (list) or `GET .../ssot/search-index/<developerName>` (dispatch_readonly) → poll `runtimeStatus == "READY"` before wiring the retriever (a just-created index reads `null` while indexing, then flips to READY on its own).
+- **Retriever: NO API existence check exists** (create/read have no API surface — see the T3 bullet). The retriever is **not** a Tooling sObject; do **not** attempt `SELECT ... FROM AIRetrieverDefinition`/`AiRetriever` (404s). Verify in the UI: Einstein Studio → Retrievers list shows it **Active**, and copy its API Name from the detail page.
+- **Prompt template wired (T1):** `GET /services/data/vXX/einstein/prompt-templates/<devName>` (dispatch_readonly) → assert the active version's `Content` contains `{!$EinsteinSearch:<RetrieverApiName>.results}` and that a `GenAiPromptTemplateDataProviders` child with `Definition: invocable://getEinsteinRetrieverResults/<RetrieverApiName>` is present. (`GET .../einstein/prompt-templates` lists all.)
+
+### Caveats
+
+- **Keep the two index surfaces separate.** The Knowledge-sourced library (Mechanism 1) and the Data Cloud hybrid index (Mechanism 2) are distinct — do not attempt to share one index across both.
+- **The prompt-template retriever wiring is a T3 UI step, but its verify is T1.** There is no supported Connect endpoint/body for inserting a retriever into a prompt template (the create-body schema is unpublished) — do the wiring in Prompt Builder. **Verify** it, though, with the tier-1 `GET /einstein/prompt-templates/<devName>` assertion above (Content merge field + `GenAiPromptTemplateDataProviders` child), not just a retriever read-back.
+- **CRITICAL: DLO→DMO mapping of Boolean/Date fields is fragile — verify it, don't assume auto-map alone is enough.** `auto-map-dlos` leaves Boolean- and Date-sourced fields unmapped until the formula-field fix above is applied (the CRM connector derives them as Text/DateTime on the DLO, which won't type-match the DMO). Verify these mappings hold:
+  - **AcademicTerm (`ssot__AcademicTerm__dlm`)** — `ssot__Name__c` (= `Academic_Term_Name`) plus season map correctly out of the box; `IsActive`, `StartDate`, `EndDate` do not (Text/DateTime on the DLO) — need the Boolean/Date formula-field fix above before they'll map.
+  - **LearningProgram (`ssot__LearningProgram__dlm`)** — same story, 5 fields (`IsActive`, `IsTopLevelProgram`, `DoesCreateOpportunityRecord`, `ActiveFromDate`, `ActiveToDate`) — same fix, see the table above.
+  - **ApplicationTimeline (`ssot__ApplicationTimeline__dlm`)** — same story, 9 Date fields (no Booleans on this object) — `ApplicationOpenDate`, `ApplicationCloseDate`, `DecisionReleaseDate`, `GraduationApplnDeadline`, `EarlyActionOpenDate`, `EarlyActionCloseDate`, `EarlyApplicationOpenDate`, `EarlyApplicationCloseDate`, `EarlyApplnDecisionRelDate` — same fix, see the table above.
+
+### Verify (either mechanism)
+
+Step-13 conversational smoke test (user-run in the deployed channel) — the agent returns a Learning-Program-grounded (and Academic-Term / PTAT-grounded) answer to a program query, and a Knowledge-grounded answer to an FAQ query.

package/skills/education-cloud-student-recruitment-agent-configure/references/permissions.md

@@ -0,0 +1,183 @@
+# Permissions & sharing foundation
+
+Read at Workflow steps 4–6, 9 & 10. Each create/change here walks the **three-tier ladder** (see `execution-model.md`): **tier 1** `/headless/metadata` if the type is allowlisted, else **tier 2** `sf`-deploy of local source (needs a shell), else **tier 3** Setup-UI. The tier per operation is called out below. Every step ends in a **concrete verify call** so the agent confirms org state after the change — do not assume success.
+
+> **Tiering summary.** **OWD** (`CustomObject` `sharingModel`), **RecordType** create, `ApplicationRecordTypeConfig`, and the **Campaign Type picklist value** all have a **tier-1** path; only **sharing-rule create** and **record-type→profile visibility** are tier-3 gaps. **SOQL `/query`/`/tooling/query` route over `dispatch_readonly` (tier 1)** — so every verify below is a tier-1 attempt first, with `sf` (tier 2) / UI as the fallback (including for a transient `/query` outage window — see `execution-model.md`).
+
+- **`PermissionSet` is on the `/headless/metadata` allowlist (CRUD).** But the **cloning path used here is plain sObject REST + the collections API, not `/headless/metadata`** (see Step 4b): `POST /sobjects/PermissionSet` → `POST /composite/sobjects` for the object/field-perm rows → `POST /sobjects/PermissionSetAssignment`. All tier 1, granular, per-row errors.
+- **OWD (`CustomObject` `sharingModel`) — TIER 1.** `PUT /services/data/vXX/headless/metadata` with `{type:"CustomObject", fullName:"<obj>", xmlRep:"<CustomObject …><sharingModel>Read</sharingModel></CustomObject>"}` → `200 {success:true}`. Only **internal** OWD is set (external stays Private). **`ActionPlanTemplate` is the one exception — tier-3-UI-only**; see Step 5 for the root cause and the don't-hardcode rule.
+- **`RecordType` create — TIER 1.** `POST /services/data/vXX/tooling/sobjects/RecordType` with the **nested** body `{FullName:"<Obj>.<DevName>", Metadata:{active:true, label:"<Label>"}}` → 201. A `400 JSON_PARSER_ERROR` means the body used flat columns instead of the nested `Metadata` object — fix the shape, don't fall back. See Step 6.
+- **Campaign `Type` picklist value — TIER 1.** `PUT /headless/metadata type:StandardValueSet fullName:CampaignType` (whole-set replace). See Step 6.
+- **Sharing-rule create is a tier-1/2 gap → tier-3 UI.** See Step 6b for the exact error and why the sibling deploy skills can't help either.
+- **Record-type→profile visibility is a tier-3-UI step** (tooling PATCH on `Profile` is unsupported; the only API write is a whole-file `Profile` MDAPI replace, too high-blast-radius for a 3-click task). See Step 6.
+
+## Configure vs. verify at a glance
+
+| Step | Operation | Best tier | **Verify call** |
+|---|---|---|---|
+| 4a | Assign the **Admin/builder** persona's sets (the AI Agent Access **clone** goes to the Einstein Agent User at **step 9**, not here — that user doesn't exist until Claude creates it as part of step 9) | **T1** — `PermissionSetAssignment` sObject POST | query PSA (below) — attempt T1 `/query`, `sf` fallback |
+| 4b | Clone + customize `EducationCloudAiAgentAccess` (**required** — OOTB set is an empty shell) | **T1** — sObject `POST /sobjects/PermissionSet` + `/composite/sobjects` for obj/field perms + PSA POST (NOT `/headless/metadata`) | query the cloned PS + its perms (below) |
+| 5 | OWD → Public Read Only on 6 objects | **T1** — `PUT /headless/metadata CustomObject sharingModel` (5/6); **`ActionPlanTemplate` is T3-UI-only** (`IsCustomizable=false`) | tooling query `EntityDefinition.InternalSharingModel` — attempt T1 `/tooling/query`, `sf` fallback |
+| 6a | Campaign "Recruitment Event" picklist value | **T1** — `PUT /headless/metadata StandardValueSet:CampaignType` (whole-set replace) | query picklist value (below) |
+| 6b | Campaign "Campus Tours" sharing rule | **T3** — `SharingCriteriaRule`/`SharingOwnerRule` CREATE is a real MDAPI gap (fails at T1 AND `sf`) → UI | query sharing rule (below) |
+| 6c | Individual Application record type | **T1** — `POST /tooling/sobjects/RecordType` nested `{FullName,Metadata}` | query `RecordType` (below) |
+| 6d | `ApplicationRecordTypeConfig` (registers the RT into the admissions feature) | **T1** — `POST /tooling/sobjects/ApplicationRecordTypeConfig` | tooling query `ApplicationRecordTypeConfig` (below) |
+| 6e | Record type → profile visibility (3 profiles) | **T3** — tooling PATCH on `Profile` unsupported; only API write is whole-file `Profile` MDAPI replace (too risky) → UI | tooling GET Profile `recordTypeVisibilities` (below) |
+
+## Step 4 — Clone, customize, and assign the Education Cloud AI Agent Access permission set
+
+> **CRITICAL: DO NOT assign the OOTB `EducationCloudAiAgentAccess` — it is an EMPTY SHELL.** The standard set (one of the 5 canonical EDU standard permission sets) ships with **0 object perms, 0 field perms, every `Permissions*` boolean false**. Assigning it to the Einstein Agent User grants **nothing**, yet reads like the agent has Education Cloud access — actively misleading. It exists to be **cloned FROM**. So **4b (clone + customize) is REQUIRED, not optional.** **CRITICAL: Order within Step 4: assign the Admin/builder persona to the running user FIRST (4a), THEN build the clone (4b)** — the builder sets (especially *Education Cloud Full Access* + *Einstein for Education Cloud Access*) are what make the **license-gated EDU object fields visible** to the running admin; without them the objects show **0 fields** in Object Manager and 4b's field-matrix build has nothing to reference. Only the clone's **Einstein-Agent-User** assignment is deferred to step 9 (that running user doesn't exist until agent creation at that step).
+
+**Step 4a (DO THIS FIRST — before building the clone in 4b) — Assign the Admin/builder persona to the running user; DEFER the clone's Einstein-Agent-User assignment to step 9 (T1, concrete call):**
+
+The clone's assignment to the **Einstein Agent User** cannot happen at step 4 — that running user doesn't exist yet, and Claude creates + grants it directly at **step 9** (see `agent-and-subagents.md` step 9, points 2–3; the full mechanism lives there, not here). What to do **here, before building the clone**: assign the **Admin/builder** persona's sets to the running user so the human can build — critically *Education Cloud Full Access* and *Einstein for Education Cloud Access*, which unlock visibility of the **license-gated EDU object fields**. **CRITICAL: Symptom if 4b runs first:** see the note above — assign these two sets first, then clone.
+
+- **Tier 1 (headless):** `POST /services/data/vXX/sobjects/PermissionSetAssignment` via the write-enabled `dispatch` tool, one row per builder set, body `{ "AssigneeId": "<builderUserId>", "PermissionSetId": "<psId>" }`. sObject REST routes over dispatch. (`DUPLICATE_VALUE` on re-assign is benign/idempotent.)
+- **Tier 2 (`sf` CLI, if a shell is present):** `sf org assign permset --name <builder set> --target-org <alias>`.
+- **Tier 3 (manual):** Setup → Permission Sets → the set → Manage Assignments → Add Assignment → the builder user.
+
+**Verify (attempt T1 `/query` over `dispatch_readonly` → `sf` fallback):**
+```bash
+# Tier 2 fallback:
+sf data query -q "SELECT PermissionSet.Name, PermissionSet.Label FROM PermissionSetAssignment WHERE AssigneeId = '<builderUserId>'" --target-org <alias>
+```
+Confirm a row for each Admin/builder set from the persona table below (Agentforce Default Admin, Education Cloud Full Access, Einstein for Education Cloud Access, etc.) — a set missing from the results means the assignment didn't take.
+
+**Step 4b — Clone + customize the full matrix (T1, sObject REST — NOT `/headless/metadata`):**
+
+The tier-1 path is plain sObject REST + the collections API — cleaner and more granular than a metadata deploy:
+
+1. **Create the clone** — `POST /services/data/vXX/sobjects/PermissionSet` body `{Name:"SRA_AI_Agent_Access", Label:"Education Cloud AI Agent Access (Student Recruitment Agent)", Description:"…", PermissionsAccessEducationCloud:true, PermissionsUseEducationCloudComp:true, PermissionsActionPlansUserAccess:true}` → 201. **Use the fixed `Name` `SRA_AI_Agent_Access`** (`Name` is the PermissionSet API/developer key — there is no separate `developerName` field on this sObject) so step 9 and the verify below re-find it by **exact `Name`, not a fuzzy `LIKE`**; a `DUPLICATE_DEVELOPER_NAME` on re-run means it already exists → read it back, don't treat as failure. **The three "system permissions" are boolean COLUMNS on the PermissionSet record**, set inline at create: *Access Education Cloud Objects* = `PermissionsAccessEducationCloud`; *Access Education Cloud Components* = `PermissionsUseEducationCloudComp`; *Access the Action Plans feature* = `PermissionsActionPlansUserAccess`. (Do NOT hunt for `CustomPermission`/`SetupEntityAccess` — wrong surface.)
+2. **Object perms** — `POST /services/data/vXX/composite/sobjects` (`allOrNone:false`) with one `ObjectPermissions` row per object. Row shape: `{"attributes":{"type":"ObjectPermissions"}, "ParentId":"<clonePsId>", "SobjectType":"AcademicInterest", "PermissionsRead":true, "PermissionsCreate":true}` (omit or set `false` the perms you don't grant; `PermissionsRead` is required for any other object perm). **CRITICAL: `EducationalInfoRequest` Read requires `Case` Read** (`FIELD_INTEGRITY_EXCEPTION: depends on Read Case`) — the SRA help doc's object list omits `Case`; **add it**. Objects (all R unless noted): AcademicInterest (C,R), Account (C,R), AcademicTerm, ActionPlan, ActionPlanTemplate, ApplicationStageDefinition, ApplicationTimeline, Campaign, Contact, ContactRequest, EducationalInfoRequest, IndividualApplicationTask, Learning, LearningProgram, `PreliminaryApplicationRef`, `ProgramTermApplnTimeline`, **+ `Case` (R)**. (17 objects — the 16 above plus `Case`; `/composite/sobjects` caps at 200 rows/call, so one call covers all.)
+3. **Field perms** — `POST /services/data/vXX/composite/sobjects` (`allOrNone:false`) with one `FieldPermissions` row per field. Row shape: `{"attributes":{"type":"FieldPermissions"}, "ParentId":"<clonePsId>", "SobjectType":"AcademicInterest", "Field":"AcademicInterest.ReceivedDate", "PermissionsRead":true, "PermissionsEdit":true}` — **CRITICAL: `SobjectType` is its own required column, even though `Field` is already fully-qualified** — omitting it 400s; it is not redundant with `Field`. `Field` is the fully-qualified `SobjectType.FieldName`, and `PermissionsEdit:true` requires `PermissionsRead:true` on the same row. Fields (R = `PermissionsRead` only; R+E = both): AcademicInterest{AcademicTermId, AccountId, ContactId, ContactRequestId, EducationalInfoRequestId, LearningProgramId, ReceivedDate, Subscription}=R+E; AcademicTerm{IsActive, StartDate}=R; ApplicationTimeline{ApplicationCategory, ApplicationCloseDate, ApplicationCloseDateTime, ApplicationOpenDate}=R; Contact{AccountId}=R; IndividualApplicationTask{ApplicationStageDefinitionId}=R; Learning{AcademicLevel}=R; LearningProgram{AcademicLevel, IsActive}=R; ProgramTermApplnTimeline{AcademicTermId, ActionPlanTemplateVersionId, ApplicationTimelineId, LearningProgramId}=R.
+
+> **CRITICAL: API-name traps (fail hard on a wrong `SobjectType`/`Field`):** "Preliminary Application Reference" → **`PreliminaryApplicationRef`** and "Program Term Application Timeline" → **`ProgramTermApplnTimeline`** (both truncated — full spellings 404). Use exact API names; resolve field API names via `/sobjects/<Obj>/describe` (label→name) rather than `FieldDefinition` queries, which can 404 for metadata-entity lookups.
+
+**Verify the clone was built correctly (attempt T1 `/query` over `dispatch_readonly` → `sf` fallback):**
+```bash
+# Tier 1 first (dispatch_readonly): GET /services/data/vXX/query?q=<the SOQL below, URL-encoded>
+# Tier 2 fallback:
+sf data query -q "SELECT Id, Name, Label, IsCustom, PermissionsAccessEducationCloud, PermissionsUseEducationCloudComp, PermissionsActionPlansUserAccess FROM PermissionSet WHERE Name = 'SRA_AI_Agent_Access'" --target-org <alias>
+```
+Confirm the clone is `IsCustom:true` with all three system booleans true (`PermissionsAccessEducationCloud`, `PermissionsUseEducationCloudComp`, `PermissionsActionPlansUserAccess`). The clone→Einstein-Agent-User PSA (and its `PermissionSetAssignment WHERE PermissionSet.Name = 'SRA_AI_Agent_Access'` verify) is confirmed at **step 9**.
+
+That query only confirms the 3 system booleans on the parent `PermissionSet` row — it never checks that the 17 `ObjectPermissions` and 23 `FieldPermissions` child rows from points 2–3 above actually landed (the `/composite/sobjects` calls are `allOrNone:false`, so a partial failure on some rows returns `200` alongside the successful ones). Verify those too:
+```bash
+sf data query -q "SELECT SobjectType FROM ObjectPermissions WHERE ParentId='<clonePsId>'" --target-org <alias>
+sf data query -q "SELECT Field FROM FieldPermissions WHERE ParentId='<clonePsId>'" --target-org <alias>
+```
+Expect **17** `ObjectPermissions` rows (the 16 objects + `Case`) and **23** `FieldPermissions` rows. A short count means some rows 400'd silently in the composite call — check each row's `errors[]` in the original response before re-sending just the missing ones.
+
+> **Do NOT clone per-subagent.** Clone the permission set **once** and assign that single clone. A per-subagent object/field breakdown (Create Admissions Application / Campus Tours / FAQ / Escalation) is useful only as a field-level reference for what each subagent touches — it must never become a series of setup steps or separate clones.
+
+### Three-persona permission model (this is the correct model to encode)
+
+Permissions map to **three distinct user personas**, not one:
+
+| Persona | Who | Permission sets |
+|---|---|---|
+| **Admin / builder** | The human setting up + owning the agent | Agentforce Default Admin; Education Cloud Full Access; Einstein for Education Cloud Access; **(Legacy) Data Cloud Marketing Admin** (API name `GenieMarketingAdmin` — the label resolves to the *Legacy* set; the non-legacy Data Cloud sets are Admin/Architect/Activation, a different grant); Prompt Template Manager + User; Knowledge (Lightning Knowledge Manager). PSL: Messaging — **WARNING:** the label "Messaging for In-App and Web User" is **ambiguous**: `EasyServiceMessagingSessionPsl` ("Messaging User") vs `EmbeddedServiceMessagingUserPsl` ("Enhanced Chat User"); pick per the org's messaging setup and assign by **API name**, not label. |
+| **Einstein Agent User** (the Digital/Agent User the ASA agent runs as — **ASA/Service path only**; the AEA agent has no service account) | The service account the Service agent acts under | The full parity set required for this restricted-license user: **6 PermissionSetLicenses** (`PermissionSetLicenseAssign`, assign first — this restricted-license user's other assignments fail `FIELD_INTEGRITY_EXCEPTION` without them): `AgentforceServiceAgentUserPsl`, `EducationCloudAiAgentUserPsl`, `AgentforceServiceAgentBuilderPsl`, `EinsteinGPTPromptTemplatesPsl`, `EasyServiceKnowledgeBasePsl`, `GenieDataPlatformStarterPsl`. **8 PermissionSetAssignments**: `AgentforceServiceAgentBase`, `AgentforceServiceAgentUser`, `AgentforceServiceAgentBuilder`, `ServiceLightningKnowledgeManager`, `EinsteinGPTPromptTemplateUser`, `GenieUserEnhancedSecurity`, `RunFlow`, and the **`SRA_AI_Agent_Access` clone** from step 4b (NOT the OOTB `EducationCloudAiAgentAccess` set — see the CRITICAL note above). Without the full 14-grant set, `publish`/Commit Version fails with a generic *"User doesn't have access to agent"* — a sharing-flavored message that is actually a missing-license/permission-set problem. |
+| **Community user** (authenticated Experience Cloud path — **AEA agent only**) | Authenticated prospective students on the community | Clone of `EducationCloudExprcCloudAccess` — create with the **fixed `Name` `SRA_Exprc_Cloud_Access`**, Label "Education Cloud for Experience Cloud Access (Student Recruitment Agent)" (re-find by exact `Name`, same rule as the AI Agent Access clone) — with the **Run Flows** app perm (`PermissionsRunFlow`) set on the clone; **plus separate PS assignments** (not clone settings): **Prompt Template User**, Knowledge, Data Cloud starter. **This whole persona is AEA/auth-path only** — the ASA/Service agent runs under the Einstein Agent User, so an ASA-only build skips it. **Clone + config at Step 4** (same as the Einstein clone); the **Enable Agent Access → AEA agent** selection and the assignment to community users happen at **step 10** (both need the agent to exist). **Clone target differs by path** (see below). |
+
+Each persona's *assignment* is a tier-1 `PermissionSetAssignment` POST (or `sf org assign permset` at tier 2) once the sets exist. The community-user PSL *clone* (AEA path) uses the same **tier-1 sObject-REST path as step 4b** (`POST /sobjects/PermissionSet` + `/composite/sobjects`), with `sf`-deploy / UI as tier-2/3 fallbacks (see below).
+
+**Before the Step 4a assignment above, self-resolve the running user's Id at tier 1 — don't presuppose you already know your own display name.** A `/query WHERE Name='<current user>'` only works once something has already told you that name; when nothing has, resolve identity via the current-user/"me" lookup your runtime exposes (discover it if you don't already know which one) rather than guessing at a `WHERE` clause you can't populate yet, then reuse that Id directly. (Routes over `dispatch_readonly`.)
+
+**Resolve Ids, then select interactively — do NOT blindly assign all three personas.** Many orgs already carry some of these sets, and the two agent-dependent personas (whichever agent paths are in scope) can't be assigned at Step 4 — they're deferred until the agent exists (Einstein Agent User at step 9, community persona at step 10 — see the sequencing below):
+
+1. **Resolve the Einstein Agent User's Id from `BotDefinition`, not by profile.** The **Einstein Agent User exists only for the ASA/Service agent** (the AEA/Employee agent has no service account — authenticated community users invoke it as themselves). Since step 9 creates this user itself and knows its Id directly, there's no need to query it back before granting — `SELECT BotUserId FROM BotDefinition WHERE DeveloperName='<ASA agent>'` is a **verify**, not a discovery step, once step 9 is done, and should read back the exact user Id step 9 created and granted. Do **not** resolve it by `WHERE Profile.Name='Einstein Agent User'` (it can match other digital-agent users in the org). A **null** `BotUserId` at verify time means the sentinel substitution was skipped in step 9 — fix that, not an expected state. (Routes over `dispatch_readonly`.)
+2. **Ask the customer which personas/users to assign** — all three, or a subset — rather than assuming. Then assign per their selection.
+3. **Skip duplicates** — a `DUPLICATE_VALUE` error on an existing assignment is benign/idempotent; don't treat it as a failure.
+4. **Sequencing — only the Admin/builder persona is assigned at Step 4; the other two are agent-dependent.** Einstein Agent User grant → step 9; community agent-access-enable + user assignment → step 10. See the persona table above for what each grant is and why — same fact, not a new one.
+
+### The unauthenticated path has NO guest user — do not build a guest PSL
+
+The Service (ASA) path runs entirely under the **Einstein Agent User** service account (the three-persona model above); there is **no guest/unauthenticated Salesforce user in the SRA model**, so do **not** clone or assign a guest permission-set license (e.g. `EducationCloudGuestAccessPsl`). The ASA's Education Cloud access is the `SRA_AI_Agent_Access` clone of `EducationCloudAiAgentAccess` (built step 4b), assigned to the agent's running user at step 9. The only cloned community set is for the **authenticated** path:
+
+- **Authenticated community (AEA only)** → clone `EducationCloudExprcCloudAccess`; its license is `EducationCloudExprcCloudAccessPsl`.
+
+## Step 5 — OWD (internal) → Public Read Only on 6 objects
+
+Set internal OWD to **Public Read Only** on exactly these 6:
+
+1. Academic Interest
+2. Academic Term
+3. Action Plan Template
+4. Application Timeline
+5. Learning
+6. Program Term Application Timeline
+
+**NOT** Learning Program (it's `ControlledByParent` — can't set OWD on a child-controlled object), **NOT** Campaign (Campaign uses a sharing rule instead — step 6). **NOT** Individual Application (it gets RecordTypes at step 6, not OWD).
+
+> **CRITICAL: API-name correction:** the 6th object's real API name is **`ProgramTermApplnTimeline`** ("Application"→"Appln"), NOT `ProgramTermApplicationTimeline`. The full spelling doesn't exist as an entity, so a verify query using it silently returns 0 rows for that object → the customer thinks OWD is set when the object was never touched. (Note the sibling `ApplicationTimeline` keeps its full spelling — only the compound name is truncated.)
+
+- 🟡 **OWD (`CustomObject` `sharingModel`) — attempt Tier 1, but confirmed to fail org-wide on at least one gateway.** `PUT /services/data/vXX/headless/metadata` body `{type:"CustomObject", fullName:"<obj>", xmlRep:"<CustomObject xmlns=\"http://soap.sforce.com/2006/04/metadata\"><sharingModel>Read</sharingModel></CustomObject>"}` → attempt for all 6 objects. Only **internal** OWD is set; `ExternalSharingModel` stays Private (intended). Cold-verify the write with the read below — a `200`/`success:true` alone is not proof the value changed. ⚠️ **Confirmed failure mode:** on some orgs, ALL 6 — not just `ActionPlanTemplate` — return `400 UNSUPPORTED_OPERATION: MetadataCrud does not support UPDATE on type: CustomObject`, including a retry using `externalSharingModel` instead of `sharingModel`. On this exact error, drop straight to Setup UI for all 6 — don't retry reshaped, and don't assume the other 5 are fine just because they're not `ActionPlanTemplate`.
+  - **CRITICAL: `ActionPlanTemplate` has its own, separate, always-true exception → T3-UI-only regardless of the above.** Root cause: `EntityDefinition.IsCustomizable=false` (the other 5 are `true`) — MDAPI rejects it as a "non-customizable CustomObject" (`500`), and `sf` hits the identical wall. This is a *different* failure than the blanket `UNSUPPORTED_OPERATION` above — object-specific, not gateway-specific — so `IsCustomizable` alone doesn't predict the broader failure; check it only to confirm this one exception.
+  - **Tier 2 (`sf`, fallback):** deploy each object's `sharingModel = Read` via `sf project deploy start`.
+  - **Tier 3 (manual):** Setup → Sharing Settings → Edit → set the object's Default Internal Access to **Public Read Only** → Save.
+
+**Verify OWD (attempt T1 `/tooling/query` over `dispatch_readonly` → `sf` fallback):** **WARNING:** `EntityDefinition` **rejects disjunctions** (`WHERE … OR …` → `400 MALFORMED_QUERY: Disjunctions not supported`) — use an `IN (...)` list (below) or separate filtered queries.
+```bash
+# Tier 1 first (dispatch_readonly): GET /services/data/vXX/tooling/query/?q=<the SOQL below, URL-encoded>
+# Tier 2 fallback:
+sf data query --use-tooling-api -q "SELECT QualifiedApiName, InternalSharingModel, ExternalSharingModel, IsCustomizable FROM EntityDefinition WHERE QualifiedApiName IN ('AcademicInterest','AcademicTerm','ActionPlanTemplate','ApplicationTimeline','Learning','ProgramTermApplnTimeline')" --target-org <alias>
+```
+Confirm `InternalSharingModel = 'Read'` for all 6. (Note `ProgramTermApplnTimeline` — the corrected API name.)
+
+## Step 6 — Topic-specific prep
+
+### 6a — Campaign "Recruitment Event" picklist value (Campus Tours) — 🟡 Tier 1 attempt (confirmed org-dependent)
+Add a **"Recruitment Event"** value to Campaign **Type** (backing set `StandardValueSet:CampaignType`).
+- **Tier 1:** `PUT /services/data/vXX/headless/metadata`, `type:StandardValueSet`, `fullName:CampaignType`, `xmlRep` listing **all existing values + Recruitment Event** → `200 {success:true}`. **WARNING: Whole-set-replace semantics — you MUST echo every existing value** or the omitted ones are deleted. Read current values first (e.g. `ui-api/object-info/Campaign/picklist-values/{rtId}/Type`). ⚠️ **Confirmed failure mode:** both this write and a direct read (`GET .../headless/metadata?type=StandardValueSet&fullName=CampaignType`) can 400 `UNSUPPORTED_OPERATION: MetadataCrud does not support READ/UPDATE on type: StandardValueSet` on some orgs. On that error, go straight to Tier 2/3 — don't retry reshaped.
+- **Tier 2/3 fallback:** `sf`-deploy the `StandardValueSet` source, or Setup → Object Manager → Campaign → Fields → Type → New value.
+
+**Verify (attempt T1 `/query` → `sf` fallback):**
+```bash
+# Tier 2 fallback:
+sf data query --use-tooling-api -q "SELECT Metadata FROM FieldDefinition WHERE EntityDefinition.QualifiedApiName='Campaign' AND QualifiedApiName='Type'" --target-org <alias>
+```
+
+### 6b — Campaign "Campus Tours" criteria sharing rule — CONFIRMED GENUINE MDAPI GAP → TIER 3 UI
+Criteria-based Campaign sharing rule: `Type = Recruitment Event` → shared to a portal group, access **Read Only**.
+- **CRITICAL: `SharingCriteriaRule`/`SharingOwnerRule` CREATE is unsupported through ANY MDAPI path.** Attempt: `POST /headless/metadata` with the correct `<SharingRules><sharingCriteriaRules>…</sharingCriteriaRules></SharingRules>` shape → `400 UNSUPPORTED_OPERATION: MetadataCrud does not support CREATE on type: SharingCriteriaRule`. Since the failure is on the CREATE *operation* (MetadataCrud), `sf`-deploy hits the **identical** wall — this is NOT a tier-1-vs-2 gap. `platform-sharing-rules-generate`/`platform-metadata-deploy` cannot help.
+- **Tier 3 (the reliable path):** Setup → Sharing Settings → Campaign Sharing Rules → New. The target portal group/profile already exists in the org — Experience Cloud site setup does not create it, so this does **not** need to wait for Step 12. As a T3-UI step it's fine to defer to the end of the build if that's how the skill is sequencing its manual steps, but re-prompt for it there rather than treating step 12 as a hard dependency.
+- **CRITICAL: This sharing rule's target audience is authenticated-community-only — largely an AEA concern.** The portal group it shares Campaign records to only has members on the authenticated (AEA) path; the ASA/Service agent already reads Campaign via its `SRA_AI_Agent_Access` clone's object perms (Step 4b) and doesn't need this rule. If the customer wants the AEA path, don't assume the portal group's underlying community licensing already exists — verify it first (`prerequisites.md`'s AEA community-licensing prerequisite: 4 UserLicenses + 4 Profiles). If those are missing, the "already exists in the org" assumption above doesn't hold and this step has nothing to share to yet.
+- If attempting tier 1 first, use the exact router-expected shape — the `<SharingRules><sharingCriteriaRules>…</sharingCriteriaRules></SharingRules>` wrapper — so the attempt fails cleanly on the unsupported CREATE *operation* rather than on a malformed body, confirming the tier-3 fallback is genuinely required.
+
+**Verify:** `GET /sharing/rules/Campaign` (tier 1, readonly) → confirm the `Campus_Tours` rule with `ruleType:Criteria`, `mainAccessLevel:"Read Only"`.
+
+### 6c — Individual Application record type (Admissions Application) — 🟢 TIER 1
+- **Tier 1:** `POST /services/data/vXX/tooling/sobjects/RecordType` with the **nested** body `{FullName:"IndividualApplication.Admissions_Application", Metadata:{active:true, label:"Admissions Application"}}` → 201. A `400 JSON_PARSER_ERROR` means the body used flat columns instead of the nested `Metadata` object — fix the shape, don't fall back to another tier.
+- **CRITICAL: Do NOT prescribe a record-type description** — leave it to the customer (omit it). Watch the BusinessProcess coupling rule for other objects (Opportunity/Lead/Case/Solution need a paired `.businessProcess-meta.xml`; `IndividualApplication` does not).
+- **Tier 2/3 fallback:** `sf project deploy start -m RecordType:IndividualApplication.<Name>`, or Setup → Object Manager → Individual Application → Record Types → New.
+
+**Verify (attempt T1 `/query` → `sf` fallback):** use **data** `/query`, not tooling — see `execution-model.md`'s query-routing nuance (c) for why (`RecordType.DeveloperName` 400s `INVALID_FIELD` on the tooling surface).
+```bash
+# Tier 2 fallback:
+sf data query -q "SELECT Id, Name, DeveloperName FROM RecordType WHERE SobjectType='IndividualApplication'" --target-org <alias>
+```
+
+### 6d — `ApplicationRecordTypeConfig` (registers the RT into the admissions feature) — 🟢 TIER 1
+Creating the record type (6c) is necessary but **not sufficient** — Education Cloud needs a **second** record that registers that record type into the admissions feature, or the SRA admissions flow won't recognize it.
+- **It's a tooling-tier entity, invisible to the data API** (`KeyPrefix 0jJ`, `IsCustomizable=false`, `PublisherId=System`) — `/sobjects/ApplicationRecordTypeConfig/describe` returns 404 and data `/query` returns `400 INVALID_TYPE`. Read + write + verify all go through `/tooling/...`.
+- **Tier 1 create:** `POST /services/data/vXX/tooling/sobjects/ApplicationRecordTypeConfig` body `{DeveloperName:"Admissions_Application", MasterLabel:"Admissions Application", ApplicationUsageType:"EDU", ObjectName:"IndividualApplication", RecordTypeName:"Admissions Application"}` → 201.
+- **CRITICAL: `RecordTypeName` takes the record type's LABEL** ("Admissions Application"), NOT the DeveloperName and NOT the Id (despite `idLookup:true`) — both of those return `400 INVALID_API_INPUT: "Invalid record type"`. Picklist API values: `ApplicationUsageType` = **`EDU`**; `ObjectName` = **`IndividualApplication`** (only value).
+
+**Verify (tooling `/query`; data `/query` throws `INVALID_TYPE`):**
+```bash
+# Tier 2 fallback:
+sf data query --use-tooling-api -q "SELECT DeveloperName, ApplicationUsageType, ObjectName, RecordTypeName FROM ApplicationRecordTypeConfig WHERE DeveloperName='Admissions_Application'" --target-org <alias>
+```
+
+### 6e — Record type → profile visibility — CRITICAL: TIER 3 UI
+After 6c/6d, the record type must be made **visible to the profiles** that use it or the personas can't select it. Assign `IndividualApplication.Admissions_Application` to **Customer Community Plus User, Einstein Agent User, System Administrator**.
+- **CRITICAL: The three PROFILES already exist, independent of whether their users do.** `Einstein Agent User` is a standard profile present in every org from the start — assigning record-type visibility to it does not wait on the specific running user Claude creates at step 9. Don't defer this step or tell the customer it'll come back around once that user exists; it's assignable now.
+- **CRITICAL: Tooling PATCH on `Profile` is UNSUPPORTED** (`400 INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: Operation UPDATE cannot be applied on … Profile … through Tooling API`) — no surgical/merge write for `recordTypeVisibilities`. The only API write is `PUT /headless/metadata type:Profile` = **whole-file REPLACE** (profiles are enormous — 400+ fieldPermissions, userPermissions incl. `DigitalAgentUser`; a partial echo silently strips the rest). Too high blast radius for a 3-click task.
+- **→ Tier 3 UI, per profile:** Setup → Profiles → open each of **Einstein Agent User**, **Customer Community Plus User**, **System Administrator** → Record Type Settings → Individual Application → move **Admissions Application** from Available Record Types to Selected Record Types → Save. Set default where appropriate.
+
+> **WARNING: Page-layout *assignment* to a record type is a separate piece with no tier-1/2 path** — no `layoutAssignments` handling exists in any catalog skill. If needed, expect tier-3 UI.
+
+**Verify (T1 readonly, one profile per call):** `GET /services/data/vXX/tooling/sobjects/Profile/{id}` → inspect `body.Metadata.recordTypeVisibilities` for the `Admissions_Application` entry (`visible:true`). **WARNING:** Two gotchas: (a) **one profile per call** (multi-row `Metadata`/`FullName` retrieval → `MALFORMED_QUERY`); (b) payload is **large** (System Administrator ~515KB) — extract only the `recordTypeVisibilities` slice.
+
+> All five blocks (6a–6e) are hard prerequisites for their subagents. 6a/6c/6d are **T1**; 6b + 6e are tier-3-UI gaps.