@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/health-cloud-initial-configure/SKILL.md

@@ -1,511 +0,0 @@
----
-name: health-cloud-initial-configure
-description: "Guides a Salesforce admin through setting up Health Cloud in a brand-new org, end to end — tying the many separate Setup pages an admin would otherwise click through by hand into one ordered, resumable workflow, run in the strict order the platform requires. Covers the foundation (Health Cloud Console, FHIR / Clinical Data Model, Discovery Framework, OmniStudio), the advanced capabilities (Einstein for Health Cloud, Disease Surveillance, Data Cloud, Context Service, Digital Experiences / Experience Cloud), Data Protection & Privacy / Consent Management, Translation Workbench, Contacts to Multiple Accounts, Person Accounts (with its record types, page layouts, and profile record-type visibilities), and placing the Patient Card and patient Timeline on the account record page and on the Health Cloud Console app's own patient page. Encodes orderings the Setup UI never surfaces (Contacts to Multiple Accounts must precede Person Accounts) and two irreversible, one-way gates (enabling Person Accounts, and the org Timeline toggle) that require explicit confirmation, and re-reads live org state before every step so a partly-done setup can be safely resumed. Use when the user asks to \"set up Health Cloud\", \"configure Health Cloud in my org\", \"get my org ready for Health Cloud\", \"enable Health Cloud and its features\", \"turn on Health Cloud\", \"I just got Health Cloud, help me set it up\", or \"finish setting up Health Cloud\" — or asks to enable a specific part of Health Cloud (Person Accounts, the patient page / record page, or the Timeline) as a step of that setup. Not for setting up Intelligent Appointment Management / patient scheduling (a different Health Cloud feature), and not for an org that already runs Service Cloud on shared Case/Account/Contact objects (that is a migration, not a fresh setup)."
-metadata:
-  version: "1.0"
----
-
-**Setting up Health Cloud from a new org means running all four acts in order — Act 1 (foundation), Act 2 (data protection & account config), Act 3 (Person Accounts, record types, layouts, profiles), and Act 4 (Patient Card & Timeline) — NOT just the foundation toggles.** This is the full end-to-end setup for a brand-new org: the ordered, resumable journey that ties together the individual Setup pages an admin would otherwise navigate by hand. Finishing Act 1 is not finishing the setup.
-
-Guide an admin through standing up **Health Cloud** in a **brand-new org** — Console, FHIR Data Model, Discovery Framework, data protection, accounts, Person Accounts, record types, layouts, and the Patient Card + Timeline — in the **strict order** the underlying preferences and platform features require, with a validate-only stance on anything genuinely external to Salesforce (edition, license, paid add-on entitlements).
-
-This skill automates as much of the setup as a real customer-org admin can legitimately do via API/metadata: license/prereq detection, org-preference toggles, Settings/RecordType/Profile/FlexiPage metadata deploys, and the Person Accounts + Timeline enablement sequences. It does **not** assume internal-only enablement paths — everything here is something a customer admin could trigger themselves, just faster and in the right order.
-
-## Orient the admin first — what this skill is (and is not)
-
-Before you confirm scope or run anything, give the admin a one-screen orientation so expectations are set up front. Do this proactively — don't wait to be asked.
-
-- **This is the ordered, end-to-end setup *workflow*, not a single toggle.** It walks the org through four stages in the exact order the platform requires: (1) **foundation** — Health Cloud Console, FHIR / Clinical Data Model, Discovery Framework, OmniStudio, and the advanced capabilities (Einstein for Health Cloud, Disease Surveillance, Data Cloud, Context Service, Digital Experiences, and the care org preferences — Enhanced Care Plans, Integrated Care Management, Care Gap); (2) **data protection & account configuration** — Consent Management, Translation Workbench, Contacts to Multiple Accounts; (3) **Person Accounts** — record types, page layouts, profile visibilities; (4) **Patient Card + Timeline** on the org-default patient record page, then **create + activate the Health Cloud Console app's own record page** (last, once its component prerequisites are all on). State these four stages to the admin before your first write (see the *Mandatory pre-write plan* below).
-- **Be explicit about what is automated vs. what stays manual.** Almost every step is something a customer admin can do themselves via API/metadata — org-preference toggles, Settings/RecordType/Profile/FlexiPage deploys, and the Person Accounts + Timeline sequences — this skill just does them faster and in the correct order. A few surfaces have **no dispatchable API** (they are called out inline as gaps): for those, surface the manual Setup-UI path, mark that step INCOMPLETE, and keep going — never fabricate a call. External prerequisites (edition, license, paid add-on entitlements) are **validate-only** — the skill checks them and redirects if unmet; it never tries to grant them.
-- **This is NOT the one-click "enable everything" button — do not shortcut through the bulk orchestrator.** Do **not** call the bulk `executeHealthCloudBasicFeatureSetup` orchestrator (or any single "basic feature setup" / one-shot enable-all entry point) as a fast path. That orchestrator ignores its argument, force-enables *every* feature in its internal map, and silently kicks off the **IRREVERSIBLE Person Accounts automation the admin never confirmed** — exactly the destructive side effect this ordered workflow exists to prevent. Enable each feature through its own dedicated control (the per-step routes in the Acts below), and gate the two irreversible steps on explicit confirmation. If the admin explicitly asks for "the one-click setup" or "just turn everything on," explain why this skill deliberately does not do that and walk them through the ordered flow instead.
-- **This is a setup workflow, not a test plan or an audit checklist.** Actually run and verify each step against the live org (re-read state, gate on independent read-backs) — do not merely narrate what "should" happen or produce a checklist of expected outcomes.
-
-## Scope & definition of done — READ THIS FIRST
-
-**"Set up Health Cloud" / "Configure Health Cloud" / "Prepare my org for Health Cloud" with no narrowing qualifier means run ALL FOUR ACTS, in order: Act 1 → Act 2 → Act 3 → Act 4.** Act 1 (foundation) is only *one* of the four acts. If you find yourself about to stop after the foundation toggles for an unqualified "set up Health Cloud" request, that is the bug this section exists to prevent — keep going through Act 4.
-
-**You are NOT done after Act 1 (or Act 3).** The setup is complete only when **Act 4's end state** is reached (Patient Card placed where possible; Timeline enabled, configured, and activated). If a specific, documented gate blocks a later step, **report that gate explicitly and still run every step that is not blocked** — never silently stop. A run that ends after the foundation toggles is a *partial* run, not a completed setup; say so plainly if you must stop early.
-
-**This targets a brand-new org.** If Service Cloud is already configured (shared Case/Account/Contact objects), STOP — that is a separate migration path, not this workflow (precondition `OrgState.NoExistingServiceCloudConfig`). Act 1's `detect-service-cloud-presence` step is the observable check that surfaces this: it queries for a Service Cloud footprint and warns about the shared Case/Account/Contact objects before any write; the precondition is the hard backstop.
-
-**Two irreversible gates dominate the flow.** Enabling **Person Accounts** (Act 3) CANNOT be undone and is a hard prerequisite for record types, layouts, and components. The org-level **Timeline toggle** (Act 4) is a second one-way gate — it cannot be turned back off. Both require explicit user confirmation before you dispatch them. If the admin declines Person Accounts, END the workflow — every remaining step depends on it.
-
-**`enable-data-protection` (Consent Management) is REQUIRED for HIPAA.** If the admin skips it, mark the final summary INCOMPLETE.
-
-**Deferred / gapped steps are NOT stop signals.** Steps that hit a declared gap (no dispatchable API for a Setup surface) are called out so you set correct expectations — **not** so you halt the act sequence. Surface the manual Setup path, mark that step INCOMPLETE, and continue with everything not blocked. Never fabricate a call for a gapped step. **Note the exception: the advanced-capability entitlements (Einstein for Health Cloud, Disease Surveillance, Data Cloud, Context Service) are NOT gaps and are NOT skippable — they are EXPECTED on a properly provisioned Health Cloud org, so a genuinely absent one is a BLOCKING error (see the advanced-capabilities section below), not a deferral.**
-
-## Mandatory pre-write plan — state this before your FIRST write
-
-Before you execute a single write operation (any toggle, any deploy, any enablement), post a short plan to the admin that makes your scope decision **explicit and reviewable**:
-
-1. **The full journey is four acts** — list them: Act 1 (foundation), Act 2 (data protection & accounts), Act 3 (Person Accounts + record types + layouts + profiles), Act 4 (Patient Card + Timeline).
-2. **Which layout strategy** you will use — **custom Patient/Provider layouts (default)** or **reuse the default Person Account layout**. Quote the admin's words that justify anything other than the default. (There is no capability-tier choice: the advanced capabilities are always part of the setup and are EXPECTED to be entitled on a properly provisioned Health Cloud org — a genuinely missing entitlement is a blocking error, not a skip.)
-3. **The two irreversible gates** — call out that Person Accounts and the Timeline org toggle are permanent, and that you will require explicit confirmation at each before dispatching.
-4. **Where you will start.** For an unqualified request this is Act 1, step 1 (`validate-hc-license`) — never mid-flow.
-
-If your plan proposes stopping after the foundation toggles for an unqualified "set up Health Cloud" request, that plan is wrong on its face — stop and re-plan from the full 1→4 journey.
-
-## Supported utterances
-
-Route on intent — a customer states a goal in plain language, not a fixed phrase:
-
-- "Set up Health Cloud" / "Configure Health Cloud in my org" / "Get my org ready for Health Cloud"
-- "Enable Health Cloud and its features" / "Turn on Health Cloud"
-- "I just got Health Cloud — help me set it up" / "Finish setting up Health Cloud"
-- "Set up Health Cloud with all the advanced capabilities / with Einstein, Data Cloud, Disease Surveillance, Context Service" (the advanced capabilities are always part of the full setup; the phrase just affirms it)
-- "Enable Person Accounts for Health Cloud" (narrow → Act 3, but confirm the prereqs from Acts 1–2 are met first)
-- "Set up the Health Cloud patient page / patient record page / timeline" (narrow → Act 4, after confirming Person Accounts is on)
-
-## Session state (track across the conversation)
-
-- `target_org_alias` — the org being configured; confirmed explicitly before any write (never silently inherited).
-- `layout_strategy` — `custom-layouts` (default) or `default-layout`. See *Decision points* below.
-- `act1_complete` … `act4_complete` — bool per act; acts run strictly 1→2→3→4. For an unqualified request, all four must reach `true` (or be explicitly reported as gate-blocked) before you report the setup complete.
-- `person_accounts_confirmed` — bool; the explicit user acknowledgement that Person Accounts is permanent. Nothing in the Person Accounts enablement chain runs until this is `true`.
-- `timeline_toggle_confirmed` — bool; the explicit user acknowledgement that the org-level Timeline toggle is one-way.
-- `hipaa_data_protection_done` — bool; `enable-data-protection` succeeded. If false at the end, the summary is INCOMPLETE.
-
-## Entry point — route on the admin's actual ask
-
-**Default rule:** unless the admin's ask *explicitly narrows the scope*, treat it as the full setup and **run Acts 1→4 in order.** When in doubt, run the full journey.
-
-| Signal | Where to start |
-|---|---|
-| **"Set up Health Cloud" / "configure Health Cloud" / "prepare my org for Health Cloud" / no narrowing qualifier / no prior state known** | **Run the FULL journey: `validate-hc-license` (Act 1 step 1), then Acts 1→2→3→4 in order — the advanced Act-1 steps always run. This is NOT "just the foundation toggles." Not done until Act 4's end state.** |
-| "…and all advanced capabilities" / "with Einstein / Data Cloud / Disease Surveillance / Context Service" | Same as the default full journey; the phrase just affirms the advanced steps (which always run) are in scope. |
-| "Person Accounts is what I need" | Narrow → Act 3, but first confirm Contacts-to-Multiple-Accounts (Act 2) is on and a Business Account record type exists — Person Accounts hard-gates on both. |
-| "Just the patient page / timeline" | Narrow → Act 4, after confirming Person Accounts is already enabled (Act 4 hard-depends on it). |
-| Service Cloud already configured / existing shared-object config | STOP — out of scope; this is a fresh-org setup, not a migration. Redirect. |
-
-## Decision points (confirm before Act 1 writes; drive optional steps)
-
-This workflow has one admin decision (layout strategy). Confirm it up front; it gates which layout steps run. There is no separate "choices" object — the decision is expressed as the per-step *applies-when* notes in the act tables below. **There is no capability-tier choice** — the advanced capabilities (Einstein for Health Cloud, Disease Surveillance, Data Cloud, Context Service) always run and are EXPECTED to be entitled on a properly provisioned Health Cloud org; a genuinely missing advanced-capability entitlement means the org is mis-provisioned and is a BLOCKING error (halt and surface for remediation), not a skip.
-
-### 1. Layout strategy — default `custom-layouts`
-
-> Create custom role-specific Patient and Provider page layouts (recommended), or reuse the default Person Account layout for both record types?
-
-- **`custom-layouts` (default):** Create a Patient layout and a Provider layout with role-specific fields, then map the Patient/Provider record types to them. Runs `create-patient-layout` + `create-provider-layout` + `assign-person-account-layouts-to-profiles` (the assignment is its own Profile `<layoutAssignments>` PUT, not part of the RT create).
-- **`default-layout`:** Keep the auto-generated Person Account layout for both record types. **Skips** `create-patient-layout`, `create-provider-layout`, and `assign-person-account-layouts-to-profiles`; the record types map to the default Person Account layout instead.
-
-## Prerequisites
-
-### A. True prerequisites — external to this skill (validate only)
-
-These gate the flow. If unmet, report which one and redirect — don't attempt to fix them. Surface each as a discrete checked line (✅/❌ + the value you queried), up front, even when they all pass.
-
-- **Health Cloud license provisioned** (grants `OrgPermissions.HealthCloud`). **A Life Sciences Cloud license does NOT satisfy this** — the LSC platform license (`IndustriesLSC4CE-1.pld.xml`) grants LifeSci org perms but not `OrgPermissions.HealthCloud`, which ships only in `HealthCloud-1.pld.xml` via `HealthCloudAddOn-1`. Verified live by `validate-hc-license`.
-- **Edition:** Enterprise or Unlimited (`OrgEdition.EnterpriseOrUnlimited`).
-- **Lightning Experience enabled** (`OrgPermissions.LightningExperienceEnabled`).
-- **Admin access:** Customize Application + View/Modify Setup (`UserPermissions.CustomizeApplication`).
-- **Can initiate HC org-setup automation:** `HealthCloud.userCanInitiateHealthCloudOrgSetupAutomation` (the class-level guard used by the console enable/verify steps).
-- **Can access the site-management setup page:** `IndustriesLifeSciences.userCanAccessSiteMgmtSetupPage` (legacy guard; see note under `validate-hc-license`).
-- **Brand-new org:** `OrgState.NoExistingServiceCloudConfig` — no pre-existing Service Cloud / shared-object config.
-
-**Advanced capabilities — entitlements are EXPECTED, not optional.** The advanced steps always run as part of the setup, and a properly provisioned Health Cloud org carries their entitlements, so each step is expected to succeed. If a step's entitlement is genuinely absent (e.g. **403 ACCESS_DENIED** on the target route), that is a **BLOCKING ERROR** — the org is mis-provisioned; halt and surface it for remediation. Do NOT silently mark the step SKIPPED and move on. (This is distinct from the idempotency skip on `enable-data-cloud`, which correctly skips when Data Cloud is ALREADY provisioned — an is-it-already-done check, unrelated to entitlement.)
-
-- **Einstein for Health Cloud** is driven via the `healthCloudGenAIPref` master org preference (set through the Package to Core set-preference control) — a real, **non-entitlement-gated** toggle (it enables while the org-wide Einstein GenAI platform gate still 403's). The org-wide Einstein Generative AI platform gate (`generative-aisetup`, `OrgPermissions.HealthCloudGenerativeAI`) is a **separate** paid entitlement that returns **403 ACCESS_DENIED** even for a System Administrator and **no PermSet clears it**; this SOR deliberately does **not** drive it — it is empirically independent of the HC pref. So `enable-einstein-for-health-cloud` normally succeeds regardless of the org-wide GenAI entitlement.
-- **Data Cloud licensed** (`OrgPermissions.CustomerDataPlatform`). Read licensing + provisioning via the CDP Setup Home provisioning-status control, **NOT** the old `isCdpProvisioned` route (that 500s/route-broken and is not a reliable signal). A Health Cloud org is EXPECTED to carry the Data Cloud license — if it is genuinely absent, that is a BLOCKING error, not a skip. (`enable-data-cloud` still SKIPS on the IDEMPOTENCY signal — when Data Cloud is already provisioned, `provisionStatus == succeeded` — which is unrelated to entitlement.)
-
-**Data Protection precondition:** `enable-data-protection` needs only View Setup and has **no** paid-add-on precondition (free org preference).
-
-### B. Automatable by this skill (the Acts below)
-
-License/prereq detection; Console + FHIR + Discovery Framework enablement; OmniStudio detection + optional pref tuning; the advanced toggles (when licensed); Consent Management; Translation Workbench + Contacts-to-Multiple-Accounts (Settings deploys); Person Accounts readiness/terms/enablement; record types, layouts, profile record-type visibilities; Patient Card placement; Timeline enable → configure → activate.
-
-## Transport & deploy discipline (applies to EVERY Act — read before your first write)
-
-These rules are cross-cutting; each Act references them rather than repeating them.
-
-1. **Prefer the platform dispatch tool; two transports exist.** Most toggles are dispatcher-backed Aura routes (`/headless/invoke/...`) or Connect APIs (`/services/data/...`). All **metadata** (Settings singletons, RecordType, Profile, FlexiPage, CustomObject) deploys through the headless Metadata REST resource **`/services/data/vXX/headless/metadata`** (`POST`=create, `PUT`=update, `GET`=read; `{type, fullName, xmlRep}`) — supported end-to-end for every metadata type this skill touches. Each step below names its transport. Prefer the headless Metadata resource for Settings/RecordType/Profile/CustomObject and for creating/activating FlexiPage pages built from standard `force:*` components. **The FlexiPage binds of the Patient Card and timeline (`healthcloud:patientCard`, `industries_common:timeline`, Act 4 steps 49 & 55) ALSO go through the headless `PUT` — one `dispatch` call, `PUT /services/data/vXX/headless/metadata` with the flat body `{type:"FlexiPage", fullName:"<DeveloperName>", xmlRep:"<whole re-authored page>"}`.** NO multipart, NO zip, NO `sf` CLI — a single JSON PUT `dispatch` issues directly. ⚠ The ONE load-bearing rule: **send the WHOLE page.** FlexiPage `<flexiPageRegions>` are ordered full-record lists, so the PUT is a FULL REPLACE (not the component-level merge that Settings/Profiles/CustomObject actionOverrides get) — a PUT that omits pre-existing components drops them. So read-modify-write: GET the current `xmlRep`, insert your `<itemInstances>`, PUT the whole page preserving every existing region/component. The Patient Card is the standard **`healthcloud:patientCard`** component, bound by `<componentName>` with **NO `<componentInstanceProperties>` block** (this is how Lightning App Builder persists it). The timeline is **`industries_common:timeline`** and MUST be bound WITH a **`timelineConfigs`** component property naming the 4 OOTB Timeline Configurations (`String[]`, each element a `TimelineObjectDefinition` DeveloperName: `HC_Clinical_Data`, `HC_Engagement_Data`, `HC_Patients_Life_Story`, `HC_Assessments`) — a property-free timeline bind does NOT auto-resolve the org's active configs, so the timeline renders none/wrong configurations. Two gotchas, both TRANSACTIONAL (the whole PUT fails atomically): (1) **component access** — a bind before the backing feature is enabled fails `hasComponentAccess` (run `handle-timeline-toggle` before the timeline; Health Cloud enablement in Act 1 provides `healthcloud:patientCard`); (2) **property shape** — the timeline's `timelineConfigs` is array-typed, so serialize it as a `<valueList>` of `<valueListItems><value>…</value></valueListItems>` (one per config); an EMPTY `timelineConfigs` property (name, no value) rolls back the whole page and a SCALAR `<value>` is rejected with `FIELD_CUSTOM_VALIDATION_EXCEPTION: "Value is not allowed for Array attribute type in API version 49 and above."`. ALWAYS gate on an independent read-back, never the write echo.
-2. **Headless-metadata merge semantics (know these before deploying).** The headless Metadata resource does **component-level MERGE** for **Settings singletons and Profiles** (a single-field deploy preserves every other field), so the `read-*` snapshot steps are OPTIONAL for those. **FlexiPage region-adds are read-modify-write** (region item lists are ordered — read the whole page, add your `<itemInstances><componentInstance>` — the v68.0 shape, not a bare `<componentInstances>` — PUT the whole page back), and **CustomObject `actionOverrides` also merge** (non-destructive). If `/headless/metadata` genuinely 404s on a stripped org, that is an org route artifact, not a missing capability — fall back to the **manual Setup UI** and Tooling SOQL reads; never conclude "the capability is missing" from a dispatcher 404 alone.
-3. **What MERGES vs what is read-modify-write (know before deploying).** Everything in THIS rule goes through `/headless/metadata` (no CLI) — INCLUDING the two OmniStudio/industries FlexiPage binds, which use the same whole-page `dispatch` PUT of rule 1 (`PUT /headless/metadata {type:FlexiPage, fullName, xmlRep:<whole page>}`). **Settings singletons MERGE** (`PUT Account` with only `<enableRelateContactToMultipleAccounts>true>` preserves every other AccountSettings field; same for `LanguageSettings`). **Profiles MERGE at the component level too** — a `PUT type=Profile` carrying ONLY the target `<recordTypeVisibilities>` blocks assigns RT visibility WITHOUT wiping other perms (`PermissionsModifyAllData` on the System Administrator profile stays true). So NEVER round-trip the ~1MB full Profile; send the minimal fragment. **CustomObject `actionOverrides` also MERGE** (activating a record page is a one-override PUT; every pre-existing override survives). **FlexiPage region-adds are READ-MODIFY-WRITE, not merge** — region item lists are ordered, so read the whole page's `xmlRep`, add your `<itemInstances><componentInstance>` (distinct `<identifier>`; the v68.0 shape — NOT a bare `<componentInstances>`), and write the whole page back preserving every existing region/component. That write-back is a `/headless/metadata` PUT for ALL pages — `force:*`-only pages AND the two OmniStudio/industries binds (steps 49 & 55) alike; the only rule is send the WHOLE page (a partial-page PUT drops the components you omit). **RecordType create** is a `POST` whose `xmlRep` is a `<CustomObject>` root wrapping a nested `<recordTypes>` block (a top-level `<RecordType>` is rejected). Because Settings/Profile/CustomObject all merge, the `read-*` snapshot steps are OPTIONAL for them (useful only for read-back verification); the FlexiPage `read-*` step IS required (it feeds the RMW).
-4. **Re-read to verify — never trust the write's own echo.** Toggles echo the written value; gate on an INDEPENDENT read-back (the `verify-*` / `get-*` step), which confirms the preference actually persisted. Metadata deploys: gate on `state=Changed` plus a follow-up retrieve.
-5. **Ground the final report in fresh queries**, not stale session notes — re-query end state immediately before reporting "done."
-6. **CLI TLS handling:** if a `sf` command needs relaxed TLS for a local/dev endpoint, set `NODE_TLS_REJECT_UNAUTHORIZED=0` **inline on that single command only** — NEVER in shell init, a profile, or Claude settings.
-
----
-
-## Act 1 of 4 — Discovery & Foundation
-
-> Act 1 both **validates** external prereqs (edition/license — check only) **and performs writes** (Console, FHIR, Discovery Framework, and the advanced toggles). Validating the prereqs is not the same as running Act 1.
-
-Run these in order. Each write is preceded/followed by a read so the workflow is resumable — before writing, re-read the corresponding `read-`/`get-`/`check-` step and skip the write if the state is already correct.
-
-| # | Step id | Purpose | Backing API | Route |
-|---|---|---|---|---|
-| 1 | `validate-hc-license` | validate | Health Cloud license check | GET `/headless/invoke/platform/health-cloud-admin-feature-setup/has-health-cloud-licence` (proposed) |
-| 2 | `read-health-cloud-setup-state` | read | Read Health Cloud setup state | GET `/headless/invoke/platform/health-cloud-admin-feature-setup/get-health-cloud-setup-state` |
-| 2a | `detect-service-cloud-presence` | read | Tooling: `RecordType WHERE SobjectType IN ('Case','Account','Contact')` (+ Data `SELECT COUNT() FROM Case`) | GET `/services/data/v67.0/tooling/query/?q=SELECT+Id,Name,SobjectType,IsActive+FROM+RecordType+WHERE+SobjectType+IN+('Case','Account','Contact')` |
-| 2b | `check-health-cloud-foundation-permset` | verify | **Data API**: `PermissionSetAssignment WHERE PermissionSet.Name='HealthCloudFoundation'` | GET `/services/data/v67.0/query/` |
-| 2c | `assign-health-cloud-foundation-permset` | write | **Data API**: create `PermissionSetAssignment` (HealthCloudFoundation → running admin) | POST `/services/data/v67.0/sobjects/PermissionSetAssignment` |
-| 2d | `verify-health-cloud-foundation-permset` | verify | **Data API**: `PermissionSetAssignment` read-back (totalSize ≥ 1) | GET `/services/data/v67.0/query/` |
-| 3 | `enable-health-cloud-console` | write | Set org preference consolePreference = true | PATCH `/headless/invoke/platform/package-to-core-settings/set-preference` |
-| 4 | `verify-health-cloud-console` | verify | Read org preference consolePreference | GET `/headless/invoke/platform/package-to-core-settings` |
-| 5 | `read-fhir-pref` | read | Read Clinical Data Model org preference | GET `/headless/invoke/platform/clinical-data-model-settings` |
-| 6 | `enable-fhir-data-model` | write | Toggle Clinical Data Model pref = true | PATCH `/headless/invoke/platform/clinical-data-model-settings/handle-clinical-data-model-pref-toggle` |
-| 7 | `verify-fhir-data-model` | verify | Read Clinical Data Model org preference | GET `/headless/invoke/platform/clinical-data-model-settings` |
-| 8 | `enable-fhir-subscription-access` *(optional)* | write | Toggle FHIR Subscription Access pref = true | PATCH `/headless/invoke/industries/industries-healthcare/fhir-subscription-setup/handle-fhir-subscription-access-org-pref-toggle` |
-| 9 | `enable-discovery-framework` | write | Connect `enableFeature` (`featureApiName=industries-health-cloud-discovery-framework`) | POST `/services/data/v63.0/connect/setup/discovery/feature/{featureApiName}/enable` (implemented) |
-| 10 | `check-omnistudio-package-installed` | verify | Read OmniStudio prefs — gate on `standardOmniStudioRuntime` (READ-ONLY; managed package NOT required) | GET `/headless/invoke/platform/omni-studio-settings/get-omni-studio-prefs` |
-| 11 | `enable-omnistudio-runtime-pref` | write | Save OmniStudio pref `standardOmniStudioRuntime` = true — grants `runtime_omnistudio:flexcard` access (Act 4 prereq) | PATCH `/headless/invoke/platform/omni-studio-settings/save-pref` |
-| 12 | `check-omnistudio-permissions-assigned` | verify | **Data API**: `PermissionSetAssignment WHERE PermissionSet.Name='OmniStudioAdmin'` | GET `/services/data/v67.0/query/` |
-| 13 | `assign-omnistudio-admin-permset` | write | **Data API**: create `PermissionSetAssignment` (OmniStudioAdmin → running admin) | POST `/services/data/v67.0/sobjects/PermissionSetAssignment` |
-| 14 | `verify-omnistudio-admin-permset` | verify | **Data API**: `PermissionSetAssignment` read-back (totalSize ≥ 1) | GET `/services/data/v67.0/query/` |
-| 14a | `check-omnistudio-user-permset` | verify | **Data API**: `PermissionSetAssignment WHERE PermissionSet.Name='OmniStudioUser'` | GET `/services/data/v67.0/query/` |
-| 14b | `assign-omnistudio-user-permset` | write | **Data API**: create `PermissionSetAssignment` (OmniStudioUser → running admin) | POST `/services/data/v67.0/sobjects/PermissionSetAssignment` |
-| 14c | `verify-omnistudio-user-permset` | verify | **Data API**: `PermissionSetAssignment` read-back (totalSize ≥ 1) | GET `/services/data/v67.0/query/` |
-| 14d | `enable-omnistudio-pref` *(optional, per-key)* | write | Save OmniStudio pref `<key>` = true — only for a key that reads off | PATCH `/headless/invoke/platform/omni-studio-settings/save-pref` |
-
-**Act 1 — foundation notes (ordering & findings):**
-
-- **`validate-hc-license` is the gate for the whole workflow.** The check returns `true` when reachable; on a denied caller it throws rather than returning `false` — treat any error as "not provisioned, HALT." Its guard `HealthCloud.userCanInitiateHealthCloudOrgSetupAutomation` = `(OrgPermissions.HealthCloud || HealthCloudSandboxUpgrade) && UserPermissions.ViewSetup`, so a Life Sciences license does NOT satisfy it. **This was deliberately retargeted OFF** the Life Sciences Site Management setup-page guard (which required the LS Site Management feature and would wrongly deny a pure Health Cloud org) onto the Health Cloud setup guard.
-- **`read-health-cloud-setup-state`** is the authoritative, INDEPENDENT HC feature-state read. Do NOT read state via the Life Sciences Site Management setup-page pref — that reads the Life Sciences `ORG_PREFERENCE_LS_SITE_MANAGEMENT` pref, a DIFFERENT setting, and produced a false-positive verify.
-- **`detect-service-cloud-presence`** is the OBSERVABLE Service Cloud detection Act 1 requires — the `OrgState.NoExistingServiceCloudConfig` precondition is the hard backstop, this step makes the detection dispatchable and emits the shared-object warning. Primary Tooling query enumerates record-type customizations across the three objects Health Cloud SHARES with Service Cloud — `RecordType WHERE SobjectType IN ('Case','Account','Contact')`. ALSO run the Data-API volume signal `SELECT COUNT() FROM Case`: Case rows indicate active Service Cloud use even with zero custom Case record types (record-type count alone under-detects). If either signal shows a footprint (Case records exist, or Case/Contact record types beyond defaults), WARN that this workflow targets a brand-new org and that an org with existing Service Cloud config belongs on the separate migration path; then let the precondition gate stop/continue. **Account record types are EXPECTED** (Health Cloud creates them) — do NOT treat Account-only rows as a Service Cloud signal. Non-fatal on its own. Depends on step 1; runs before `enable-health-cloud-console` (the first write depends on it) so the warning precedes any mutation.
-- **`check-health-cloud-foundation-permset` (2b) + `assign-health-cloud-foundation-permset` (2c) + `verify-health-cloud-foundation-permset` (2d) — assign the "Health Cloud Foundation" permission set to the running admin as one of the FIRST steps.** This is the foundational Health Cloud permission set (`PermissionSet.Name='HealthCloudFoundation'`, Label "Health Cloud Foundation", a STANDARD `force`-namespace permission set that ships with the Health Cloud license) — it grants the running admin the baseline Health Cloud object/tab/feature access the rest of the setup assumes. Self-assign via the **Data API** (`PermissionSetAssignment` is a standard Data-API sObject, NOT a Tooling type), mirroring the OmniStudioAdmin (12–14) and GenieAdmin (18a–18c) self-assigns: query for an existing assignment (2b); if 0 rows, resolve `PermissionSetId` via `SELECT Id FROM PermissionSet WHERE Name='HealthCloudFoundation'` and POST `{AssigneeId, PermissionSetId}` (2c, idempotent — skip when 2b already returned a row — and reversible via DELETE); gate on an independent read-back (2d, `totalSize ≥ 1`), NOT the POST echo. Runs right after `read-health-cloud-setup-state`/`detect-service-cloud-presence` and BEFORE `enable-health-cloud-console` (which now `depends_on` `verify-health-cloud-foundation-permset`) so the foundation permissions are in place before any feature toggle. **Org-provisioning gate:** if `SELECT Id FROM PermissionSet WHERE Name='HealthCloudFoundation'` returns 0 rows, the Health Cloud license is not provisioned (the same condition `validate-hc-license` catches) — a BLOCKING mis-provisioning error, NOT a user-permission gap; do NOT fabricate an Id or skip ahead. `HealthCloudFoundation` resolves to a Standard, `force`-namespace PermissionSet; the POST returns `{success:true, id:…}` and the independent read-back returns 1 row.
-- **`enable-health-cloud-console`** — set `consolePreference` = true → 200 `body:true`; independent read-back → `true`. Reversible (re-call with `value:false` to roll back). `consolePreference` is one of three allowlisted keys (`consolePreference` / `stdRelationshipPreference` / `healthCloudGenAIPref`); any other string throws. **DO NOT use the bulk `executeHealthCloudBasicFeatureSetup` orchestrator** for this — it ignores its arg, force-enables EVERY feature in its org-preference map, AND kicks off the IRREVERSIBLE Person Accounts automation (a destructive side-effect the caller did not ask for). Depends on steps 1–2.
-- **`enable-fhir-data-model`** — this is the correct control for the "FHIR Data Model" toggle on the Clinical Data Model Settings page. Baseline `false`; PATCH `{value:true}` → 200 `{}`; read-back flipped to `true`. Gate on the verify read, not the write body. Reversible (`{value:false}`). **Distinct from FHIR Subscription Access** (step 8) — that is a *different* preference (event streaming); it read `true` on the org even while the Clinical Data Model toggle was off, which had produced an earlier false "enabled" report.
-- **`enable-fhir-subscription-access`** *(optional)* — a separate preference. Include only when the org needs FHIR event subscriptions.
-- **`enable-discovery-framework`** — the correct `SetupDiscoveryFeatureApiName` is **`industries-health-cloud-discovery-framework`** → 201 `{"success": true}` on the v63.0 path. The earlier guess **`DiscoveryFramework` is WRONG** (400 NOT_FOUND). Idempotent; no sibling read-back — the enable response is the only confirmation. Rollback via the sibling `/disable` route.
-- **OmniStudio here is STANDARD OmniStudio (the metadata-based runtime) — NOT the legacy OmniStudio/Vlocity MANAGED PACKAGE. There is nothing to "install", so this sub-flow is fully automatable and must NOT be marked INCOMPLETE for a missing package.** With `standardOmniStudioRuntime=true` the org has NO `omnistudio` managed package yet `OmniUiCard`/`OmniProcess` resolve as standard first-class Data-API sObjects (`custom:false`, `OmniUiCard` keyPrefix `0ko`), and the three OmniStudio permission sets (OmniStudioAdmin/User/Execution) ship standard. Corrected flow:
-  - **`check-omnistudio-package-installed`** (step 10) is now a READ of `getOmniStudioPrefs()` — gate on `standardOmniStudioRuntime`. The old `InstalledSubscriberPackage` probe is only relevant to the managed-package path; its absence is EXPECTED and MUST NOT escalate. If `standardOmniStudioRuntime==false`, do NOT stop — run **`enable-omnistudio-runtime-pref`** (step 11) next.
-  - **`enable-omnistudio-runtime-pref`** (step 11) — `savePref({prefName:"standardOmniStudioRuntime", value:true})`. Grants the org access to the `runtime_omnistudio:flexcard` Lightning component and the rest of the Standard OmniStudio runtime surface (Core enforces component access transactionally via `hasComponentAccess`). Note: the Act 4 Patient Card bind uses the standard `healthcloud:patientCard` component (provided by Health Cloud enablement), NOT `runtime_omnistudio:flexcard`, so this pref is not the specific gate for that bind — but it remains a required Act 1 foundation step for the OmniStudio runtime. Verify via an independent `getOmniStudioPrefs()` re-read. Caution: like the Timeline toggle, treat it as potentially IRREVERSIBLE and only fire when the runtime is genuinely off.
-  - **`check-omnistudio-permissions-assigned`** (step 12) + **`assign-omnistudio-admin-permset`** (13) + **`verify-omnistudio-admin-permset`** (14) — via the **Data API** (`PermissionSetAssignment` is a Data-API sObject, NOT a Tooling type). Zero rows means "not yet self-assigned", NOT "package missing". The flow self-assigns `OmniStudioAdmin` to the running admin (idempotent, reversible via DELETE) so it no longer dead-ends on a human hand-off. 0 rows → POST 201 → read-back 1 row.
-  - **`check-omnistudio-user-permset`** (14a) + **`assign-omnistudio-user-permset`** (14b) + **`verify-omnistudio-user-permset`** (14c) — the same self-assign pattern for the **`OmniStudioUser`** permission set, alongside `OmniStudioAdmin`. `OmniStudioUser` is the STANDARD, `force`-namespace runtime-*consumer* permission set (it grants the baseline access to RUN OmniStudio assets — FlexCards, OmniScripts — that the Patient Card / patient-facing runtime surface needs, complementing the authoring access `OmniStudioAdmin` grants); it ships standard on a Standard-OmniStudio org with NO managed package. Self-assign via the **Data API**: query for an existing assignment (14a); if 0 rows, resolve `PermissionSetId` via `SELECT Id FROM PermissionSet WHERE Name='OmniStudioUser'` and POST `{AssigneeId, PermissionSetId}` (14b, idempotent — skip when 14a already returned a row — reversible via DELETE); gate on an independent read-back (14c, `totalSize ≥ 1`), NOT the POST echo. `OmniStudioUser` resolves to a Standard, `force`-namespace PermissionSet (Label "Omnistudio User"); 0 rows before → POST → 201 `{success:true, id:…}`; independent read-back → 1 row.
-  - **`enable-omnistudio-pref`** (14d, optional, per-key) — tune any OTHER pref in the 15-key map that reads off. Only fire for a specific key that is off.
-
-### Act 1 — Advanced capabilities
-
-**These steps always run as part of the setup** — there is no capability-tier opt-out, and their entitlements are EXPECTED on a properly provisioned Health Cloud org. A genuinely absent advanced-capability entitlement (Data Cloud unlicensed, etc.) means the org is mis-provisioned — treat it as a **BLOCKING error** (halt and surface for remediation), NOT a skip. **One nuance for the Data Cloud route:** a 403 ACCESS_DENIED on `check-cdp-provision-status` is NOT immediately a mis-provisioning block — for a stock System Administrator it is first the fixable USER-LEVEL missing `GenieAdmin` permission (steps 18a–18c self-assign it). Only a 403 that persists after `GenieAdmin` is assigned, or an absent `GenieAdmin` permission set, is the org-level `OrgPermissions.DataCloud` mis-provisioning block. (The org-wide Einstein Generative AI platform toggle was dropped from this SOR per team decision — see the note below — so the advanced steps run 15–22, plus the Data Cloud permission self-assign 18a–18c, and there is no Einstein-GenAI step. Steps 23–23b that follow are the Digital Experiences enablement tail, a distinct Act-1 closer — NOT an advanced capability.)
-
-| # | Step id | Purpose | Backing API | Route |
-|---|---|---|---|---|
-| 15 | `enable-einstein-for-health-cloud` | write | Set org preference healthCloudGenAIPref = true | PATCH `/headless/invoke/platform/package-to-core-settings/set-preference` (proposed) |
-| 16 | `verify-einstein-for-health-cloud` | verify | Read org preference healthCloudGenAIPref | GET `/headless/invoke/platform/package-to-core-settings` (proposed) |
-| 17 | `enable-disease-surveillance` | write | Set org preference diseaseSurveillancePref = true | PATCH `/headless/invoke/platform/public-health-settings/set-preference` (implemented) |
-| 18 | `verify-disease-surveillance` | verify | Read public health settings preferences | GET `/headless/invoke/platform/public-health-settings/get-preferences` (implemented) |
-| 18a | `check-data-cloud-setup-permset` | verify | **Data API**: `PermissionSetAssignment WHERE PermissionSet.Name='GenieAdmin'` | GET `/services/data/v67.0/query/` |
-| 18b | `assign-data-cloud-setup-permset` | write | **Data API**: create `PermissionSetAssignment` (GenieAdmin → running admin) | POST `/services/data/v67.0/sobjects/PermissionSetAssignment` |
-| 18c | `verify-data-cloud-setup-permset` | verify | **Data API**: `PermissionSetAssignment` read-back (totalSize ≥ 1) | GET `/services/data/v67.0/query/` |
-| 19 | `check-cdp-provision-status` | read | Read Data Cloud provisioning status | GET `/headless/invoke/platform/cdpsetup-home` (implemented) |
-| 20 | `enable-data-cloud` | write | Enable Data Cloud (toggle CDP pref = true, install CIM package) | PATCH `/headless/invoke/platform/cdpsetup-home/toggle-cdp-enabled-pref` (implemented) |
-| 21 | `read-context-service-access` | read | Connect API: read Context Service access | GET `/services/data/v64.0/connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` (implemented) |
-| 22 | `enable-context-service` | write | Connect API: set Context Service access | PUT `/services/data/v64.0/connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` `{isEnabled:true}` |
-| 22a | `enable-care-plans` | write | Metadata `IndustriesSettings` `<enableCarePlansPreference>true>` (fullName `Industries`) | PUT `/headless/metadata` (Settings MERGE) |
-| 22b | `verify-care-plans` | verify | **Tooling**: `SELECT IsCarePlansPreferenceEnabled FROM IndustriesSettings` | GET `/services/data/v67.0/tooling/query/` |
-| 22c | `enable-integrated-care-management` | write | Metadata `IndustriesSettings` `<enableIntegratedCareManagementSetting>true>` (fullName `Industries`) — **AFTER 22b** | PUT `/headless/metadata` (Settings MERGE) |
-| 22d | `verify-integrated-care-management` | verify | **Tooling**: `SELECT IsIntegratedCareManagementSettingEnabled FROM IndustriesSettings` | GET `/services/data/v67.0/tooling/query/` |
-| 22e | `enable-care-gap` | write | Metadata `IndustriesSettings` `<enableCareGapPrefSetting>true>` (fullName `Industries`) | PUT `/headless/metadata` (Settings MERGE) |
-| 22f | `verify-care-gap` | verify | **Tooling**: `SELECT IsCareGapPrefSettingEnabled FROM IndustriesSettings` | GET `/services/data/v67.0/tooling/query/` |
-
-**Act 1 — advanced notes (ordering & findings):**
-
-- **`enable-einstein-for-health-cloud`** — this is the **real toggle** for "Einstein for Health Cloud" — the `healthCloudGenAIPref` master org preference via the Package to Core set-preference control (same route family as `enable-health-cloud-console`), body `{orgPref:"healthCloudGenAIPref", value:true}` → 200 `body:true`; read-back → `true`. `orgPref` is a CASE-SENSITIVE allowlist (`consolePreference` / `stdRelationshipPreference` / `healthCloudGenAIPref`); any other/mis-cased key throws. Reversible (`{value:false}`). Verify via `verify-einstein-for-health-cloud` (step 16), NOT the write echo. **This is DISTINCT from — and independent of — the org-wide Einstein Generative AI platform gate** (`generative-aisetup`, `OrgPermissions.HealthCloudGenerativeAI`), which 403s even for a System Admin and **no PermSet clears**; that org-wide toggle was **dropped from this SOR by team decision** because it is entitlement-gated and empirically independent of the HC pref (which read `true` while the platform gate still 403'd). So this step normally succeeds regardless of the org-wide GenAI entitlement — do NOT re-add an `enable-einstein-genai` step.
-- **`enable-disease-surveillance`** — set `diseaseSurveillancePref` = true → 200 `{body:true}`; read-back echoes `diseaseSurveillancePref: true`. The key discovery was the **preference-key VALUE**: camelCase **`diseaseSurveillancePref`** — NOT the earlier guess `DiseaseSurveillance` (which 500'd). This key is the VALUE passed to the `orgPref` parameter (the `@Key` name stays `orgPref`; it is not a parameter rename). Valid keys enumerable from the preferences read: `diseaseCaseClassificationPref`, `healthCloudGenAIPref`, `deDupeForDSPref`, `hasRemoteGeniePlatform`, `diseaseSurveillancePref`. The preferences read takes no args and returns the full map — assert on the `diseaseSurveillancePref` member, not a bare boolean. Reversible.
-- **`check-data-cloud-setup-permset` (18a) + `assign-data-cloud-setup-permset` (18b) + `verify-data-cloud-setup-permset` (18c) — Data Cloud setup PERMISSION prerequisite.** Both Data Cloud steps below sit behind the class-level guard `CDP.userCanSetupCdp`, whose chain requires the LICENSED user permission `AccessCustomerDataCloudSetup` (settingItem `userPermission.AccessCustomerDataCloudSetup` on `GenieDataPlatformStarterPsl`; granted by the standard Salesforce-managed **`GenieAdmin`** permission set). That permission is **NOT** part of a stock System Administrator, so a fresh admin **403s on `check-cdp-provision-status` AND `enable-data-cloud` until `GenieAdmin` is self-assigned** — exactly like the OmniStudioAdmin self-assign (steps 12–14). The flow self-assigns `GenieAdmin` to the running admin via the **Data API** (`PermissionSetAssignment` is a Data-API sObject): query for an existing assignment (18a); if 0 rows, resolve `PermissionSetId` via `SELECT Id FROM PermissionSet WHERE Name='GenieAdmin'` and POST `{AssigneeId, PermissionSetId}` (18b, idempotent, reversible via DELETE); gate on an independent read-back (18c, `totalSize ≥ 1`). This is the ONLY user-level permission gap in the whole workflow — a permission sweep across all steps confirmed every other step is covered by a stock System Administrator (`CustomizeApplication`/`ViewSetup`/`ModifyAllData`/`ViewAllProfiles`/`ManageProfilesPermissionsets`/`AssignPermissionSets`). Derived from the CDP access-check chain; not confirmed on the reference org because Data Cloud is not provisioned there. **Org-provisioning gate:** if `SELECT Id FROM PermissionSet WHERE Name='GenieAdmin'` returns 0 rows, the `GenieDataPlatformStarterPsl` license is absent — i.e. `OrgPermissions.DataCloud` is not provisioned — which is the true BLOCKING mis-provisioning condition (surface for remediation), NOT a user-permission gap. Runs after Disease Surveillance and BEFORE `check-cdp-provision-status` (which now `depends_on` `verify-data-cloud-setup-permset`).
-- **`check-cdp-provision-status`** — REPLACES the old `isCdpProvisioned` route (which 500s and is unreliable). Also read the Data Cloud license flag (GET `.../cdpsetup-home/has-data-cloud-license`): `hasDataCloudLicense → true`, `getProvisionStatus → {provisionStatus:"succeeded", stepsComplete:"6"}`. **If `provisionStatus == "succeeded"`, SKIP `enable-data-cloud`** (already on). **403 handling:** a 403 ACCESS_DENIED here is NOT automatically an org-mis-provisioning block — for a stock System Administrator it is first the USER-LEVEL missing `GenieAdmin` permission, which steps 18a–18c fix. Only a 403 that PERSISTS after `GenieAdmin` is assigned (or an absent `GenieAdmin` permission set = absent Data Cloud PSL) is the org-level `OrgPermissions.DataCloud` mis-provisioning gate to halt-and-surface on.
-- **`enable-data-cloud`** — real enablement API: the toggle writes CDP+CIM prefs atomically and kicks off async tenant provisioning. Run when `provisionStatus != "succeeded"` (the idempotency gate — skip when already provisioned, since toggling a provisioned tenant is disruptive). `hasDataCloudLicense` is EXPECTED to be `true` on a Health Cloud org — if it reads `false`, that is a BLOCKING error to surface for remediation, NOT a reason to skip the step. Provisioning is async: do NOT treat the PATCH 200 as "done" — poll `get-provision-status` until `stepsComplete` reaches 4–6 / `provisionStatus=succeeded`, then register the tenant-specific endpoint. **Effectively one-way** for a customer flow: deprovision requires `save-consent` first + cleared cleanup/dependency checks. Read the recommended `installCIMPackage` value from the CIM-package-install status before committing.
-- **`enable-context-service`** — a genuine Connect API resource in `industries-context-connect-api`, NOT headless-invoke. **Both the `{preferenceName}` and `{uniqueIdentifier}` path segments are the literal string `contextServiceEnabled`** — PUT `/services/data/v64.0/connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` with the **flat** body `{"isEnabled":true}` → 200 `{"isEnabled":true,"uniqueIdentifier":"contextServiceEnabled"}`; GET read-back confirms `isEnabled == true`. Org-access-check `IndustriesContext.orgHasIndustriesContextService`; underlying pref `ContextDefinitionsEnabled`. **GOTCHAS (both cost a prior run):** (1) the source's `ContextServiceAccessInputRepresentation` implies a `contextServiceAccessInput{}` wrapper, but this org 400s it (`JSON_PARSER_ERROR "Unrecognized field"`) — send the **flat** `{"isEnabled":true}`. (2) The earlier `missing_routes` "gap" was a mis-built path, NOT a route gap: using `preferenceName=ContextService` + `uniqueIdentifier=<org id>` at v67.0/v63.0 404s; the correct segments are `contextServiceEnabled`/`contextServiceEnabled` at **v64.0**. Verify by re-reading `getContextServiceAccess` and asserting `isEnabled == true` (gate on the read-back, not the write echo).
-- **`enable-care-plans` (22a) → `enable-integrated-care-management` (22c) → `enable-care-gap` (22e) — three Health Cloud care org preferences.** Each is a minimal single-field `IndustriesSettings` MERGE via `PUT /headless/metadata` (`fullName` `Industries` — the singleton drops the "Settings" suffix), body e.g. `<IndustriesSettings xmlns="http://soap.sforce.com/2006/04/metadata"><enableCarePlansPreference>true</enableCarePlansPreference></IndustriesSettings>` — **one `enable*` field per PUT** (a full retrieve→deploy fails on feature-coupled prefs). Each backs a component on the **Act-4 Health Cloud Console record page**: Enhanced Care Plans → the Care Plan Manager FlexCard (`IndustriesHCCarePlanManager`), Care Gap → the Care Gap Manager FlexCard (`HealthCloudCareManagementCareGapManager`), Integrated Care Management → the ICM console surface. With any of them OFF the console page **throws and cannot be saved** — that is why they live in Act 1 and gate the Act-4 `create-console-flexipage`. **STRICT ORDERING:** Enhanced Care Plans MUST be enabled BEFORE the Integrated Care Management master — Care Plans provisions the ICM console app the master depends on; a premature ICM PUT returns **400 INSUFFICIENT_ACCESS_OR_READONLY** on the field (recognized but read-only until the prereq is on). After Care Plans is on, the same PUT returns `success:true`. Care Gap is **independent** (no ordering dependency). **READ-BACK:** `enableCarePlansPreference` and `enableIntegratedCareManagementSetting` do NOT surface in the `GET /headless/metadata` `IndustriesSettings` XML (unlike `enableCareGapPrefSetting`, which does), so all three verify via **Tooling** SOQL on the matching `Is*Enabled` fields (`IsCarePlansPreferenceEnabled` / `IsIntegratedCareManagementSettingEnabled` / `IsCareGapPrefSettingEnabled`) for a uniform channel — gate on the read-back, not the write echo.
-
-### Act 1 — Digital Experiences (Experience Cloud) enablement
-
-> The Act-1 closer: turn **Digital Experiences** (Experience Cloud / Communities / Networks) ON at the org level. **Enablement ONLY — this workflow does NOT create an Experience site.** A site (`Network`) is built later, out of this skill, via Experience Builder (`POST /connect/communities` / the internal `createCommunity` path) — it cannot be cold-created via the Metadata API, so no site-creation step belongs here. This is a **third one-way gate**: once ON, Digital Experiences cannot be turned back off, so require explicit admin confirmation before dispatching `enable-digital-experiences`. Unlike the Person Accounts and Timeline gates, it does **not** gate any downstream Act-1 step — a decline just skips these three steps and continues.
-
-| # | Step id | Purpose | Backing API | Route |
-|---|---|---|---|---|
-| 23 | `read-communities-settings` *(optional — Settings deploys MERGE)* | read | Metadata `CommunitiesSettings` (fullName `Communities`) | GET `/services/data/vXX/headless/metadata?type=CommunitiesSettings&fullName=Communities` |
-| 23a | `enable-digital-experiences` | write | Metadata `CommunitiesSettings` `<enableNetworksEnabled>true>` | PUT `/services/data/vXX/headless/metadata` (Settings deploys MERGE) — **ONE-WAY / IRREVERSIBLE** |
-| 23b | `verify-digital-experiences` | verify | **Data API**: `SELECT Id FROM Network` (the definitive on/off probe) | GET `/services/data/v67.0/query/` |
-
-**Act 1 — Digital Experiences notes (ordering & findings):**
-
-- **`enable-digital-experiences`** — `PUT /services/data/vXX/headless/metadata {type:"CommunitiesSettings", fullName:"Communities", xmlRep:"<CommunitiesSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><enableNetworksEnabled>true</enableNetworksEnabled></CommunitiesSettings>"}` → `200 {"results":[{"success":true}]}`. **Settings singletons MERGE at the component level**, so the single-field PUT does NOT clobber other `CommunitiesSettings` values — the `read-communities-settings` snapshot is OPTIONAL (useful only for read-back). The metadata-singleton `fullName` is **`Communities`**, NOT `CommunitiesSettings`. **ONE-WAY / IRREVERSIBLE — no rollback** (there is no supported off-switch for Digital Experiences once enabled); require explicit user confirmation before dispatching, like the Person Accounts and Timeline gates. **Leave `enableOotbProfExtUserOpsEnable` untouched (`false`)** — that is a Patient-App-phase concern (external OOTB profile user ops), out of scope for initial setup. On enable, the org auto-materializes ~10 additional `CommunitiesSettings` fields (e.g. `enableCommunityWorkspaces`, `enableNameFieldsUserPIIEnabled`) — expanded surface is extra confirmation, not a problem. **The headless Metadata PUT is the write channel for this Settings enable — no zip deploy needed.**
-- **`verify-digital-experiences`** — the DEFINITIVE on/off probe is the **`Network` sObject via the Data API** (`SELECT Id FROM Network`), NOT a settings re-read. **DE ON → 200** (0 rows until a site is built — expected here, since this workflow creates no site). **DE OFF → 400 `INVALID_TYPE`** ("sObject type 'Network' is not supported") — the `Network` sObject only materializes once Digital Experiences is enabled. Gate `enable-digital-experiences` success on this returning 200, not on the deploy echo. `INVALID_TYPE` on the **Tooling** API is just the wrong endpoint — use the Data API.
-- **No site creation here.** The prior team decision dropped BOTH the DE enable AND a `build-patient-experience-site` step as "a separate, post-setup concern." This step re-adds **only the enablement** (a concrete `metadata_api` write, no longer a gap); patient-portal / Experience-site provisioning remains out of scope — it is tracked as a separate task under the Home Health guided setup.
-
-**Act 1 end state:** Health Cloud Foundation permission set assigned to the running admin, Console ON, FHIR Data Model ON, Discovery Framework enabled, Standard OmniStudio runtime ON and OmniStudioAdmin + OmniStudioUser self-assigned (+ any optional prefs tuned); Einstein for Health Cloud ON, Disease Surveillance ON, GenieAdmin self-assigned (the Data Cloud setup permission) and Data Cloud provisioned, Context Service ON (these advanced-capability entitlements are EXPECTED on a properly provisioned HC org; a genuinely absent one is a BLOCKING error, not a skip); Digital Experiences ENABLED (`Network` sObject queryable) — or SKIPPED if the admin declined the one-way toggle — with **no Experience site created** (deliberately out of scope). Underlying setup-page nodes: `SiteManagementSettingsHc` (legacy license surface), `ClinicalDataModelSettings`, `FhirSubscriptionSetup`, `PublicHealthSettings`, `OmniStudioSettings`, `CommunitiesSettings`.
-
----
-
-## Act 2 of 4 — Data Protection & Account Configuration
-
-> Runs after Act 1, before Act 3. `enable-data-protection` is REQUIRED for HIPAA. `enable-contacts-to-multiple-accounts` MUST complete before Act 3's Person Accounts.
-
-| # | Step id | Purpose | Backing API | Route |
-|---|---|---|---|---|
-| 24 | `enable-data-protection` | write | Set Consent Management pref = true | PATCH `/headless/invoke/platform/consent/consent-management/handle-prefs` |
-| 25 | `read-language-settings` *(optional — Settings deploys MERGE)* | read | Metadata `LanguageSettings` (fullName `Language`) | GET `/services/data/vXX/headless/metadata?type=LanguageSettings&fullName=Language` |
-| 26 | `enable-translation-workbench` | write | Metadata `LanguageSettings` `<enableTranslationWorkbench>true>` | PUT `/services/data/vXX/headless/metadata` (Settings deploys MERGE) |
-| 27 | `read-account-settings` *(optional — Settings deploys MERGE)* | read | Metadata `AccountSettings` (fullName `Account`) | GET `/services/data/vXX/headless/metadata?type=AccountSettings&fullName=Account` (or Tooling SOQL) |
-| 27a | `enable-standard-relationship-objects` | write | Set org preference stdRelationshipPreference = true | PATCH `/headless/invoke/platform/package-to-core-settings/set-preference` |
-| 27b | `verify-standard-relationship-objects` | verify | Read org preference stdRelationshipPreference | GET `/headless/invoke/platform/package-to-core-settings` |
-| 28 | `enable-contacts-to-multiple-accounts` | write / **org-creation prereq** | `ContactsToMultipleAccounts` org feature (at org creation) — the pref PUT alone does NOT provision the object | scratch-def `features:["ContactsToMultipleAccounts"]` (recommended) / Setup UI Account Settings save |
-| 29 | `verify-contacts-to-multiple-accounts` | verify | Data API: `SELECT Id FROM AccountContactRelation LIMIT 1` (RUNTIME queryability, not a pref/catalog read) | GET `/services/data/v67.0/query/` |
-
-**Act 2 — notes (ordering & findings):**
-
-- **`enable-data-protection`** — PATCH `handle-prefs {consentManagementEnabled:true}` → 200 (empty body; endpoint documents 204). This is the correct control for the "Data Protection and Privacy" toggle on the Consent Management page (sets `ORG_PREFERENCE_CONSENT_MANAGEMENT_ENABLED`; needs View Setup only, no paid add-on). **REQUIRED for HIPAA — mark the final summary INCOMPLETE if skipped.** The previous wiring provisioned the separate paid Privacy Center add-on, which was WRONG (it reported "enabled" while this toggle stayed OFF). **Verify programmatically via the `read-health-cloud-setup-state` read-back — do NOT report "no getter exists":** `handle-prefs` writes `ORG_PREFERENCE_CONSENT_MANAGEMENT_ENABLED`, the SAME org preference the setup-state read surfaces as its `CONSENT_MANAGEMENT_ENABLED` feature (via the `DataPrivacyProtection` map entry — confirmed to be the identical constant). So re-read `get-health-cloud-setup-state` and assert `CONSENT_MANAGEMENT_ENABLED` is `SUCCESS`/enabled. **The aggregator can LAG the write by a few seconds — a single immediate `NOT_STARTED` read does NOT mean the write failed; re-poll.** A `handle-prefs` 200 plus a subsequent `CONSENT_MANAGEMENT_ENABLED=SUCCESS` read is the confirmation. Do NOT switch to a `OrgPreferenceSettings/ConsentManagementEnabled` metadata deploy — handle-prefs is the proven control and that deploy path is unnecessary (and would be a deploy-blocked dead end). Reversible (`{consentManagementEnabled:false}`).
-- **`enable-translation-workbench`** — `PUT /services/data/vXX/headless/metadata {type:"LanguageSettings", fullName:"Language", xmlRep:"<LanguageSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><enableTranslationWorkbench>true</enableTranslationWorkbench></LanguageSettings>"}` → `{success:true}`; Tooling read-back `enableTranslationWorkbench == true`. **Settings singletons MERGE at the component level**, so the single-field PUT did NOT clobber other LanguageSettings values — the `read-language-settings` snapshot is OPTIONAL. The metadata-singleton `fullName` is **`Language`**, NOT `LanguageSettings` and NOT `Organization` (metadata singletons drop the "Settings" suffix; a PUT with `fullName=Organization` fails `FIELD_INTEGRITY_EXCEPTION`). Same field the `LabelWorkbenchSetup` skill (team Globalization, approved) toggles. **The headless Metadata REST resource is the write channel here and is proven — no zip deploy needed for this Settings singleton.** If `/headless/metadata` genuinely 404s on a stripped org, fall back to the manual Setup UI.
-- **`enable-standard-relationship-objects`** — the **"Standard Objects for Account and Contact Relations"** toggle on the *Package To Core Settings* page. Sourced from the `PackageToCoreSettings` SOR: set-preference with the CASE-SENSITIVE allowlisted `orgPref=stdRelationshipPreference` (the "standard relationship junction objects" pref), body `{orgPref:"stdRelationshipPreference", value:true}` → 200. Same route + control family as `enable-health-cloud-console` (`consolePreference`) and `enable-einstein-for-health-cloud` (`healthCloudGenAIPref`). The allowlist is exactly `consolePreference` / `stdRelationshipPreference` / `healthCloudGenAIPref`; a mis-cased or unknown key returns HTTP **500 CONTROLLER_ERROR** (not a clean 400). **Always send `value:true` EXPLICITLY** — an omitted or `null` value defaults to false and persists false, indistinguishable from an intentional disable. Verify via `verify-standard-relationship-objects` (a read-back returning `true`), NOT the write echo. Reversible (`value:false`). Runs right before `enable-contacts-to-multiple-accounts`. Observed: `is-package-enabled` → `false` (legacy HealthCloud managed package absent); baseline read → `false`; set `{orgPref:"stdRelationshipPreference", value:true}` → 200 `body:true`; read-back → `true` (persisted). The write/persist/verify contract works AND persists on a managed-package-free core org. **CAVEAT (from the source SOR) refined:** the pref reads/persists `true` regardless of managed-package presence; the SOR's **"no runtime effect until the managed package is installed"** claim governs downstream *runtime* behavior (junction-object materialization), which is not observable via this toggle read — so a `true` read-back is authoritative for the setup step, not for runtime materialization.
-- **`enable-contacts-to-multiple-accounts` — MUST be provisioned AT ORG CREATION; the preference PUT alone does NOT enable it.** The modern `AccountContactRelation` object is NOT runtime-provisioned by the `AccountSettings.enableRelateContactToMultipleAccounts` **preference**. Runtime readability requires a SEPARATE org permission, `SharedContactsReady` (entity `apiAccess="Sales.orgHasSharedContactsReadyOrInternal"`). The two are DECOUPLED BY DESIGN: enabling the preference only scaffolds schema defaults (picklist values / default page layout / FLS on `AccountContactRelation`) — it NEVER sets `SharedContactsReady` and never enqueues the migration. `SharedContactsReady` is set ONLY by **(a)** creating the org with the **`ContactsToMultipleAccounts` feature** (which sets pref + ready-perm + status `UPGRADE_SUCCEEDED` directly at creation — no data to migrate on a fresh org; **RECOMMENDED for a new HC org**), or **(b)** an async PK-chunking enablement job, whose ONLY triggers are the interactive Setup UI **Account Settings** save (or an internal tool) on a CLEAN org whose pref is still OFF. Enabling the feature sets pref→ready-perm→status in sequence, and the feature-enabled check keys on the READY PERM (not the pref) — the feature is "on" only when the perm is set.
-  - **A Metadata-API PUT does NOT enable CMA.** The settings validation rejects any deploy that would actually CHANGE the pref OFF→ON ("cannot update enable-shared-contacts via the Metadata API"); a PUT succeeds only when the pref is ALREADY on (a no-op echo) — that is NOT evidence the object was provisioned. Only `SharedContactsEnabled` is MD-API-declarative; `SharedContactsReady` is not.
-  - **CATCH-22:** if the pref is ON but enablement never completed (status ≠ `UPGRADE_SUCCEEDED`, ready-perm off — how an HC org created WITHOUT the feature lands), the org is **UNREPAIRABLE in place**: Setup UI disable throws a wrong-state-for-disabling error, a plain re-save is a no-op (pref already on, so the OFF→ON job never runs), and MD-API can't touch the pref. **RECREATE the org with `"features":["ContactsToMultipleAccounts"]`.** Symptom on the stuck org: pref reads `true`, yet `AccountContactRelation` SOQL/describe fails 400 `INVALID_TYPE` and `getGlobalDescribe` is null — the exact string the Console **Household** tab shows ("The requested resource does not exist").
-  - **HARD ORDERING / prerequisite:** CMA (real runtime provisioning) is required before `enable-person-accounts` AND for the Console Household tab (arcGraph — see Act 4). Because the runtime dispatch calls in this workflow CANNOT enable it, treat this as an **org-creation prerequisite**: verify it (step 29), and if absent, stop and recreate the org with the feature. The AccountSettings field name is `enableRelateContactToMultipleAccounts` (NOT `enableMultipleAccounts`); the metadata-singleton `fullName` is `Account`.
-- **`verify-contacts-to-multiple-accounts` — RUNTIME queryability probe, NOT a preference/catalog read.** Data API: `SELECT Id FROM AccountContactRelation LIMIT 1`. Provisioned → **200** (0 rows is fine on a fresh org). NOT provisioned → **400 `INVALID_TYPE`** ("sObject type 'AccountContactRelation' is not supported"). Gate step 28 / downstream Person Accounts + the Household tab on the **200**, exactly like `verify-digital-experiences` gates on the `Network` sObject. **Do NOT gate on the `AccountSettings.enableRelateContactToMultipleAccounts` pref (Tooling metadata read) or on an `EntityDefinition` catalog row** — both read true/present on a pref-only org and FALSE-GREEN it. A 400 here means CMA was never truly enabled → recreate the org with the `ContactsToMultipleAccounts` feature. The API name is the SINGULAR `AccountContactRelation` (NOT `AccountContactRelationship`).
-
-**Act 2 end state:** Data Protection/Consent Management ON (HIPAA); Translation Workbench ON; Standard Objects for Account and Contact Relations (`stdRelationshipPreference`) ON and verified; Contacts-to-Multiple-Accounts genuinely RUNTIME-PROVISIONED (`AccountContactRelation` queryable → 200), NOT merely pref-flipped — if the runtime probe 400s, the org was created without the `ContactsToMultipleAccounts` feature and must be recreated with it (no in-place fix). Underlying setup-page nodes: `ConsentManagement`, `PackageToCoreSettings`, `AccountSettings`.
-
----
-
-## Act 3 of 4 — Person Accounts & Record Types
-
-> Runs after Act 2. **Enabling Person Accounts is PERMANENT and CANNOT be undone.** Do not dispatch `enable-person-accounts` until readiness passes, terms are accepted, Contacts-to-Multiple-Accounts is ON, and the admin has explicitly confirmed. If the admin declines, END the workflow — every remaining step depends on it.
-
-| # | Step id | Purpose | Backing API | Route |
-|---|---|---|---|---|
-| 31 | `create-business-account-record-type` | write | Metadata `RecordType` `Account.Business_Account` | POST `/headless/metadata` — **gap `metadata_only`** |
-| 32 | `person-account-readiness` | validate | Check Person Account readiness | GET `/headless/invoke/platform/person-account-settings/check-person-account-readiness` |
-| 33 | `accept-person-account-terms` | write | Accept Person Account terms & conditions | PATCH `/headless/invoke/platform/person-account-settings/accept-terms-and-conditions` |
-| 34 | `verify-person-account-terms` | verify | Check Person Account readiness | GET `/headless/invoke/platform/person-account-settings/check-person-account-readiness` |
-| 35 | `enable-person-accounts` | write | Enable Person Accounts | PATCH `/headless/invoke/platform/person-account-settings/enable-person-accounts` — **IRREVERSIBLE** |
-| 36 | `verify-person-account-record-types` | verify | Tooling: `RecordType WHERE SobjectType='Account'` (artifact 2 of 4) | GET `/services/data/v67.0/tooling/query/?q=SELECT+Id,Name,SobjectType+FROM+RecordType+WHERE+SobjectType='Account'` |
-| 36a | `verify-person-account-object` | verify | Tooling: `FieldDefinition` `IsPersonAccount` on Account (artifact 1 of 4) | GET `/services/data/v67.0/tooling/query/?q=SELECT+QualifiedApiName+FROM+FieldDefinition+WHERE+EntityDefinition.QualifiedApiName='Account'+AND+QualifiedApiName='IsPersonAccount'` |
-| 36b | `verify-person-account-layout` | verify | Tooling: `Layout WHERE TableEnumOrId='Account'` (artifact 3 of 4) | GET `/services/data/v67.0/tooling/query/?q=SELECT+Id,Name,TableEnumOrId+FROM+Layout+WHERE+TableEnumOrId='Account'` |
-| 36c | `verify-account-contact-relation` | verify | Data API: `SELECT Id FROM AccountContactRelation LIMIT 1` (artifact 4 of 4 — RUNTIME queryability, not an `EntityDefinition` catalog read) | GET `/services/data/v67.0/query/` |
-| 37 | `assign-person-account-record-type-to-profiles` | write | Metadata `Profile` — Patient/Provider/PersonAccount RT visibilities + defaults, on Admin & Standard | PUT `/headless/metadata` (implemented) |
-| 38 | `create-patient-layout` *(custom-layouts only)* | write | Tooling `Layout` sObject (`PersonAccount` entity) | POST `/services/data/v64.0/tooling/sobjects/Layout` |
-| 39 | `create-provider-layout` *(custom-layouts only)* | write | Tooling `Layout` sObject (`PersonAccount` entity) | POST `/services/data/v64.0/tooling/sobjects/Layout` |
-| 40 | `create-patient-record-type` | write | Metadata `RecordType` `PersonAccount.Patient` | POST `/headless/metadata` — **gap `metadata_only`** |
-| 41 | `create-provider-record-type` | write | Metadata `RecordType` `PersonAccount.Provider` | POST `/headless/metadata` — **gap `metadata_only`** |
-| 42 | `assign-person-account-layouts-to-profiles` *(custom-layouts only; AFTER the Patient/Provider record types exist — steps 40/41)* | write | Metadata `Profile` `<layoutAssignments>` — Patient/Provider RT → custom layout, on Admin & Standard | PUT `/headless/metadata` |
-
-**Act 3 — notes (ordering, contracts & findings):**
-
-- **`create-business-account-record-type`** is a **HARD PREREQUISITE** for Person Accounts — `checkPersonAccountReadiness` reports `accountRecordTypeCreated=false` (and `allStepsComplete=false`) until at least one custom Account record type exists. A fresh org has zero, so this MUST run before `person-account-readiness`. Contract: POST `/headless/metadata` with `{type:"RecordType", fullName:"Account.Business_Account", xmlRep:<xml>}` where **`xmlRep` MUST be a `<CustomObject>` root wrapping a nested `<recordTypes>` block** — a top-level `<RecordType>` is REJECTED (400 VALIDATION_ERROR). Success → 200 `{"results":[{"success":true,"id":"012...","fullName":"Account.Business_Account"}]}`. Asymmetric read-back: GET returns a top-level `<RecordType>`. The metadata-addressing `fullName` is `Account.Business_Account`; the `<fullName>` inside `<recordTypes>` is the bare dev name `Business_Account`.
-- **`person-account-readiness`** — gate HARD: proceed to enablement only when `allStepsComplete == true`. Gates: `accountRecordTypeCreated` (needs the Business Account RT above), `profilePermsSet` (Account read → Contact read), `orgWideSharingSet` (Contacts default = Controlled By Parent), and `termsConditionsAccepted`. On a false gate the response carries `actionLinks {recordTypesLink, orgWideSharingLink, profileMgmtLink}` — surface the relevant one. `warnProfiles[]`/`errorProfiles[]` list blocking profiles; `hasError` flags a hard stop.
-- **`accept-person-account-terms`** — returns `{}` and flips `termsConditionsAccepted` false→true. Irreversible acknowledgement (no rollback). Gate on the readiness re-read (`verify-person-account-terms`, assert `termsConditionsAccepted == true` — that is the field name, **NOT** `termsAccepted`).
-- **`enable-person-accounts` — IRREVERSIBLE, no rollback.** Present the final irreversibility warning and require explicit user confirmation before dispatching; if declined, END the workflow. End-to-end: after readiness reached `allStepsComplete==true`, the enable call → 200 with `{personAccountsEnabled:true, personAccountsEnabledDate:..., hasError:false}`. The platform AUTO-PROVISIONS the Person Account artifacts asynchronously. **The immediate response (`personAccountsEnabled==true && hasError==false`) confirms the call was accepted, but is NOT the success gate. Do NOT check `personAccountsAPIAvailable` at all — it does NOT update reliably on the Health Cloud Admin Feature Setup page (it stays `false` well past a successful enable), so it is neither a success nor a failure signal; it has been removed as a check.** The TRUE success gate is the **FOUR Person Account artifacts** being present, verified by the four sibling verify steps — `verify-person-account-object`, `verify-person-account-record-types`, `verify-person-account-layout`, `verify-account-contact-relation` (`assign-person-account-rt-visibility` depends on all four). Async propagation lag between the enable call and the artifacts materializing is EXPECTED — poll the four artifact verifies until present, do NOT treat the lag as failure. Depends on `verify-person-account-terms` AND `verify-contacts-to-multiple-accounts`.
-- **Verify ALL FOUR Person Account artifacts (steps 36, 36a–36c)** — this workflow requires confirming four artifacts post-enable, not record types alone (record types alone would false-green if the object, layout, or ACR object silently failed to materialize). Each is a Tooling query; all depend on `enable-person-accounts`; together they gate `assign-person-account-record-type-to-profiles` (SOR: `assign-person-account-rt-visibility`):
-  - **(2 of 4) `verify-person-account-record-types`** — `SELECT Id, Name, SobjectType FROM RecordType WHERE SobjectType='Account'` returns TWO Account record types: the Business Account RT plus the auto-provisioned "Person Account" RT (the definitive enablement artifact). `DeveloperName` is NOT queryable on RecordType at v67.0.
-  - **(1 of 4) `verify-person-account-object`** — `SELECT QualifiedApiName FROM FieldDefinition WHERE EntityDefinition.QualifiedApiName='Account' AND QualifiedApiName='IsPersonAccount'` → 1 row. The `IsPersonAccount` field materializes on Account ONLY once Person Accounts is enabled, so it is the authoritative object-level signal. Do NOT query `EntityDefinition` for an `IsPersonAccountEnabled` column — no such column (400 INVALID_FIELD). (The sObject may lag immediately post-enable — re-query after propagation.)
-  - **(3 of 4) `verify-person-account-layout`** — `SELECT Id, Name, TableEnumOrId FROM Layout WHERE TableEnumOrId='Account'` → "Account Layout"; assert ≥ 1 Account page layout exists to render the person account.
-  - **(4 of 4) `verify-account-contact-relation` — RUNTIME queryability, NOT an `EntityDefinition` catalog read.** `SELECT Id FROM AccountContactRelation LIMIT 1` via the **Data API** → assert **200** (0 rows is fine). A 400 `INVALID_TYPE` means the object is NOT runtime-provisioned — CMA was pref-flipped without the `SharedContactsReady` perm (see Act 2 step 28); recreate the org with the `ContactsToMultipleAccounts` feature. **Do NOT use `EntityDefinition`** — it returns a catalog row for the schema def even when the object is not provisioned, so it FALSE-GREENS a pref-only org. This is also gate #5 for the Console **Household** tab (Act 4). The API name is the SINGULAR **`AccountContactRelation`** (NOT `AccountContactRelationship`).
-- **`assign-person-account-record-type-to-profiles`** — Metadata `Profile` **component-level MERGE — send the MINIMAL `<recordTypeVisibilities>` fragment, NOT the ~1MB full Profile.** A `PUT type=Profile` carrying ONLY the target `<recordTypeVisibilities>` blocks assigns RT visibility WITHOUT wiping other perms (`PermissionsModifyAllData` on the System Administrator profile stayed `true` after the deploy). Never round-trip the whole Profile; never GET-edit-redeploy the 1MB body. The `/headless/metadata` verb is create-vs-update split: **POST = CREATE** (returns `DUPLICATE_VALUE`), **PUT = UPDATE**; standard Profiles always pre-exist, so this step MUST use **PUT**. Assign the **Patient and Provider** Person Account record types (plus the base Person Account RT and the Business Account RT), and set the record-type defaults, on **BOTH standard user profiles — do NOT stop after Admin** (the fresh run applied it to Admin only): **System Administrator (`fullName=Admin`)** and **Standard User (`fullName=Standard`)**. Standard profiles are addressed by their ALIAS (`Admin`/`Standard`), NOT their display name; confirm they exist first via `SELECT Id, Name FROM Profile WHERE Name IN ('System Administrator','Standard User')`. Per profile send ONE PUT with these FOUR `<recordTypeVisibilities>` (Person Account RTs addressed `PersonAccount.<Name>`, NOT `Account.<Name>`; `personAccountDefault` is a valid child): `Account.Business_Account` → `visible=true, default=true` (default for BUSINESS accounts); `PersonAccount.PersonAccount` → `visible=true, personAccountDefault=true` (Selected + default for PERSON accounts); `PersonAccount.Patient` → `visible=true` (Selected); `PersonAccount.Provider` → `visible=true` (Selected). Gotcha: whenever any RT is `visible=true`, exactly ONE must be `default=true` per object (the business default) AND exactly ONE `personAccountDefault=true` (the person-account default), or the deploy fails `FIELD_INTEGRITY_EXCEPTION: No default record type specified`. **Runs AFTER `create-patient-record-type` + `create-provider-record-type`** (`depends_on`) so `PersonAccount.Patient` / `PersonAccount.Provider` exist before the profiles reference them. Gate on an independent per-profile read-back of `<recordTypeVisibilities>`, never the deploy echo.
-- **`create-patient-layout` / `create-provider-layout`** *(custom-layouts only — skip on `layout_strategy=default-layout`)* — Layout create IS wired — just NOT through `/headless/metadata` (that path 400s "Invalid fullName" because `Layout` isn't in the headless dispatcher's metadata allowlist). Use the **native Tooling REST `Layout` sObject** instead: `POST /services/data/v64.0/tooling/sobjects/Layout` with body `{"FullName":"PersonAccount-Patient Layout","Metadata":{"layoutSections":[…]}}` → **201** `{id, success:true}`. This is a plain Tooling REST call (same class as every other step here), not a zip deploy. To MODIFY an existing layout, PATCH the same sObject (`PATCH /services/data/v64.0/tooling/sobjects/Layout/<id>`, body ONLY `Metadata` + `FullName` — any other top-level field → 400 `FIELD_INTEGRITY_EXCEPTION`).
-  - **CRITICAL — target the `PersonAccount` entity, NOT `Account`.** Patient/Provider are PERSON record types, so their layouts live on the `PersonAccount` pseudo-entity: **`FullName` MUST be `PersonAccount-<Name> Layout`** (e.g. `PersonAccount-Patient Layout` / `PersonAccount-Provider Layout`), which resolves `EntityDefinitionId=PersonAccount` / `TableEnumOrId=PersonAccount`. Placing `Person*` fields on an `Account-`prefixed (business) layout → 400 `FIELD_INTEGRITY_EXCEPTION "Cannot use field:PersonBirthdate in a layout"`. The org's auto-provisioned default is `PersonAccount-Person Account Layout`; business Account layouts stay under `EntityDefinitionId=Account`. Read the family with `SELECT Id,Name,TableEnumOrId,EntityDefinitionId FROM Layout WHERE EntityDefinitionId='PersonAccount'`.
-  - **Required layout fields differ by entity:** on `PersonAccount` only `Name` is required; the business `Account` entity additionally requires `ParentId` (else 400 "Layout must contain an item for required layout field: ParentId"). Don't copy the Account requirement onto the PersonAccount layout. **The required `Name` layoutItem MUST carry `behavior: "Required"` — not `"Edit"`**: `behavior:"Edit"` on `Name` 400s `FIELD_INTEGRITY_EXCEPTION "Field:Name must be Required"`, and OMITTING `Name` entirely 400s "Layout must contain an item for required layout field: Name". Person accounts also can't place the discrete `FirstName`/`LastName`/`Salutation` name components alongside the compound `Name` — use `Name`.
-  - **Fields — use only what exists, do NOT fabricate.** This org (Standard OmniStudio, NO HealthCloud managed package) has NO `HealthCloudGA__*` custom fields, so MRN / Primary Care Provider / NPI Number / Specialties / Care Team etc. do NOT exist here — omit them. The reference layouts used standard Person Account demographic fields: Patient — `Name`, `PersonBirthdate`, `PersonGender`, `PersonMaritalStatus`, `PersonEmail`, `PersonMobilePhone`, `PersonHomePhone`, `PersonMailingAddress`, `OwnerId`; Provider — `Name`, `PersonTitle`, `PersonDepartment`, `PersonEmail`, `PersonMobilePhone`, `PersonOtherPhone`, `PersonMailingAddress`, `OwnerId`. Only if the org DOES carry Health Cloud custom person fields (`*__pc`) should you add the role-specific ones (Patient: Medical Record Number, Primary Care Provider, Care Team…; Provider: NPI Number, Specialties, License…) — and only after confirming each exists via the Account describe.
-  - Gate on an independent read-back (`SELECT Id,Name,TableEnumOrId,EntityDefinitionId FROM Layout WHERE EntityDefinitionId='PersonAccount'` shows Patient + Provider), not the POST echo. Creating the layouts does NOT assign them — that is a **separate** step, `assign-person-account-layouts-to-profiles` (see below), a Profile `<layoutAssignments>` PUT. **The mapping is NOT done by `create-*-record-type`** — a RecordType create is a `<CustomObject><recordTypes>` PUT and structurally cannot carry `<layoutAssignments>` (that element lives on the Profile). On `layout_strategy=default-layout` `create-patient-layout`/`create-provider-layout` AND `assign-person-account-layouts-to-profiles` are all skipped, and the person RTs fall back to `PersonAccount-Person Account Layout`.
-- **`assign-person-account-layouts-to-profiles`** *(custom-layouts only — skip on `layout_strategy=default-layout`)* — assigns the custom Patient/Provider layouts to their record types. Layout-to-RT assignment is a **Profile** `<layoutAssignments>` element (NOT a RecordType/CustomObject element), so it is a distinct `PUT /headless/metadata` `type=Profile` write — the same **component-level MERGE** used for `<recordTypeVisibilities>`, so send a MINIMAL fragment (never the ~1.3 MB full Profile). Apply ONE PUT PER PROFILE, on BOTH standard profiles (`fullName=Admin`, `fullName=Standard`). `xmlRep` = `<Profile><layoutAssignments><layout>PersonAccount-Patient Layout</layout><recordType>PersonAccount.Patient</recordType></layoutAssignments><layoutAssignments><layout>PersonAccount-Provider Layout</layout><recordType>PersonAccount.Provider</recordType></layoutAssignments></Profile>` (record types addressed `PersonAccount.<Name>`, NEVER `Account.<Name>`; `<layout>` is the exact FullName created upstream). Merge is additive — the base `PersonAccount.PersonAccount` RT stays on its stock layout. **This is the LAST Act 3 write — runs AFTER `create-patient-layout` + `create-provider-layout`, `create-patient-record-type` + `create-provider-record-type` (the referenced `PersonAccount.Patient`/`PersonAccount.Provider` RTs must exist first, or the Profile deploy 400s), and `assign-person-account-rt-visibility`** (`depends_on`). Gate on an independent per-profile read-back — GET `/headless/metadata?type=Profile&fullName=<Admin|Standard>` and confirm each profile's `xmlRep` carries both `<layoutAssignments>` — never the deploy echo.
-- **`create-patient-record-type` (`PersonAccount.Patient`) / `create-provider-record-type` (`PersonAccount.Provider`)** — separate actions (not bundled). Patient and Provider are INDIVIDUALS, so both record types are created on the special **`PersonAccount`** metadata object (addressed `PersonAccount.Patient` / `PersonAccount.Provider`), NEVER on `Account` — `Account` is reserved for BUSINESS-account record types (`Account.Business_Account`). Same `<CustomObject>`/`<recordTypes>` contract as the Business Account RT (top-level `<RecordType>` rejected 400). Layout assignment is NOT part of this step — the RecordType `<recordTypes>` block cannot carry `<layoutAssignments>`; mapping each RT to its custom layout is the separate `assign-person-account-layouts-to-profiles` step (custom-layouts only; otherwise the RTs keep the default Person Account layout). The `<fullName>` inside `<recordTypes>` is the bare dev name (`Patient` / `Provider`); the metadata-addressing `fullName` is `PersonAccount.Patient` / `PersonAccount.Provider`. Both MUST run BEFORE `assign-person-account-record-type-to-profiles`, which sets their visibility + defaults on the two standard profiles.
-- **`verify-person-account-record-types` — SObjectType(SOQL) vs Metadata-API namespace are ORTHOGONAL, do NOT "reconcile" them.** The verify query is `SELECT Id, Name, SobjectType FROM RecordType WHERE SobjectType='Account'`, and it correctly filters on `'Account'` because at the SOQL/Tooling layer **every** Account-family record type — business AND person-account — reports `SobjectType='Account'`. That is expected and does NOT mean the person-account RTs are addressed `Account.<Name>` in the **Metadata API**: they live under the `PersonAccount` pseudo-object (`PersonAccount.PersonAccount` / `PersonAccount.Patient` / `PersonAccount.Provider`): `GET .../headless/metadata?type=RecordType&fullName=PersonAccount.PersonAccount` (and `PersonAccount.Patient`) → **200**; the `Account.<Name>` forms (`Account.PersonAccount`, `Account.Patient`) → **404 `INVALID_CROSS_REFERENCE_KEY` "Metadata not found"**. So a static check that reads `SobjectType='Account'` and suggests flipping the create/assign `fullName`s to `Account.<Name>` is a **false positive** — doing so reintroduces the object-namespace bug. Only `Account.Business_Account` uses the `Account` namespace.
-
-**Act 3 end state:** Business Account RT created; readiness passed; terms accepted; Person Accounts ENABLED (permanent) and all four artifacts verified (object, record type, page layout, Account Contact Relationship object); Patient/Provider record types created on `PersonAccount` (+ custom layouts when chosen); Patient, Provider, and base Person Account record types made visible on **both** standard profiles (System Administrator, Standard User) with Person Account set as the person-account default and Business Account as the business default. Underlying setup-page nodes: `PersonAccountSettings`, `AccountSettings`, `EnhancedProfiles`.
-
----
-
-## Act 4 of 4 — Patient Card & Timeline
-
-> The **final** act. Hard-depends on Person Accounts (Act 3). Contains the second irreversible gate — the org-level Timeline toggle. Not done until this act's end state is reached.
-
-| # | Step id | Purpose | Backing API | Route |
-|---|---|---|---|---|
-| 42 | `discover-account-flexipage` | read | Tooling: `FlexiPage WHERE EntityDefinitionId='Account' AND Type='RecordPage'` | GET `/services/data/v67.0/tooling/query/...` |
-| 43 | `create-account-flexipage` *(skip if 42 found a page)* | write | Metadata `FlexiPage` (standalone Account RecordPage) | POST `/services/data/vXX/headless/metadata` |
-| 44 | `verify-account-flexipage` | verify | Tooling `FlexiPage` read-back (0 → 1) | GET `/services/data/v67.0/tooling/query/...` |
-| 45 | `activate-account-flexipage` | write | Metadata `CustomObject` Account — `View/Large/Flexipage` actionOverride (MERGE) | PUT `/services/data/vXX/headless/metadata` |
-| 46 | `verify-account-flexipage-active` | verify | Metadata GET/Tooling — assert the `View/Large/Flexipage` override present | GET `/services/data/vXX/headless/metadata?type=CustomObject&fullName=Account` |
-| 47 | `read-patient-flexipage` | read | Metadata `FlexiPage` (RMW snapshot — feeds the binds below) | GET `/services/data/vXX/headless/metadata?type=FlexiPage&fullName={devName}` |
-| 48 | `discover-patient-card-flexcard` | read | **Data API**: `OmniUiCard WHERE Name LIKE '%Patient%Card%'` — INFORMATIONAL only; the Patient Card is the standard `healthcloud:patientCard` component (not an OmniUiCard row), so 0 rows does NOT block step 49 | GET `/services/data/v67.0/query/` |
-| 49 | `add-patient-card-to-flexipage` | write | **Whole-page `dispatch` PUT** binding the standard `healthcloud:patientCard` component into `main`, NO property block, WITH a `<visibilityRule>` ({!Record.IsPersonAccount} EQUAL true) so it shows only on person accounts | `PUT /services/data/vXX/headless/metadata {type:FlexiPage, fullName, xmlRep:<whole page>}` |
-| 49b | `verify-patient-card-in-flexipage` | verify | Metadata `FlexiPage` read-back — assert `healthcloud:patientCard` present in `main` WITH its `{!Record.IsPersonAccount}` EQUAL true `<visibilityRule>` (+ no pre-existing component dropped); the modeled gate for step 49 (`add-timeline-to-flexipage` depends on THIS, not the raw write) | GET `/services/data/vXX/headless/metadata?type=FlexiPage&fullName={devName}` |
-| 50 | `handle-timeline-toggle` | write | Handle Timeline org toggle (value=true) | PATCH `/headless/invoke/platform/timeline/handle-timeline-toggle` — **ONE-WAY / IRREVERSIBLE** |
-| 51 | `verify-timeline-enabled` | verify | Read Timeline org preference | GET `/headless/invoke/platform/timeline/get-timeline-org-pref` |
-| 51b | `check-timeline-configurations` | read | Tooling: active Account-anchored `TimelineObjectDefinition`s (HC seeds 4) — gates 52/53 | GET `/services/data/v67.0/tooling/query/...` |
-| 52 | `save-timeline-configuration` | write | Save timeline configuration (config) — **SKIP if 51b found ≥1 (seeded set already satisfies)** | PATCH `/headless/invoke/platform/timeline/save-timeline-configuration` |
-| 53 | `activate-timeline-configuration` | write | Set timeline configuration active status (RecordId, isActivated=true) — **SKIP with 52** | PATCH `/headless/invoke/platform/timeline/set-timeline-configuration-active-status` |
-| 54 | `verify-timeline-configuration-active` | verify | Tooling: ≥1 active Account-anchored `TimelineObjectDefinition` (seeded or custom) | GET `/services/data/v67.0/tooling/query/...` |
-| 55 | `add-timeline-to-flexipage` | write | **Whole-page `dispatch` PUT** binding `industries_common:timeline` into `main` WITH the `timelineConfigs` valueList of the 4 OOTB configs AND a `<visibilityRule>` ({!Record.IsPersonAccount} EQUAL true) so it shows only on person accounts (AFTER the toggle) | `PUT /services/data/vXX/headless/metadata {type:FlexiPage, fullName, xmlRep:<whole page>}` |
-| 55b | `verify-timeline-in-flexipage` | verify | Metadata `FlexiPage` read-back — assert `industries_common:timeline` present in `main` with a `timelineConfigs` valueList naming all 4 OOTB config DeveloperNames AND its `{!Record.IsPersonAccount}` EQUAL true `<visibilityRule>` (+ Patient Card not dropped); the modeled gate for step 55 | GET `/services/data/vXX/headless/metadata?type=FlexiPage&fullName={devName}` |
-| 55c | `check-console-flexipage` | read | Tooling existence probe for the fixed `Account_Record_Page` DeveloperName (`SELECT Id, DeveloperName, MasterLabel FROM FlexiPage WHERE DeveloperName='Account_Record_Page'`) so the create below is **idempotent / retry-safe**; `totalSize > 0` SKIPs the create (page already exists → fall through to verify/activate), `totalSize = 0` runs it | GET `/services/data/vXX/tooling/query/?q=<soql>` |
-| 56 | `create-console-flexipage` | write | Metadata `FlexiPage` (create `Account_Record_Page`, the Console's record page) — a CHILD of `healthcloud__HealthCloudAccount_rec_L_3Col` (template `flexipage:recordHomeThreeColTemplateDesktop`). Full-record POST of the exact live shape; **runs LAST in Act 4** (`depends_on` the org-pref + timeline + arcGraph prerequisites), **gated by `skip_condition: check-console-flexipage.totalSize > 0`** so a resumed run skips the POST instead of hitting `DUPLICATE_DEVELOPER_NAME` | POST `/services/data/vXX/headless/metadata {type:FlexiPage, fullName:Account_Record_Page, xmlRep:<whole page>}` |
-| 57 | `verify-console-flexipage` | verify | Metadata `FlexiPage` read-back — assert the page materialized with all regions (`leftsidebar` Patient Card FlexCard, `main` Action Launcher + tabset over the detail/carePlan/careGap/arcGraph facets, `rightsidebar` timeline + Chatter), correct `<parentFlexiPage>`/`<template>`; the modeled gate for step 56 | GET `/services/data/vXX/headless/metadata?type=FlexiPage&fullName=Account_Record_Page` |
-| 58 | `activate-console-flexipage-as-app-default` | write | Metadata `CustomApplication` `standard__HealthCloudConsole` — add a `View/Large/Flexipage` **actionOverride** (`content=Account_Record_Page`, `pageOrSobjectType=Account`) so the page is the app's **App Default** Account page (**FULL-RECORD REPLACE — read-modify-write the whole app**, NOT a merge) | PUT `/services/data/vXX/headless/metadata {type:CustomApplication, fullName:standard__HealthCloudConsole, xmlRep:<whole app + View actionOverride>}` |
-| 58b | `verify-console-flexipage-active` | verify | Metadata `CustomApplication` read-back — assert a `View` actionOverride with `content=Account_Record_Page`, `type=Flexipage`, `pageOrSobjectType=Account`; the modeled gate for step 58 | GET `/services/data/vXX/headless/metadata?type=CustomApplication&fullName=standard__HealthCloudConsole` |
-
-**Act 4 — notes (ordering, findings & the Timeline gate):**
-
-- **`discover-account-flexipage`** — the Account RecordPage `DeveloperName` is org-specific; query rather than hardcode. **On a genuinely fresh HC org there is typically ZERO custom Account RecordPage FlexiPage** (the org renders the Salesforce standard page, which only materializes into an editable FlexiPage once one is deployed/edited) — so 0 rows is EXPECTED and is NOT a dead end: proceed to `create-account-flexipage`. If ≥ 1 exists, confirm the intended page with the admin, SKIP the create, and feed its DeveloperName into `read-patient-flexipage`.
-- **`create-account-flexipage`** *(skip if `discover-account-flexipage` found a page)* — `POST /services/data/vXX/headless/metadata {type:"FlexiPage", fullName:"<DevName>", xmlRep:<...>}` → `200 {success:true, id:0M0S...}`; Tooling read-back 0 → 1. Minimal valid standalone Account `RecordPage`: root `<FlexiPage xmlns="http://soap.sforce.com/2006/04/metadata">`, `<type>RecordPage</type>`, `<sobjectType>Account</sobjectType>`, `<template><name>flexipage:recordHomeTemplateDesktop</name></template>`, standalone (**no** `<parentFlexiPage>`), and `<flexiPageRegions>` (e.g. `header` → `force:highlightsPanel`, `main` → `force:relatedListContainer`). **COMPONENT NESTING — metadata v68.0 shape:** inside a region a component is wrapped `<itemInstances><componentInstance><componentName>…</componentName></componentInstance></itemInstances>` — NOT a bare `<componentInstances>` element. A `<componentInstances>` (or components placed directly under the region) is rejected at v68.0 with `componentInstances not valid in version 68.0`; author `<itemInstances>` → `<componentInstance>` and the create succeeds. (The org is on metadata v68.0 — use `<itemInstances><componentInstance>` everywhere a component sits in a region, including the two Act-4 binds below.) **PITFALL that produces `UNKNOWN_EXCEPTION`:** on a standalone page each region carries ONLY `<name>` + `<type>Region</type>` — do NOT add `<mode>Replace</mode>` (a stray `<mode>` is valid only on a CHILD page that sets `<parentFlexiPage>`, and on a standalone page throws `UNKNOWN_EXCEPTION`). `sidebar` IS a valid region type on `recordHomeTemplateDesktop` — a `sidebar` failure is the stray-`<mode>` bug, not an invalid region.
-- **`activate-account-flexipage`** — makes the new page the org-default Account record page. There is NO `FlexiPageAssignment` metadata type; the assignment is a `View` **actionOverride** on the object: `PUT /services/data/vXX/headless/metadata {type:"CustomObject", fullName:"Account", xmlRep:<CustomObject with ONE <actionOverrides>: actionName=View, type=Flexipage, formFactor=Large, content=<DevName>>}` → `200 {success:true}` (id null for a CustomObject update — normal). **Component-level MERGE, non-destructive** — read-back shows the new `View/Large/Flexipage` override present AND every pre-existing `Default` override intact.
-- **`read-patient-flexipage`** — Metadata read (`{type, fullName, xmlRep}`) that snapshots the WHOLE page. **FlexiPage region-adds are READ-MODIFY-WRITE, not merge and not full-replace** (region item lists are ordered) — the two binds below read this snapshot, add ONE `<itemInstances>` wrapping a `<componentInstance>` (distinct `<identifier>`) — the v68.0 shape; NOT a bare `<componentInstances>` — and PUT the whole page back preserving every existing region/component.
-- **`discover-patient-card-flexcard`** — INFORMATIONAL query via the **Data API** (`SELECT Id, Name FROM OmniUiCard WHERE Name LIKE '%Patient%Card%'`). The Patient Card placed in step 49 is the standard **`healthcloud:patientCard`** Lightning component, **NOT** an `OmniUiCard`-backed custom FlexCard — so this query is NOT a gate: **0 rows is expected and does NOT block step 49.** (`INVALID_TYPE` **on the Data API** = Standard OmniStudio runtime is off — re-check `enable-omnistudio-runtime-pref`, Act 1; the SAME error on the **Tooling** API just means the wrong endpoint.)
-- **`add-patient-card-to-flexipage`** — bind the standard **`healthcloud:patientCard`** component onto the Account record page **via a single `dispatch` `PUT /services/data/vXX/headless/metadata` with the flat body `{type:"FlexiPage", fullName:"<DeveloperName>", xmlRep:"<whole re-authored page>"}`**; NO multipart, NO zip, NO `sf` CLI. Author the whole FlexiPage `.flexipage` XML adding an `<itemInstances><componentInstance>` (the metadata v68.0 shape — NOT a bare `<componentInstances>`, which v68.0 rejects) whose `<componentName>` is `healthcloud:patientCard` with a distinct `<identifier>` and **NO `<componentInstanceProperties>` block** (bind by component name only — this is how Lightning App Builder persists it). ⚠ **SCOPE TO PERSON ACCOUNTS:** the activated page is the org-DEFAULT Account record page (one page for all 4 Account record types), so without a scope rule the card leaks onto Business accounts. Add a `<visibilityRule>` to the component instance — `<visibilityRule><criteria><leftValue>{!Record.IsPersonAccount}</leftValue><operator>EQUAL</operator><rightValue>true</rightValue></criteria></visibilityRule>` — so the card renders ONLY on person-type record types (Patient/Provider/PersonAccount), never Business. `Account.IsPersonAccount` is a standard boolean true for any person account, so ONE rule covers all person RTs (no per-RT page needed). Child-element order inside the `<componentInstance>`: `<componentInstanceProperties>`* (none here) → `<componentName>` → `<identifier>` → `<visibilityRule>`. Then: (1) GET the CURRENT page (`read-patient-flexipage`) so you have every existing region/component; (2) insert the new `<itemInstances>` (component instance carrying the `<visibilityRule>` above) into the existing `main` `<flexiPageRegions>`; (3) **PUT the WHOLE page** (`{type:FlexiPage, fullName, xmlRep:<whole page>}`) and assert `success:true` — FlexiPage regions are ordered full-record lists, so the PUT is a FULL REPLACE (not a component merge); a partial-page PUT drops every omitted component; (4) **then GATE ON READ-BACK — never the write echo — asserting the `<visibilityRule>` persisted.** The PUT is atomic, so its real gotcha is component access — on a Health-Cloud-enabled org (Act 1) `healthcloud:patientCard` is accessible; a bind before the backing feature is enabled fails the whole PUT `hasComponentAccess`. Bind the standard `healthcloud:patientCard` component — NOT `runtime_omnistudio:flexcard`/`flexcardName=HealthCloudPtCardPatientCard`, which does not resolve to the Patient Card and fails the write.
-- **Timeline (Act 4 tail) — driven by the Timeline setup Aura routes.** Timeline has NO public Connect/Tooling/Metadata CRUD for the org toggle + configuration; those dispatcher-backed Aura routes are the programmatic path. The model is **enable org toggle → verify → CHECK for seeded configurations → (only if none) create + activate a configuration → THEN bind the `industries_common:timeline` component onto the FlexiPage.** **PREFER SEEDED:** HC enablement auto-provisions FOUR active Account-anchored `TimelineObjectDefinition`s (`HC_Patients_Life_Story`, `HC_Clinical_Data`, `HC_Assessments`, `HC_Engagement_Data`) — so on a normally-enabled org the seeded set is the OOTB configuration to render and the custom create/activate (steps 52/53) are REDUNDANT. Author a custom config ONLY when `check-timeline-configurations` finds none (a stripped org). ⚠ **SEED ORDERING:** the four are seeded in ONE batch at the moment `handle-timeline-toggle` flips the org pref on, conditional on which features are enabled AT TOGGLE TIME — `HC_Assessments` only seeds if the Discovery Framework / assessments feature (`enable-discovery-framework`) is already ON. Toggling the timeline before assessments seeds only 3 (`HC_Clinical_Data`, `HC_Engagement_Data`, `HC_Patients_Life_Story`), and enabling assessments afterward does NOT retroactively seed `HC_Assessments` (the toggle is one-way/irreversible, so it can't re-seed). So `handle-timeline-toggle` depends_on `enable-discovery-framework` — assessments MUST precede the toggle for all 4 to seed. ⚠ **NOTE:** the `industries_common:timeline` component does NOT auto-resolve active definitions at runtime — it renders ONLY the configs explicitly wired into its `timelineConfigs` component property. So the bind (step 55) MUST name all 4 seeded config DeveloperNames (or the custom config's DeveloperName on a stripped org); a property-free bind renders none/wrong configurations. **CRITICAL ORDERING:** the component bind (`add-timeline-to-flexipage`) MUST run AFTER `handle-timeline-toggle`, because the timeline component bind is ALSO gated by `hasComponentAccess` — with the org Timeline feature OFF the bind is refused with `FIELD_INTEGRITY_EXCEPTION`; after the toggle flips it on, the RMW PUT → 200 and reads back. The `industries_common:timeline` component is placed on the page via a **whole-page `dispatch` PUT `/headless/metadata`** (see step 55). Timeline SOR preconditions: `Timeline/AccessTimeline` + `Timeline/ConfigureCdpEventsOnTimeline`.
-  - **`handle-timeline-toggle` — ONE-WAY / IRREVERSIBLE, no rollback.** Call the BARE path `PATCH /headless/invoke/platform/timeline/handle-timeline-toggle {value:true}` — the MCP rewrites it into the direct-invoke `POST` envelope; do NOT use the FQ `/services/data/.../headless/invoke/...` path (405/400). `value=false` throws `CannotTurnPrefOffError`. Must be ON before any configuration is created/activated AND before `add-timeline-to-flexipage`. Require explicit user confirmation before dispatching (second irreversible gate). Verify via `get-timeline-org-pref` read-back (bare boolean `true`), not the write echo.
-  - **`check-timeline-configurations`** *(pre-check — gates 52/53)* — Tooling `SELECT Id, DeveloperName, MasterLabel, IsActive FROM TimelineObjectDefinition WHERE BaseObject='Account' AND IsActive=true`. HC enablement seeds FOUR (`HC_Patients_Life_Story`, `HC_Clinical_Data`, `HC_Assessments`, `HC_Engagement_Data`) — `totalSize=4` on a normally-enabled org before any custom config. If `totalSize>0`, **SKIP `save-timeline-configuration` + `activate-timeline-configuration`** (the seeded set already renders the timeline). Only `totalSize=0` (a stripped org) proceeds to the custom create.
-  - **`save-timeline-configuration`** *(SKIP if `check-timeline-configurations` found ≥1)* — `saveTimelineConfiguration({config:{...}})`; base/anchor object = Account (Person Account). ⚠️ **`config` MUST be sent as a JSON OBJECT — do NOT stringify it** (a stringified `config` is rejected `400 REQUEST_ERROR`). Required config keys (exact casing): `DeveloperName`, `MasterLabel`, `BaseObject`. **`Definition` must be a NON-EMPTY, DEEPLY-NESTED object** — `{}` is rejected (`CONTROLLER_ERROR "Specify a definition..."`), and the minimal-looking schema with `anchorObject`/`age` as **bare strings is ALSO rejected** (`500 CONTROLLER_ERROR`). The real schema requires nested objects:
-    ```json
-    {"timeline": {
-      "anchorObject": {"object": {"entity": "Account", "label": "Account", "source": "", "icon": ""}},
-      "age": {"field": "CreatedDate", "label": "Created Date", "type": "DateTime"},
-      "events": []
-    }}
-    ```
-    `anchorObject.object.{entity,label,source,icon}` (a nested object, not the bare entity name) and `age.{field,label,type}` (the `age` field must point at a DATE/DATETIME field — `Account.CreatedDate` passes); `events` may be `[]`. Recover the exact shape from an existing live `TimelineObjectDefinition` if in doubt. **OMIT `RecordId` to CREATE** (supplying it performs an UPDATE); duplicate DeveloperName → `DuplicateApiNameError`. Returns `{RecordId}`, which the next step consumes.
-  - **`activate-timeline-configuration`** *(SKIP with `save-timeline-configuration`)* — `setTimelineConfigurationActiveStatus({RecordId, isActivated:true})` (note the key is `isActivated`, NOT `isActive`). **Reversible** (`isActivated:false`), unlike the org toggle. Only runs on the custom-create path (seeded definitions are already active — nothing to activate).
-  - **`verify-timeline-configuration-active`** — the `get-timeline-object-definitions` route is NOT wired in routes-full.json; verify via Tooling `SELECT Id,DeveloperName,MasterLabel,IsActive,BaseObject FROM TimelineObjectDefinition WHERE BaseObject='Account' AND IsActive=true` and assert **`totalSize>=1`** (the seeded set OR a custom config satisfies the end-state — do NOT gate on a specific `DeveloperName`).
-  - **`add-timeline-to-flexipage`** — binds `industries_common:timeline` into the `main` region **via a single `dispatch` `PUT /services/data/vXX/headless/metadata` with the flat body `{type:"FlexiPage", fullName:"<DeveloperName>", xmlRep:"<whole re-authored page>"}`**; NO multipart, NO zip, NO `sf` CLI. ⚠⚠ **BIND WITH A `timelineConfigs` COMPONENT PROPERTY NAMING THE 4 OOTB CONFIGS** — the component instance carries `<componentName>industries_common:timeline</componentName>`, a unique `<identifier>`, AND a `<componentInstanceProperties>` block whose `<name>` is `timelineConfigs`. `timelineConfigs` is `String[]` (design type `TimelineConfig[]`, max 5); each element is a `TimelineObjectDefinition` DeveloperName — wire all 4 seeded Account-anchored configs: `HC_Clinical_Data`, `HC_Engagement_Data`, `HC_Patients_Life_Story`, `HC_Assessments` (App Builder shows the MasterLabel — Clinical Data, Engagement Data, Patients Life Story, Assessments — but persists the DeveloperName). A property-free bind does NOT auto-resolve active configs; the timeline then renders none/wrong configurations. ⚠ **SCOPE TO PERSON ACCOUNTS:** like the Patient Card, the timeline sits on the org-DEFAULT Account page shared by all 4 record types, so it MUST also carry a `<visibilityRule>` — `<visibilityRule><criteria><leftValue>{!Record.IsPersonAccount}</leftValue><operator>EQUAL</operator><rightValue>true</rightValue></criteria></visibilityRule>` — or it leaks onto Business accounts. Child-element order inside the `<componentInstance>`: `<componentInstanceProperties>` (the `timelineConfigs` block) → `<componentName>` → `<identifier>` → `<visibilityRule>`. STEPS: re-read the page AFTER the Patient Card bind (`verify-patient-card-in-flexipage`) so the card is preserved, insert the timeline `<itemInstances>` (with the `timelineConfigs` property AND the `<visibilityRule>` above) into the existing `main` `<flexiPageRegions>`, and **PUT the WHOLE page** (`{type:FlexiPage, fullName, xmlRep:<whole page>}`) — FlexiPage regions are ordered full-record lists, so the PUT is a FULL REPLACE, not a component merge; a partial-page PUT drops every omitted component. ⚠ Serialize the array as a `<valueList>` (order `<componentInstanceProperties>` BEFORE `<componentName>`/`<identifier>`, then `<visibilityRule>` last): `<componentInstanceProperties><name>timelineConfigs</name><valueList><valueListItems><value>HC_Clinical_Data</value></valueListItems>…</valueList></componentInstanceProperties>`, one `<valueListItems>` per config. Do NOT send an EMPTY `timelineConfigs` property (name, no value — rolls back the whole page) or a SCALAR `<value>` (rejected: `FIELD_CUSTOM_VALIDATION_EXCEPTION: "Value is not allowed for Array attribute type in API version 49 and above."`). Depends on BOTH `verify-patient-card-in-flexipage` (gate on the read-back-confirmed card — the PUT re-authors the whole page, so it must carry the already-placed card) AND `handle-timeline-toggle` (the feature toggle MUST precede the bind or the atomic PUT fails `hasComponentAccess` — `FIELD_INTEGRITY_EXCEPTION: "Your org doesn't have access to component industries_common:timeline."`). GATE ON READ-BACK (asserting the `timelineConfigs` valueList AND the `{!Record.IsPersonAccount}` EQUAL true `<visibilityRule>` persisted), never the write echo. This is the component placement that renders the timeline on the Account record page — scoped to person accounts only.
-
-- **Health Cloud Console app — CREATE its record page, then ACTIVATE it as the App Default (steps 56–58b).** The org-default Account page (steps 42–55) is NOT what the **Health Cloud Console** app renders — a Lightning app renders its OWN assigned Account record page. There is exactly ONE path here (no fallback, no alternate/"Case A vs Case B"): **create** the Console's record page from the exact live shape, then **activate** it as the app's App Default via a `CustomApplication` `View` actionOverride. This section runs **LAST in Act 4** because the page embeds components whose backing org prefs must ALL be on first, or saving the page throws (see `create-console-flexipage` `depends_on`). Configure it as follows:
-  - **`check-console-flexipage`** — Tooling existence probe that makes the create below **idempotent / retry-safe** for the FIXED `Account_Record_Page` DeveloperName: `SELECT Id, DeveloperName, MasterLabel FROM FlexiPage WHERE DeveloperName = 'Account_Record_Page'` (FlexiPage is a Tooling-queryable sObject; reuses the same Tooling query route as the care/timeline verify steps). Because the create POSTs a fixed name, a resumed run — create already succeeded on a prior pass but a later verify/activate failed — would otherwise re-POST and hit `DUPLICATE_DEVELOPER_NAME`, dead-ending the workflow. `totalSize > 0` → the page already exists → `create-console-flexipage` is SKIPPED (`skip_condition`) and the flow falls through to `verify-console-flexipage` (which validates the existing page) + activation; `totalSize = 0` → the page is absent, so create runs. Runs right before `create-console-flexipage` (shares its Act 1–4 tail `depends_on`).
-  - **`create-console-flexipage`** — `POST /services/data/vXX/headless/metadata {type:"FlexiPage", fullName:"Account_Record_Page", xmlRep:<whole page>}`. **Gated by `skip_condition: check-console-flexipage.totalSize > 0`** (idempotent / retry-safe for the fixed DeveloperName — see `check-console-flexipage`). This page is a **CHILD** of the HC-provided person-account parent **`healthcloud__HealthCloudAccount_rec_L_3Col`**, template **`flexipage:recordHomeThreeColTemplateDesktop`**, sobjectType Account. Its regions: **`leftsidebar`** → Patient Card FlexCard (`runtime_omnistudio:flexcard`, `flexcardName=HealthCloudPtCardPatientCard`); **`main`** → `industries_service_excellence:actionLauncher` + a `flexipage:tabset` over `main_tabs`; the **`main_tabs`** facet → four `flexipage:tab`s (detail / carePlan / careGap / arcGraph); the facets **`detailTabContent`** (`force:detailPanel`), **`carePlanContent`** (`IndustriesHCCarePlanManager` FlexCard), **`careGapContent`** (`HealthCloudCareManagementCareGapManager` FlexCard), **`arcGraphContent`** (`runtime_industries_arcgraph:arcGraph`, `graphName=file:HealthcarePatientArcGraphTemplates.HC_PATIENT_STRUCTURE_GRAPH`); **`rightsidebar`** → `industries_common:timeline` (with the `timelineConfigs` valueList `HC_Clinical_Data`/`HC_Engagement_Data`/`HC_Patients_Life_Story`/`HC_Assessments`) + `forceChatter:recordFeedContainer`. **The exact verbatim `xmlRep` to send is encoded in the SOR overlay step `create-console-flexipage`** — send the WHOLE page (a create is a full-record write). ⚠ **NO per-component `<visibilityRule>` on this page** — unlike the org-default page (steps 49 & 55), the person-account PARENT `healthcloud__HealthCloudAccount_rec_L_3Col` supplies the record-type scoping, so the live page carries none and the encoded shape carries none. `depends_on` the tail of Acts 1–4 so every embedded component's backing pref is already on (or the create is rejected transactionally): `verify-timeline-in-flexipage`, `verify-group-membership` (arcGraph Household), `verify-care-plans`, `verify-integrated-care-management`, `verify-care-gap`, `handle-timeline-toggle` (timeline `hasComponentAccess`), `enable-omnistudio-runtime-pref` (the FlexCards). Gate on `verify-console-flexipage`, never the POST echo.
-  - **`verify-console-flexipage`** — `GET /headless/metadata {type:FlexiPage, fullName:Account_Record_Page}`; assert the page materialized with masterLabel "Account Record Page", parent `healthcloud__HealthCloudAccount_rec_L_3Col`, template `flexipage:recordHomeThreeColTemplateDesktop`, and every region/facet/component above. Modeled gate for `create-console-flexipage`.
-  - **`activate-console-flexipage-as-app-default`** — makes the created page the Console app's App Default Account page. `PUT /services/data/vXX/headless/metadata {type:"CustomApplication", fullName:"standard__HealthCloudConsole", xmlRep:<the WHOLE app with the added <actionOverrides>>}` where the override is `{actionName:View, type:Flexipage, content:Account_Record_Page, formFactor:Large, pageOrSobjectType:Account, skipRecordTypeSelect:false}`. ⚠ **FULL-RECORD REPLACE, NOT a merge.** A minimal one-override PUT is rejected `400 FIELD_INTEGRITY_EXCEPTION: "Action overrides of type Flexipage on the View action are supported only for Lightning apps."` — omitting `<uiType>Lightning</uiType>` makes the deserialized app look non-Lightning. So read-modify-write: GET the current app (`type=CustomApplication, fullName=standard__HealthCloudConsole`), add your `<actionOverrides>` block to the WHOLE returned xmlRep, and PUT it back — preserving `<uiType>`, `<navType>`, every `<tabs>`, `<formFactors>`, and `<workspaceConfig>`. Gate on `verify-console-flexipage-active`, never the write echo.
-  - **`verify-console-flexipage-active`** — `GET /headless/metadata {type:CustomApplication, fullName:standard__HealthCloudConsole}`; assert a `View` actionOverride exists with `type=Flexipage`, `pageOrSobjectType=Account`, `content=Account_Record_Page`. Modeled gate for `activate-console-flexipage-as-app-default`.
-
-- **Console Person Account "Household" tab (arcGraph) readiness — `enable-group-membership` / `verify-group-membership`.** The **Household** tab on a Person Account record page in the HC Console is the arcGraph component `runtime_industries_arcgraph:arcGraph` with graph template **`HC_PATIENT_STRUCTURE_GRAPH`**. Its core access gate ANDs **FIVE** conditions; a failure of any ONE renders the tab as **"The requested resource does not exist"**:
-  1. HC license (`ORG_HAS_HEALTH_CLOUD`) — from the HC add-on.
-  2. A platform group-membership permission — ships with the **HealthCloudAddOn** permission-set license (no separate toggle).
-  3. `IndustriesSettings.enableGroupMembershipPref` — **`enable-group-membership`** (below).
-  4. B2C / Person Accounts — Act 3's `enable-person-accounts`.
-  5. `AccountContactRelation` readable — CMA runtime provisioning, Act 2 step 28 + `verify-account-contact-relation` (the usual failing gate).
-  - Gates 4 and 5 are covered by Act 3 and the Act 2 CMA correction; gate 3 (`enableGroupMembershipPref`) is the one enablement this workflow was missing. **`enable-group-membership`** sets `IndustriesSettings.enableGroupMembershipPref=true` (Settings-singleton, metadata `fullName` = `Industries`). The `type=IndustriesSettings` headless PUT to `/headless/metadata` is the primary write channel: a true→false→true round-trip of `enableGroupMembershipPref` each returned `200 success:true`, with `GET` confirming both the flip and the restore — so the earlier allowlist caveat does NOT apply to `IndustriesSettings`. An **MDAPI file-based deploy** of the Industries settings is only a stripped-org fallback. **`verify-group-membership`** reads `IndustriesSettings` back and asserts `enableGroupMembershipPref == true`. The DEFINITIVE end-to-end Household-tab readiness is the AND of all five gates — if the tab still errors with this pref on, gate #5 (CMA runtime provisioning) is the usual culprit. Both the headless GET read (`GET /headless/metadata?type=IndustriesSettings&fullName=Industries` → 200 with `enableGroupMembershipPref=true`, gate #3 confirmed ON) AND the headless PUT write work. If gate #5 still fails (`SELECT Id FROM AccountContactRelation` → INVALID_TYPE), the tab remains broken for the CMA reason.
-
-**Act 4 end state:** Account RecordPage created (if absent) and activated as the org-default; the standard `healthcloud:patientCard` component bound onto the page via a whole-page `dispatch` PUT `/headless/metadata`; Timeline org feature enabled (permanent), **at least one active Account-anchored `TimelineObjectDefinition` present** — satisfied by the four HC-seeded definitions on a normally-enabled org (no custom config authored), or by a custom config created + activated only on a stripped org — and the `industries_common:timeline` component bound onto the page **via a whole-page `dispatch` PUT `/headless/metadata`** (after the toggle) WITH its `timelineConfigs` property naming the 4 OOTB configs so the timeline renders them. **BOTH components carry a `<visibilityRule>` of {!Record.IsPersonAccount} EQUAL true**, so the Patient Card and Timeline render ONLY on person-type record types (Patient/Provider/PersonAccount) and NOT on Business accounts — the activated page is the single org-default Account page shared by all 4 record types, so the rule is what scopes them. The card bind carries no property block (just the visibilityRule); the timeline bind carries the `timelineConfigs` valueList plus the visibilityRule — both are written by successive whole-page PUTs. **AND** — because the **Health Cloud Console** app renders its OWN assigned Account page rather than the org default — the Console's full person-account page is created and activated LAST: `create-console-flexipage` POSTs the Console's record page `Account_Record_Page` (a CHILD of `healthcloud__HealthCloudAccount_rec_L_3Col`, template `flexipage:recordHomeThreeColTemplateDesktop`) from its exact live shape — `leftsidebar` Patient Card FlexCard, `main` Action Launcher + a tabset over the detail/carePlan/careGap/arcGraph facets (Care Plan Manager + Care Gap Manager FlexCards + the `HC_PATIENT_STRUCTURE_GRAPH` arcGraph), and `rightsidebar` timeline (`timelineConfigs` = the 4 OOTB configs) + Chatter — `verify-console-flexipage` reads it back, `activate-console-flexipage-as-app-default` adds the `View/Large/Flexipage` `content=Account_Record_Page` actionOverride to `standard__HealthCloudConsole` (App Default, via a whole-app read-modify-write PUT — CustomApplication is a full-record replace, not a merge), and `verify-console-flexipage-active` confirms the override. This runs last because the page's components require the Act-1 care prefs (Care Plans → ICM → Care Gap), the arcGraph Household gate (`verify-group-membership`), the timeline toggle, and the OmniStudio runtime pref to ALL be on first, or the save throws. **This page carries NO per-component `<visibilityRule>`** — its person-account parent `healthcloud__HealthCloudAccount_rec_L_3Col` supplies the record-type scoping (unlike the org-default page, which is shared across all Account RTs and so needs the explicit rule). **Console Household tab renders: `IndustriesSettings.enableGroupMembershipPref` ON (`verify-group-membership`), completing the five arcGraph `HC_PATIENT_STRUCTURE_GRAPH` gates (HC license, the group-membership platform permission, group-membership pref, Person Accounts/B2C, `AccountContactRelation` runtime-queryable)** — if any of the five is unmet the tab shows "The requested resource does not exist," most often the CMA/`AccountContactRelation` gate (Act 2). Underlying node: `Timeline` (`health-cloud-r2-d2`).
-
----
-
-## Definition of done (the whole skill)
-
-An unqualified Health Cloud setup is **complete only when all four Acts have reached their end states**: Act 1 (Console + FHIR + Discovery Framework on; Standard OmniStudio runtime ON and OmniStudioAdmin + OmniStudioUser self-assigned; all four advanced capabilities ON — these are EXPECTED to be entitled, so a genuinely absent advanced-capability entitlement is a BLOCKING error, not a skippable end state) → Act 2 (Data Protection on for HIPAA, Translation Workbench on, Contacts-to-Multiple-Accounts on) → Act 3 (Person Accounts enabled, record types + profile visibilities + layouts set) → Act 4 (Patient Card bound onto the Account page, Timeline enabled + at least one active Account-anchored configuration present — the HC-seeded set satisfies this; author a custom one only on a stripped org — + the timeline component bound; and the Console Household tab's five arcGraph gates met — `enableGroupMembershipPref` ON plus the CMA/Person-Accounts/license/perm gates from Acts 1–3). If any step is blocked by a genuine documented gate (a Setup surface with no dispatchable API), **report the gate and complete every step that is not blocked** — then close with an explicit list of what remains; but an advanced-capability entitlement 403 is NOT such a gate — it is a blocking mis-provisioning error to surface for remediation. Note: OmniStudio is **not** a gate — Standard OmniStudio ships with the org (no managed package), so `enable-omnistudio-runtime-pref` turns the runtime on rather than escalating. `enable-data-protection` skipped = INCOMPLETE (HIPAA). Reporting "done" after only the foundation toggles is a defect.
-
-## Resumability
-
-Every step is skippable and revisitable. Before acting on any step, re-read the corresponding `check-`/`get-`/`read-` step to detect existing org state and avoid duplicating work — the agent should determine where to begin from org metadata, not assume a fresh org. Skip a write when its read shows the target state is already correct.
-
-## Metadata write discipline (recap)
-
-`assign-person-account-record-type-to-profiles`, `create-*-record-type`, `read/add-patient-flexipage`, `create/activate-account-flexipage`, and the AccountSettings/LanguageSettings/CommunitiesSettings writes touch Metadata via the headless Metadata REST resource (`/services/data/vXX/headless/metadata`) — no CLI needed for these. Merge semantics: **Settings singletons, Profiles, and CustomObject `actionOverrides` MERGE at the component level** — send the MINIMAL fragment (a single-field Settings PUT, a minimal `<recordTypeVisibilities>` Profile PUT, a one-override CustomObject PUT); never round-trip the whole record. Creating/activating a `force:*`-only FlexiPage works through this headless resource. **The two OmniStudio/industries binds on the org-default page (`add-patient-card-to-flexipage`, `add-timeline-to-flexipage`) ALSO go through it — one `dispatch` `PUT /services/data/vXX/headless/metadata {type:FlexiPage, fullName, xmlRep:<whole page>}` each; NO multipart, NO zip, NO `sf` CLI.** The Health Cloud Console app's OWN record page is instead **created whole** (not bound-into): `create-console-flexipage` POSTs the full `Account_Record_Page` (a CHILD of `healthcloud__HealthCloudAccount_rec_L_3Col` — its `<parentFlexiPage>` and `<template>` are part of the encoded shape) via the same headless resource, then `activate-console-flexipage-as-app-default` sets it as the app's App Default with a `View`-actionOverride `CustomApplication` PUT on `standard__HealthCloudConsole` — and ⚠ unlike CustomObject actionOverrides, **`CustomApplication` is a FULL-RECORD REPLACE, not a merge**: read-modify-write the whole app (a minimal one-override PUT 400s `FIELD_INTEGRITY_EXCEPTION "…supported only for Lightning apps"` because it drops `<uiType>Lightning</uiType>`), preserving `<uiType>`/`<navType>`/`<tabs>`/`<formFactors>`/`<workspaceConfig>`. Unlike Settings/Profile/CustomObject, **FlexiPage regions do NOT merge** — `<flexiPageRegions>` are ordered full-record lists, so the PUT is a FULL REPLACE: re-author the WHOLE `.flexipage` (carry every existing region/component; on a standalone region never add `<mode>`), and a partial-page PUT drops every omitted component. The PUT is ATOMIC, so its real gotchas are component access (enable the backing feature first — Health Cloud enablement for `healthcloud:patientCard`, `handle-timeline-toggle` for the timeline) and property shape: bind the Patient Card by `<componentName>` with NO `<componentInstanceProperties>` block, but bind the timeline WITH a `timelineConfigs` property naming the 4 OOTB configs, serialized as a `<valueList>` (an empty or scalar `timelineConfigs` fails the timeline PUT). **BOTH binds MUST carry a `<visibilityRule>` of `{!Record.IsPersonAccount}` EQUAL true** (child order: `<componentInstanceProperties>`* → `<componentName>` → `<identifier>` → `<visibilityRule>`) — the activated page is the org-default Account page shared by all 4 record types, so without the rule the Patient Card and Timeline leak onto Business accounts. Gate on read-back (asserting the `<visibilityRule>` persisted), never the write echo. **RecordType create** wraps a nested `<recordTypes>` block in a `<CustomObject>` root (a top-level `<RecordType>` is rejected). **Layout create/modify** is the one Metadata-shaped write that does NOT go through `/headless/metadata` (that path 400s "Invalid fullName" for `Layout`) — use the native **Tooling `Layout` sObject** REST instead (`POST`/`PATCH /services/data/vXX/tooling/sobjects/Layout`), targeting the `PersonAccount` entity (`FullName: PersonAccount-<Name> Layout`) for person layouts; a plain Tooling REST call. If `/headless/metadata` 404s on a stripped org, fall back to Tooling SOQL reads + the manual Setup UI. **`IndustriesSettings` (`enable-group-membership`)** writes through this same headless resource — a `type=IndustriesSettings` PUT of the minimal `<enableGroupMembershipPref>` fragment (a true→false→true round-trip each returns `200 success:true`, GET-confirmed) is the primary write channel here too; an **MDAPI file-based deploy** of the Industries settings is only a stripped-org fallback.
-
-## Underlying setup-page nodes (companion references — do not duplicate their step definitions)
-
-This workflow sequences operations already defined on these setup-page nodes; call them by route rather than re-deriving:
-
-- `SiteManagementSettingsHc` — legacy license-check surface (`validate-hc-license` now retargeted onto the Health Cloud license check).
-- `ClinicalDataModelSettings` — FHIR Data Model toggle.
-- `FhirSubscriptionSetup` — FHIR Subscription Access (distinct pref).
-- `PublicHealthSettings` — Disease Surveillance preference.
-- `OmniStudioSettings` — OmniStudio org prefs.
-- `ConsentManagement` — Data Protection & Privacy.
-- `AccountSettings` — Contacts-to-Multiple-Accounts.
-- `PersonAccountSettings` — Person Accounts readiness / terms / enablement.
-- `EnhancedProfiles` — Profile record-type visibilities.
-- `Timeline` (`health-cloud-r2-d2`) — the Act-4 Timeline enable → configure → activate sequence.
-- `IndustriesSettings` — `enableGroupMembershipPref` (Act-4 Console Household-tab arcGraph gate #3).
-
-Additional backing surfaces referenced inline: the package-to-core setup surface (console preference **and** Einstein for Health Cloud via `healthCloudGenAIPref`), Public Health settings (Disease Surveillance), Data Cloud provisioning (CDPSetupHome), and the Context Service Connect API. The org-wide Einstein GenAI platform gate is intentionally NOT driven (entitlement-gated 403; dropped per team decision).
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `verify-health-cloud-license` | verify | — | `GET /headless/invoke/platform/health-cloud-admin-feature-setup/has-health-cloud-licence` | — |
-| `read-health-cloud-setup-state` | read | — | `GET /headless/invoke/platform/health-cloud-admin-feature-setup/get-health-cloud-setup-state` | `verify-health-cloud-license` |
-| `enable-hc-console` | write | — | `PATCH /headless/invoke/platform/package-to-core-settings/set-preference` | `verify-health-cloud-license`, `detect-service-cloud-presence`, `verify-health-cloud-foundation-permset` |
-| `verify-hc-console` | verify | — | `GET /headless/invoke/platform/package-to-core-settings` | `enable-hc-console` |
-| `read-fhir-data-model-pref` | read | — | `GET /headless/invoke/platform/clinical-data-model-settings` | `verify-health-cloud-license` |
-| `enable-fhir-data-model` | write | — | `PATCH /headless/invoke/platform/clinical-data-model-settings/handle-clinical-data-model-pref-toggle` | `read-fhir-data-model-pref` |
-| `verify-fhir-data-model` | verify | — | `GET /headless/invoke/platform/clinical-data-model-settings` | `enable-fhir-data-model` |
-| `enable-fhir-subscription-access` | write | — | `PATCH /headless/invoke/industries/industries-healthcare/fhir-subscription-setup/handle-fhir-subscription-access-org-pref-toggle` | `enable-fhir-data-model` |
-| `enable-discovery-framework` | write | — | `PATCH /headless/invoke/platform/salesforce-go/enable-feature` | `verify-health-cloud-license` |
-| `check-omnistudio-package-installed` | verify | — | `GET /headless/invoke/platform/omni-studio-settings/get-omni-studio-prefs` | `verify-health-cloud-license` |
-| `check-omnistudio-permissions-assigned` | verify | — | `GET /services/data/v67.0/query/` | `check-omnistudio-package-installed` |
-| `verify-omnistudio-pref-read` | read | — | `GET /headless/invoke/platform/omni-studio-settings/get-omni-studio-prefs` | `check-omnistudio-package-installed` |
-| `enable-omnistudio-pref` | write | — | `PATCH /headless/invoke/platform/omni-studio-settings/save-pref` | `verify-omnistudio-pref-read` |
-| `verify-omnistudio-pref` | verify | — | `GET /headless/invoke/platform/omni-studio-settings/get-omni-studio-prefs` | `enable-omnistudio-pref` |
-| `enable-einstein-for-health-cloud` | write | — | `PATCH /headless/invoke/platform/package-to-core-settings/set-preference` | `verify-health-cloud-license` |
-| `enable-disease-surveillance` | write | — | `PATCH /headless/invoke/platform/public-health-settings/set-preference` | `verify-health-cloud-license` |
-| `verify-disease-surveillance` | verify | — | `GET /headless/invoke/platform/public-health-settings/get-preferences` | `enable-disease-surveillance` |
-| `check-cdp-provision-status` | read | — | `GET /headless/invoke/platform/cdpsetup-home` | `verify-health-cloud-license`, `verify-data-cloud-setup-permset` |
-| `enable-data-cloud` | write | — | `PATCH /headless/invoke/platform/cdpsetup-home/toggle-cdp-enabled-pref` | `check-cdp-provision-status` |
-| `read-context-service-access` | read | — | `GET /services/data/v64.0/connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` | `verify-health-cloud-license` |
-| `enable-context-service` | write | — | `PUT /services/data/v64.0/connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` | `read-context-service-access` |
-| `verify-context-service-enabled` | verify | — | `GET /services/data/v64.0/connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` | `enable-context-service` |
-| `enable-consent-management` | write | — | `PATCH /headless/invoke/platform/consent/consent-management/handle-prefs` | `verify-health-cloud-license` |
-| `read-language-settings` | read | — | `GET /headless/metadata` | `verify-health-cloud-license` |
-| `enable-translation-workbench` | write | — | `PUT /headless/metadata` | `enable-consent-management` |
-| `read-account-settings` | read | — | `GET /services/data/v66.0/tooling/query/` | `verify-health-cloud-license` |
-| `enable-contacts-to-multiple-accounts` | write | — | `PUT /headless/metadata` | `read-account-settings`, `verify-standard-relationship-objects` |
-| `verify-contacts-to-multiple-accounts` | verify | — | `GET /services/data/v67.0/query/` | `enable-contacts-to-multiple-accounts` |
-| `create-business-account-record-type` | write | — | `POST /headless/metadata` | `verify-contacts-to-multiple-accounts` |
-| `check-person-account-readiness` | verify | — | `GET /headless/invoke/platform/person-account-settings/check-person-account-readiness` | `create-business-account-record-type` |
-| `accept-person-account-terms` | write | — | `PATCH /headless/invoke/platform/person-account-settings/accept-terms-and-conditions` | `check-person-account-readiness` |
-| `verify-person-account-terms` | verify | — | `GET /headless/invoke/platform/person-account-settings/check-person-account-readiness` | `accept-person-account-terms` |
-| `enable-person-accounts` | write | — | `PATCH /headless/invoke/platform/person-account-settings/enable-person-accounts` | `verify-person-account-terms`, `verify-contacts-to-multiple-accounts` |
-| `verify-person-account-record-types` | verify | — | `GET /services/data/v67.0/tooling/query/` | `enable-person-accounts` |
-| `assign-person-account-rt-visibility` | write | — | `PUT /headless/metadata` | `verify-person-account-record-types`, `verify-person-account-object`, `verify-person-account-layout`, `verify-account-contact-relation`, `create-patient-record-type`, `create-provider-record-type` |
-| `create-patient-layout` | write | — | `POST /services/data/v64.0/tooling/sobjects/Layout` | `enable-person-accounts` |
-| `create-provider-layout` | write | — | `POST /services/data/v64.0/tooling/sobjects/Layout` | `enable-person-accounts` |
-| `create-patient-record-type` | write | — | `POST /headless/metadata` | `enable-person-accounts` |
-| `create-provider-record-type` | write | — | `POST /headless/metadata` | `enable-person-accounts` |
-| `discover-account-flexipage` | read | — | `GET /services/data/v67.0/tooling/query/` | `create-patient-record-type` |
-| `read-patient-flexipage` | read | — | `GET /headless/metadata` | `verify-account-flexipage-active` |
-| `discover-patient-card-flexcard` | read | — | `GET /services/data/v67.0/query/` | `check-omnistudio-package-installed` |
-| `add-patient-card-to-flexipage` | write | — | `PUT /headless/metadata` | `read-patient-flexipage`, `discover-patient-card-flexcard`, `enable-omnistudio-runtime-pref` |
-| `handle-timeline-toggle` | write | — | `PATCH /headless/invoke/platform/timeline/handle-timeline-toggle` | `add-patient-card-to-flexipage`, `enable-discovery-framework` |
-| `verify-timeline-enabled` | verify | — | `GET /headless/invoke/platform/timeline/get-timeline-org-pref` | `handle-timeline-toggle` |
-| `save-timeline-configuration` | write | — | `PATCH /headless/invoke/platform/timeline/save-timeline-configuration` | `check-timeline-configurations` |
-| `activate-timeline-configuration` | write | — | `PATCH /headless/invoke/platform/timeline/set-timeline-configuration-active-status` | `save-timeline-configuration` |
-| `verify-einstein-for-health-cloud` | verify | — | `GET /headless/metadata` | `enable-einstein-for-health-cloud` |
-| `read-communities-settings` | read | — | `GET /headless/metadata` | `verify-health-cloud-license` |
-| `enable-digital-experiences` | write | — | `PUT /headless/metadata` | `read-communities-settings` |
-| `verify-digital-experiences` | verify | — | `GET /services/data/v67.0/query/` | `enable-digital-experiences` |
-| `enable-care-plans` | write | — | `PUT /headless/metadata` | `verify-einstein-for-health-cloud` |
-| `verify-care-plans` | verify | — | `GET /services/data/v67.0/tooling/query/` | `enable-care-plans` |
-| `enable-integrated-care-management` | write | — | `PUT /headless/metadata` | `verify-care-plans` |
-| `verify-integrated-care-management` | verify | — | `GET /services/data/v67.0/tooling/query/` | `enable-integrated-care-management` |
-| `enable-care-gap` | write | — | `PUT /headless/metadata` | `verify-einstein-for-health-cloud` |
-| `verify-care-gap` | verify | — | `GET /services/data/v67.0/tooling/query/` | `enable-care-gap` |
-| `check-timeline-configurations` | read | — | `GET /services/data/v67.0/tooling/query/` | `verify-timeline-enabled` |
-| `verify-timeline-configuration-active` | verify | — | `GET /services/data/v67.0/tooling/query/` | `activate-timeline-configuration` |
-| `enable-standard-relationship-objects` | write | — | `PATCH /headless/invoke/platform/package-to-core-settings/set-preference` | `enable-translation-workbench` |
-| `verify-standard-relationship-objects` | verify | — | `GET /headless/invoke/platform/package-to-core-settings` | `enable-standard-relationship-objects` |
-| `enable-omnistudio-runtime-pref` | write | — | `PATCH /headless/invoke/platform/omni-studio-settings/save-pref` | `check-omnistudio-package-installed` |
-| `assign-omnistudio-admin-permset` | write | — | `POST /services/data/v67.0/sobjects/PermissionSetAssignment` | `check-omnistudio-permissions-assigned` |
-| `verify-omnistudio-admin-permset` | verify | — | `GET /services/data/v67.0/query/` | `assign-omnistudio-admin-permset` |
-| `check-omnistudio-user-permset` | verify | — | `GET /services/data/v67.0/query/` | `check-omnistudio-package-installed` |
-| `assign-omnistudio-user-permset` | write | — | `POST /services/data/v67.0/sobjects/PermissionSetAssignment` | `check-omnistudio-user-permset` |
-| `verify-omnistudio-user-permset` | verify | — | `GET /services/data/v67.0/query/` | `assign-omnistudio-user-permset` |
-| `check-health-cloud-foundation-permset` | verify | — | `GET /services/data/v67.0/query/` | `verify-health-cloud-license` |
-| `assign-health-cloud-foundation-permset` | write | — | `POST /services/data/v67.0/sobjects/PermissionSetAssignment` | `check-health-cloud-foundation-permset` |
-| `verify-health-cloud-foundation-permset` | verify | — | `GET /services/data/v67.0/query/` | `assign-health-cloud-foundation-permset` |
-| `check-data-cloud-setup-permset` | verify | — | `GET /services/data/v67.0/query/` | `verify-health-cloud-license` |
-| `assign-data-cloud-setup-permset` | write | — | `POST /services/data/v67.0/sobjects/PermissionSetAssignment` | `check-data-cloud-setup-permset` |
-| `verify-data-cloud-setup-permset` | verify | — | `GET /services/data/v67.0/query/` | `assign-data-cloud-setup-permset` |
-| `create-account-flexipage` | write | — | `POST /headless/metadata` | `discover-account-flexipage` |
-| `verify-account-flexipage` | verify | — | `GET /services/data/v67.0/tooling/query/` | `create-account-flexipage` |
-| `activate-account-flexipage` | write | — | `PUT /headless/metadata` | `verify-account-flexipage` |
-| `verify-account-flexipage-active` | verify | — | `GET /headless/metadata` | `activate-account-flexipage` |
-| `verify-patient-card-in-flexipage` | verify | — | `GET /headless/metadata` | `add-patient-card-to-flexipage` |
-| `add-timeline-to-flexipage` | write | — | `PUT /headless/metadata` | `verify-patient-card-in-flexipage`, `handle-timeline-toggle` |
-| `verify-timeline-in-flexipage` | verify | — | `GET /headless/metadata` | `add-timeline-to-flexipage` |
-| `check-console-flexipage` | read | — | `GET /services/data/v67.0/tooling/query/` | `verify-timeline-in-flexipage`, `verify-group-membership`, `verify-care-plans`, `verify-integrated-care-management`, `verify-care-gap`, `handle-timeline-toggle`, `enable-omnistudio-runtime-pref` |
-| `create-console-flexipage` | write | — | `POST /headless/metadata` | `check-console-flexipage`, `verify-timeline-in-flexipage`, `verify-group-membership`, `verify-care-plans`, `verify-integrated-care-management`, `verify-care-gap`, `handle-timeline-toggle`, `enable-omnistudio-runtime-pref` |
-| `verify-console-flexipage` | verify | — | `GET /headless/metadata` | `create-console-flexipage` |
-| `activate-console-flexipage-as-app-default` | write | — | `PUT /headless/metadata` | `verify-console-flexipage` |
-| `verify-console-flexipage-active` | verify | — | `GET /headless/metadata` | `activate-console-flexipage-as-app-default` |
-| `detect-service-cloud-presence` | read | — | `GET /services/data/v67.0/tooling/query/` | `verify-health-cloud-license` |
-| `verify-person-account-object` | verify | — | `GET /services/data/v67.0/tooling/query/` | `enable-person-accounts` |
-| `verify-person-account-layout` | verify | — | `GET /services/data/v67.0/tooling/query/` | `enable-person-accounts` |
-| `verify-account-contact-relation` | verify | — | `GET /services/data/v67.0/query/` | `enable-person-accounts` |
-| `assign-person-account-layouts-to-profiles` | write | — | `PUT /headless/metadata` | `create-patient-layout`, `create-provider-layout`, `create-patient-record-type`, `create-provider-record-type`, `assign-person-account-rt-visibility` |
-| `enable-group-membership` | write | — | `PUT /headless/metadata` | `enable-person-accounts` |
-| `verify-group-membership` | verify | — | `GET /headless/metadata` | `enable-group-membership` |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->