@salesforce/afv-skills 1.63.0 → 1.65.0

package/skills/industries-comms-service-console-settings-configure/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: industries-comms-service-console-settings-configure
+description: "Use this skill when users want to manage three Comms Cloud Setup org preferences via dispatcher-routed Setup Connect API: Comms Service Console (omnichannel agent console; ALSO gated by org-perm Identity Verification — when off, gated read/write returns Failure `IVPrefEnableError` and never touches the pref), Com. Trigger when users mention comms, service, console, settings, comms service console settings."
+metadata:
+  version: "1.0"
+---
+
+# Managing Comms Service Console Settings
+
+## When to Use This Skill
+
+Manage three Comms Cloud Setup org preferences via dispatcher-routed Setup Connect API: Comms Service Console (omnichannel agent console; ALSO gated by org-perm Identity Verification — when off, gated read/write returns Failure `IVPrefEnableError` and never touches the pref), Comms Intelligence (gated by `userHasAccessToCommsCloudSetup`), Outbound Notification Framework (gated by `userHasAccessToIndustriesCommsCloudFeature`). All ops require Customize Application or System Administrator. Each setter accepts an `enable` boolean; each call returns `ImmutableMap<String,Object>` — pref boolean on success, `{status: Failure, message: <localized label>}` on access/IV/save failure.
+
+## Workflow
+
+Three independent preferences; toggle in any order. Each: GET current, PATCH `enable` to write, companion GET to verify. Service Console additionally requires Identity Verification org-perm — without it, reads and writes return `IVPrefEnableError` Failure and never touch the pref.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- User must have CommsMsmServiceConsole AccessToCommsCloudSetup access (check: `Communications Cloud Setup access`)
+- User must have IndustriesComms AccessToIndustriesCommsCloudFeature access (check: `Communications Cloud feature access`)
+- Caller must have Customize Application OR System Administrator. The controller's `checkAccess()` (line 117) returns false otherwise; every read and write returns `{status: Failure, RestrictedAccessMessageBody}` and never invokes the underlying service method. (check: `USER_HAS_CUSTOMIZE_APPLICATION_OR_SYS_ADMIN`)
+- Org must have the Identity Verification org permission ON for the Comms Service Console pref read and write only (Comms Intelligence and Outbound Notification Framework are unaffected). When off, those two operations return `{status: Failure, IVPrefEnableError}` and never touch the underlying pref. (check: `ORG_PERMISSION_IDENTITY_VERIFICATION`)
+
+## Verification Checklist
+
+After every write operation, confirm the effect by re-reading state:
+
+- After `set-comms-service-console-pref`: call `verify-set-comms-service-console-pref` (`GET /headless/invoke/platform/comms-service-console-settings`)
+- After `set-comms-intelligence-pref`: call `verify-set-comms-intelligence-pref` (`GET /headless/invoke/platform/comms-service-console-settings/get-comms-intelligence-pref`)
+- After `set-outbound-notification-framework-pref`: call `verify-set-outbound-notification-framework-pref` (`GET /headless/invoke/platform/comms-service-console-settings/get-outbound-notification-framework-pref`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `get-comms-service-console-pref` | read | implemented | `GET /headless/invoke/platform/comms-service-console-settings` | — |
+| `get-comms-intelligence-pref` | read | implemented | `GET /headless/invoke/platform/comms-service-console-settings/get-comms-intelligence-pref` | — |
+| `set-comms-service-console-pref` | write | implemented | `PATCH /headless/invoke/platform/comms-service-console-settings/set-comms-service-console-pref` | — |
+| `verify-set-comms-service-console-pref` | verify | — | `GET /headless/invoke/platform/comms-service-console-settings` | `set-comms-service-console-pref` |
+| `set-comms-intelligence-pref` | write | implemented | `PATCH /headless/invoke/platform/comms-service-console-settings/set-comms-intelligence-pref` | — |
+| `verify-set-comms-intelligence-pref` | verify | — | `GET /headless/invoke/platform/comms-service-console-settings/get-comms-intelligence-pref` | `set-comms-intelligence-pref` |
+| `get-outbound-notification-framework-pref` | read | implemented | `GET /headless/invoke/platform/comms-service-console-settings/get-outbound-notification-framework-pref` | — |
+| `set-outbound-notification-framework-pref` | write | implemented | `PATCH /headless/invoke/platform/comms-service-console-settings/set-outbound-notification-framework-pref` | — |
+| `verify-set-outbound-notification-framework-pref` | verify | — | `GET /headless/invoke/platform/comms-service-console-settings/get-outbound-notification-framework-pref` | `set-outbound-notification-framework-pref` |
+
+### Dependency graph
+
+```mermaid
+graph TD
+  get_comms_service_console_pref["get-comms-service-console-pref (read)"]
+  get_comms_intelligence_pref["get-comms-intelligence-pref (read)"]
+  set_comms_service_console_pref["set-comms-service-console-pref (write)"]
+  verify_set_comms_service_console_pref["verify-set-comms-service-console-pref (verify)"]
+  set_comms_intelligence_pref["set-comms-intelligence-pref (write)"]
+  verify_set_comms_intelligence_pref["verify-set-comms-intelligence-pref (verify)"]
+  get_outbound_notification_framework_pref["get-outbound-notification-framework-pref (read)"]
+  set_outbound_notification_framework_pref["set-outbound-notification-framework-pref (write)"]
+  verify_set_outbound_notification_framework_pref["verify-set-outbound-notification-framework-pref (verify)"]
+  set_comms_service_console_pref --> verify_set_comms_service_console_pref
+  set_comms_intelligence_pref --> verify_set_comms_intelligence_pref
+  set_outbound_notification_framework_pref --> verify_set_outbound_notification_framework_pref
+```
+
+### Read operations
+
+#### `get-comms-service-console-pref`
+
+Read Comms Service Console (omnichannel agent console) org-pref state. When Identity Verification org-perm is OFF, returns `{status: Failure, IVPrefEnableError}` and never reads the underlying pref.
+
+**Call:** `GET /headless/invoke/platform/comms-service-console-settings`   — status: `implemented`
+
+**Output:** On success returns `{status: "SUCCESS", isPrefEnabled: <bool>}` — the boolean is the current Comms Service Console org-pref state. On Customize Application / System Administrator access denial returns `{status: Failure, message: <RestrictedAccessMessageBody label>}`; when the Identity Verification org-perm is off returns `{status: Failure, message: <IVPrefEnableError label>}` without reading the underlying pref.
+
+#### `get-comms-intelligence-pref`
+
+Read Comms Intelligence (AI-driven insights) org-pref state. Gated by Communications Cloud Setup access; access denial returns `{status: Failure, RestrictedAccessMessageBody}` without reading. No IV gating (unlike Service Console).
+
+**Call:** `GET /headless/invoke/platform/comms-service-console-settings/get-comms-intelligence-pref`   — status: `implemented`
+
+**Output:** On success returns `{status: "SUCCESS", isPrefEnabled: <bool>}` — the boolean is the current Comms Intelligence org-pref state. On access denial (userHasAccessToCommsCloudSetup guard) returns `{status: Failure, message: <RestrictedAccessMessageBody label>}`.
+
+#### `get-outbound-notification-framework-pref`
+
+Read Outbound Notification Framework (Comms Cloud notification pipeline) org-pref state. Gated by Communications Cloud feature access; access denial returns `{status: Failure, RestrictedAccessMessageBody}` without reading.
+
+**Call:** `GET /headless/invoke/platform/comms-service-console-settings/get-outbound-notification-framework-pref`   — status: `implemented`
+
+**Output:** On success returns `{status: "SUCCESS", isPrefEnabled: <bool>}` — the boolean is the current Outbound Notification Framework org-pref state. On access denial (userHasAccessToIndustriesCommsCloudFeature guard) returns `{status: Failure, message: <RestrictedAccessMessageBody label>}`.
+
+### Write operations
+
+#### `set-comms-service-console-pref`
+
+Toggle Comms Service Console org-pref via `enable` boolean. Identity Verification org-perm gates the write — when off, returns `{status: Failure, IVPrefEnableError}` and never calls `setOrgPref`. Save failure surfaces as `PrefEnableError`.
+
+**Call:** `PATCH /headless/invoke/platform/comms-service-console-settings/set-comms-service-console-pref`   — status: `implemented`
+
+**Inputs:**
+
+- `enable` *(`boolean`)* — Toggle the enable preference on or off.
+
+**Output:** On a successful save returns `{status: "SUCCESS", isPrefEnabled: <new bool>}` — mirrors the read envelope with the just-written value. When the Identity Verification org-perm is off returns `{status: Failure, message: <IVPrefEnableError label>}` and never calls setOrgPref. On save failure/exception returns `{status: Failure, message: <PrefEnableError label>}` carrying the prior boolean.
+
+#### `set-comms-intelligence-pref`
+
+Toggle Comms Intelligence org-pref via `enable` boolean. Gated by Communications Cloud Setup access; access denial returns `{status: Failure, RestrictedAccessMessageBody}` without writing. Save failure surfaces as `PrefEnableError`.
+
+**Call:** `PATCH /headless/invoke/platform/comms-service-console-settings/set-comms-intelligence-pref`   — status: `implemented`
+
+**Inputs:**
+
+- `enable` *(`boolean`)* — Toggle the enable preference on or off.
+
+**Output:** On a successful save returns `{status: "SUCCESS", isPrefEnabled: <new bool>}`. On access denial (userHasAccessToCommsCloudSetup guard) returns `{status: Failure, message: <RestrictedAccessMessageBody label>}` without writing. On save failure/exception returns `{status: Failure, message: <PrefEnableError label>}`.
+
+#### `set-outbound-notification-framework-pref`
+
+Toggle Outbound Notification Framework org-pref via `enable` boolean. Gated by Communications Cloud feature access; access denial returns `{status: Failure, RestrictedAccessMessageBody}` without writing. Save/exception failures surface as `PrefEnableError` or `OutboundNotificationFrameworkEnableError`.
+
+**Call:** `PATCH /headless/invoke/platform/comms-service-console-settings/set-outbound-notification-framework-pref`   — status: `implemented`
+
+**Inputs:**
+
+- `enable` *(`boolean`)* — Toggle the enable preference on or off.
+
+**Output:** On a successful save returns `{status: "SUCCESS", isPrefEnabled: <new bool>}`. On access denial (userHasAccessToIndustriesCommsCloudFeature guard) returns `{status: Failure, message: <RestrictedAccessMessageBody label>}` without writing. On save/exception failure returns `{status: Failure, message: <PrefEnableError label>}` or `{status: Failure, message: <OutboundNotificationFrameworkEnableError label>}`.
+
+### Verify operations
+
+#### `verify-set-comms-service-console-pref`
+
+Read back Service Console pref; boolean should equal the written `enable`. `{status: Failure, IVPrefEnableError}` means IV gate is off — neither read nor write touches the pref.
+
+**Call:** `GET /headless/invoke/platform/comms-service-console-settings`
+
+**Depends on:** `set-comms-service-console-pref`
+
+#### `verify-set-comms-intelligence-pref`
+
+Read back Comms Intelligence pref; boolean should equal the written `enable`. `{status: Failure, RestrictedAccessMessageBody}` means the userHasAccessToCommsCloudSetup guard denied — neither read nor write completed.
+
+**Call:** `GET /headless/invoke/platform/comms-service-console-settings/get-comms-intelligence-pref`
+
+**Depends on:** `set-comms-intelligence-pref`
+
+#### `verify-set-outbound-notification-framework-pref`
+
+Read back Outbound Notification Framework pref; boolean should equal the written `enable`. `{status: Failure, RestrictedAccessMessageBody}` means the userHasAccessToIndustriesCommsCloudFeature guard denied — neither read nor write completed.
+
+**Call:** `GET /headless/invoke/platform/comms-service-console-settings/get-outbound-notification-framework-pref`
+
+**Depends on:** `set-outbound-notification-framework-pref`

package/skills/industries-compliance-configure/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: industries-compliance-configure
+description: "Use this skill when users want to read or toggle Industries Compliance org preferences. Trigger when users mention compliance, setup, compliance setup."
+metadata:
+  version: "1.0"
+---
+
+# Managing Compliance Setup
+
+## When to Use This Skill
+
+Read or toggle Industries Compliance org preferences. The wire tokens (used
+both as getPrefs output keys AND as the saveOrgPreference `preference`
+argument) are CmplLogUseUserLocale (admin user-locale formatting in
+compliance views), CmplStatusTransValidation (enforce predefined status
+transitions), and CmplControlTestPref (control-test framework) — NOT the
+friendly UI labels. Per-call atomic write of one preference. A wrong/unknown
+token is a silent no-op (HTTP 200, no change), so always read back via
+getPrefs. Requires Compliance read-write access; org gate
+Compliance features access. No public Connect/Tooling/Metadata/sObject
+alternative — controller is canonical.
+
+## Workflow
+
+Call getPrefs_1 first (returns a map keyed by wire token, each
+{isAccessible, isEnabled}). saveOrgPreference_2 toggles ONE of
+CmplLogUseUserLocale | CmplStatusTransValidation | CmplControlTestPref via
+the `preference` arg (wire token, case-sensitive) + enable=true|false;
+flipping all three needs 3 calls (no batch endpoint). A wrong token returns
+200 but silently does nothing — always re-read via getPrefs_1 and compare
+the target token's isEnabled to the enable you passed.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- Org has the Industries Compliance feature provisioned (Compliance features access). Surfaced in the unified spec info.description; without it the Compliance Setup node is not reachable. (check: `Compliance features access`)
+- Caller holds Compliance read-write access. Both reading (getPrefs_1) and
+writing (saveOrgPreference_2) require the same access — there is no read-only
+tier, so a caller who can read the preferences can also toggle them. (check: `Compliance read-write access`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `getPrefs_1` | read | implemented | `GET /headless/invoke/platform/compliance-setup/get-prefs` | — |
+| `saveOrgPreference_2` | write | implemented | `PATCH /headless/invoke/platform/compliance-setup/save-org-preference` | `getPrefs_1` |
+
+### Read operations
+
+#### `getPrefs_1`
+
+Read all three Industries Compliance preferences in one call. Returns a map
+keyed by wire token (CmplLogUseUserLocale, CmplStatusTransValidation,
+CmplControlTestPref), each entry carrying {isAccessible, isEnabled}. There is
+no per-preference read — a single call returns the full set.
+
+**Call:** `GET /headless/invoke/platform/compliance-setup/get-prefs`   — status: `implemented`
+
+**Output:** Map<String,Object> aggregate. Top level carries one entry per preference,
+keyed by the WIRE TOKEN (not the friendly UI label): CmplLogUseUserLocale,
+CmplStatusTransValidation, CmplControlTestPref. Each entry's shape is
+{isAccessible: boolean, isEnabled: boolean}. isAccessible reflects license +
+read-write access; isEnabled reflects the current toggle state. Read all
+three via one call — no per-preference GET.
+
+### Write operations
+
+#### `saveOrgPreference_2`
+
+Toggle one Industries Compliance preference. Pass the wire token
+(CmplLogUseUserLocale, CmplStatusTransValidation, or CmplControlTestPref —
+the same keys getPrefs_1 returns, case-sensitive) as `preference`, plus
+enable=true|false. One preference per call (no batch endpoint); returns
+HTTP 200 with an empty body on success. A friendly UI label or any
+unrecognized token is a SILENT NO-OP — HTTP 200 with no change — so always
+confirm the result with a getPrefs_1 read-back. Requires Compliance
+read-write access.
+
+**Call:** `PATCH /headless/invoke/platform/compliance-setup/save-org-preference`   — status: `implemented`
+
+**Inputs:**
+
+- `preference` *(`String`)*
+- `enable` *(`boolean`)*
+
+**Depends on:** `getPrefs_1`
+
+**Rollback:** Call saveOrgPreference_2 again with the same preference and
+the inverse enable value. Toggle is idempotent per preference —
+the store persists the last write; there is no history.
+
+**Notes:** idempotency: Re-issuing the same (preference, enable) pair is a no-op at the
+store level. Retries on network error are safe.; atomicity: One preference per call; batching three toggles requires three
+sequential calls. Partial-failure recovery is caller's
+responsibility.; inputs_contract: Both request-body fields — `preference` and `enable` — are required. The full
+request schema, including the valid `preference` enum, is published in the
+OpenAPI spec for this operation.

package/skills/industries-compliance-document-extraction-setup-configure/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: industries-compliance-document-extraction-setup-configure
+description: "Use this skill when users want to read or change the org-wide Compliance Clause Extraction setting (Compliance Document Extraction Setup). Trigger when users mention compliance, document, extraction, setup, compliance document extraction setup."
+metadata:
+  version: "1.0"
+  accessCheck: "Industries.userHasComplianceClauseExtractionAccess"
+---
+
+# Managing Compliance Document Extraction Setup
+
+## When to Use This Skill
+
+Read or change the org-wide Compliance Clause Extraction setting
+(Compliance Document Extraction Setup).
+
+Two operations:
+  - Read the setting. Returns one entry keyed ComplianceClauseExtrctPref with
+    isEnabled (current state) and isAccessible (always true).
+  - Turn it on or off: pass preference = ComplianceClauseExtrctPref and
+    enable = true or false.
+
+Good to know:
+  - An unrecognized preference name returns success but changes nothing, so
+    read the setting back after a write.
+  - The same setting is the public Metadata API field
+    IndustriesSettings.enableComplianceClauseExtrctPref, readable through
+    Tooling API as IndustriesSettings.IsComplianceClauseExtrctPrefEnabled.
+
+Requires Industries Compliance and Einstein generative AI on the org, and a
+Compliance Admin user with access to NLP Service and Scoring Framework.
+
+## Workflow
+
+Call getPrefs_1 to read the current state. To change it, call saveOrgPreference_2 with preference = ComplianceClauseExtrctPref and the desired enable value, then call getPrefs_1 again and compare isEnabled to the value you passed — the write returns an empty 200 even when the name is not recognized. If the user prefers Metadata API, deploying IndustriesSettings with enableComplianceClauseExtrctPref sets the same value.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- Industries Compliance and Einstein generative AI must be enabled for the org. The user needs the Compliance Admin permission set and access to NLP Service and Scoring Framework. Reading and changing the setting require the same access. (check: `Compliance Clause Extraction access`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `getPrefs_1` | read | implemented | `GET /headless/invoke/industries/industries-compliance-docextraction/doc-extraction-org-pref-settings/get-prefs` | — |
+| `saveOrgPreference_2` | write | implemented | `PATCH /headless/invoke/industries/industries-compliance-docextraction/doc-extraction-org-pref-settings/save-org-preference` | `getPrefs_1` |
+
+### Read operations
+
+#### `getPrefs_1`
+
+Read the Compliance Clause Extraction setting. Returns a map with one entry, keyed ComplianceClauseExtrctPref.
+
+**Call:** `GET /headless/invoke/industries/industries-compliance-docextraction/doc-extraction-org-pref-settings/get-prefs`   — status: `implemented`
+
+**Output:** Object keyed by preference name. ComplianceClauseExtrctPref → {isEnabled (boolean — whether Compliance Clause Extraction is on), isAccessible (boolean — always true)}.
+
+### Write operations
+
+#### `saveOrgPreference_2`
+
+Turn Compliance Clause Extraction on or off. preference must be ComplianceClauseExtrctPref (matched case-insensitively); enable is true or false. Returns HTTP 200 with an empty body. An unrecognized name also returns 200 but changes nothing; omitting preference fails.
+
+**Call:** `PATCH /headless/invoke/industries/industries-compliance-docextraction/doc-extraction-org-pref-settings/save-org-preference`   — status: `implemented`
+
+**Inputs:**
+
+- `preference` *(`String`)*
+- `enable` *(`boolean`)*
+
+**Depends on:** `getPrefs_1`

package/skills/industries-contact-center-app-layout-configure/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: industries-contact-center-app-layout-configure
+description: "Act 4 of Contact Center for Health Cloud setup — make the Contact Center Lightning app visible and the default on the contact center profile; add Gender and Birthdate plus the Medication Statements and Member Plans related lists to the Person Account page layout (retrieve, edit, deploy the whole layout, read back); report Timeline state without configuring it."
+metadata:
+  version: "1.0"
+---
+
+# Act 4 of 5 — App default and Person Account page layout (setup-page steps 6, 7 and 3)
+
+Part of the `contact-center-setup` skill. Needs Act 1's toggle (the app) and Act 2's
+contact center profile.
+
+## What this Act does
+
+### Step 6 — Make Contact Center easily accessible to users
+
+1. **Find the app.** `SELECT ApplicationId, Name, Label, NamespacePrefix FROM AppMenuItem WHERE Type = 'TabSet'`
+   and pick the row whose label is the Contact Center app. It appears once Contact Center for Health
+   Cloud is on — if it is missing, re-check Act 1 before anything else. Use the returned `Name`
+   (with namespace prefix if any) as the app's full name; never guess it.
+2. **Read current visibility.** Retrieve the contact center profile **together with** that
+   `CustomApplication` in one package — a profile retrieve only returns `applicationVisibilities` for
+   apps in the same package.
+3. **Deploy** (dry-run first) a partial Profile:
+
+   ```xml
+   <Profile xmlns="http://soap.sforce.com/2006/04/metadata">
+     <applicationVisibilities>
+       <application>APP_FULL_NAME</application>
+       <default>true</default>
+       <visible>true</visible>
+     </applicationVisibilities>
+   </Profile>
+   ```
+
+   Setting a new default clears the old one on that profile — say so in the report ("Reps on the
+   Contact Center User profile now land in the Contact Center app instead of Service").
+4. **Verify** with the paired retrieve from step 2.
+
+### Step 7 — Configure the Person Account page layout
+
+1. **Find the layout reps actually see.** The default is `PersonAccount-Person Account Layout`, but
+   the contact center profile may be assigned another — read the profile's `layoutAssignments`
+   (retrieve the profile with the `Layout` members) and use the assigned one. Tell the admin the
+   layout applies to **every** profile assigned to it.
+2. **Retrieve** that layout. A Layout deploy replaces the whole layout — always edit the retrieved
+   XML, never deploy a fragment.
+3. **Edit, only what is missing:**
+   - Fields **Gender** (`PersonGender`) and **Birthdate** (`PersonBirthdate`) in a details section
+     (`<layoutItems><behavior>Edit</behavior><field>PersonBirthdate</field></layoutItems>`).
+   - Related lists **Medication Statements** and **Member Plans**. For these standard Health Cloud
+     children the layout token is the plural child object name — `MedicationStatements`,
+     `MemberPlans` (the shipped layout's `ClinicalServiceRequests` follows the same form). It is
+     **not** `Child.LookupField` (`MedicationStatement.PatientId` → *Invalid related list*) and
+     **not** the describe `relationshipName` (`Medication_Statement_Patient` → *Cannot find related
+     list*). If the dry-run still rejects a token, retrieve a layout that already shows the list
+     (or ask the admin to add it once in the layout editor) and copy its exact token — don't guess
+     variants.
+   - Help also suggests the **Service Appointments** related list; offer it.
+4. **Dry-run, deploy, retrieve again** and confirm each item is present.
+
+### Step 3 — Timeline (report only)
+
+Timeline is deferred in this version. Read whether a Timeline configuration exists for Person Account
+(the approved `Timeline` node's read step) and report: *"Timeline isn't set up by this skill yet. In
+Setup, open Timeline and add the Engagement Interactions, Engagement Topics and Cases categories to
+the Person Account timeline."* List it under *What the admin finishes by hand*. Help orders Identity
+Verification after Timeline; Act 5 notes that dependency.
+
+## Act end state
+
+- The Contact Center app is visible and the default on the contact center profile, read back.
+- The reps' Person Account layout shows Gender, Birthdate, Medication Statements and Member Plans,
+  read back.
+- Timeline state reported.
+
+## Gotchas
+
+- **Paired retrieve.** Profile `applicationVisibilities` and `layoutAssignments` come back only when
+  the app / layout is in the same retrieve.
+- **Layouts replace whole.** Fragment deploys wipe sections.
+- **Person Account fields are `Person*` on Account.** `Gender` on Contact is a different field.
+- **Dynamic Forms bypass the layout.** If the reps' Lightning record page places fields with Dynamic
+  Forms, layout fields don't show there — report it so the admin adds them in Lightning App Builder.
+
+## Permission sets this Act may assign
+
+None.

package/skills/industries-contact-center-components-configure/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: industries-contact-center-components-configure
+description: "Act 5 of Contact Center for Health Cloud setup — the contact center components: an Identity Verification process that searches by account name, account number, phone number or postal code; the Action Launcher and Record Alerts on the reps' record page; the Patient Card and Profile Card / Member Plan FlexCards (report); and an optional Open CTI softphone (detect and hand off)."
+metadata:
+  version: "1.0"
+---
+
+# Act 5 of 5 — Contact center components
+
+Part of the `contact-center-setup` skill. These are the Help article's components,
+not numbered setup-page steps. Help orders Identity Verification **after** Contact Center and
+Timeline — Act 1 and the Act 4 Timeline report come first.
+
+Ask the admin which components they want before writing; any component they decline is recorded as
+*skipped by choice*, not as a gap.
+
+## What this Act does
+
+### Identity Verification
+
+Reps verify a caller by **account name, account number, phone number or postal code** (Help).
+
+1. **Detect** — read the process and its records:
+   `SELECT Id, DeveloperName, MasterLabel FROM IdentityVerificationProcDef`, then its
+   `IdentityVerificationProcDtl` (search objects) and `IdentityVerificationProcFld` (search and
+   verification fields).
+2. **Report.** A shipped sample process may already exist. Show what it searches and verifies on,
+   in plain words, and ask whether it fits or whether to create the contact center's own process.
+3. **Create on confirmation** of the search object (Account / Person Account) and fields — use the
+   sObject creates on `IdentityVerificationProcDef`, then `IdentityVerificationProcDtl`, then
+   `IdentityVerificationProcFld`, and read them back. Account Number access for the reps is Act 2's
+   step 8; re-check it here if Act 2 didn't run.
+4. **Placement.** The Identity Verification component goes on the record page or utility bar the reps
+   use — same placement pattern as the Action Launcher below.
+5. **Verify** by re-reading the definition, details and fields.
+
+### Action Launcher
+
+Contextual quick actions for the contact center.
+
+1. **Find the reps' record page** — the Person Account Lightning record page assigned for the Contact
+   Center app and profile (`SELECT DeveloperName, MasterLabel, EntityDefinitionId FROM FlexiPage WHERE Type = 'RecordPage'`
+   via Tooling, then read the app's `profileActionOverrides` from the `CustomApplication` retrieve).
+2. **Detect** — retrieve the FlexiPage; look for an Action Launcher `componentInstance`.
+3. **Place.** If another FlexiPage in the org already contains the Action Launcher, copy its exact
+   `componentName` and properties into the retrieved page, dry-run, deploy the whole page, retrieve
+   again. Otherwise hand off: *"In Lightning App Builder, open the record page your reps use, drag
+   Action Launcher into the right column, and save."* — then retrieve and confirm. Never guess a
+   component name.
+4. Customizing which actions it shows (deployment and action categories) is the admin's choice;
+   report what is configured.
+
+### Record Alerts
+
+Informs reps about record changes that need attention.
+
+1. Reps need Read, Create, Edit on Record Alert — Act 2's object permissions. Re-check if Act 2
+   didn't run.
+2. Detect the Record Alerts component on the reps' record page (same retrieve as above); place it
+   the same way.
+3. Alerts themselves come from the org's data and integrations; report how many `RecordAlert` rows
+   exist, don't create sample alerts.
+
+### FlexCards — Patient Card, Profile Card and Member Plan (report)
+
+Patient Card (medication requests, health conditions, allergies, immunizations) and Profile Card /
+Member Plan show on the record page as OmniStudio FlexCards. Detect whether they're on the page;
+reps need the OmniStudio User permission set (Act 2). Placement uses the same retrieve-or-hand-off
+pattern. Don't author or edit FlexCard definitions.
+
+### Open CTI softphone (optional)
+
+Only if the admin uses a third-party telephony provider through Open CTI.
+
+1. Ask first. Skip by default if they use Service Cloud Voice instead.
+2. Detect call centers — `SELECT Id, Name, InternalName FROM CallCenter`. Softphone layouts are
+   checked in Setup.
+3. Hand off the call-center import (the provider supplies the definition file) and adding users to
+   the call center; verify by re-reading the call centers.
+
+## Act end state
+
+- Each component the admin chose is present and read back; each declined one recorded as skipped.
+- The Identity Verification process searches the fields the admin confirmed.
+
+## Gotchas
+
+- **FlexiPages replace whole** — edit the retrieved XML, deploy the full page.
+- **Activation lives on the app / profile, not the page.** Adding a component to an unassigned page
+  changes nothing reps see — confirm which page is assigned first.
+- **Don't duplicate the sample identity process** without asking; reps would see two verification
+  flows.
+
+## Permission sets this Act may assign
+
+None. OmniStudio User for FlexCards and the Action Launcher is Act 2's.

package/skills/industries-contact-center-path-knowledge-configure/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: industries-contact-center-path-knowledge-configure
+description: "Act 3 of Contact Center for Health Cloud setup — turn on Path Settings and deploy an active Engagement Interaction path on Status (New, In Progress, Completed); make sure Lightning Knowledge is on, rep users are Knowledge users (on confirmation) and a How-To article record type exists, following the Service Setup Assistant's outcome."
+metadata:
+  version: "1.0"
+---
+
+# Act 3 of 5 — Engagement Interaction path and Knowledge (setup-page steps 4 and 5)
+
+Part of the `contact-center-setup` skill. Runs after
+Act 2 (`contact-center-setup-act2-user-access`) (reps and their profile are known).
+
+## What this Act does
+
+### Step 4 — Configure Engagement Interaction Path
+
+1. **Detect Path Settings** — one `Settings:PathAssistant` retrieve; read `pathAssistantEnabled`.
+2. If off, deploy the minimal settings document on its own (split-deploy — the path deploy fails while
+   Path Settings is off):
+
+   ```xml
+   <PathAssistantSettings xmlns="http://soap.sforce.com/2006/04/metadata">
+     <pathAssistantEnabled>true</pathAssistantEnabled>
+   </PathAssistantSettings>
+   ```
+
+   Read it back.
+3. **Detect an existing path** — Tooling
+   `SELECT Id, MasterLabel, SobjectType, IsActive FROM PathAssistant WHERE SobjectType = 'EngagementInteraction'`.
+   An active one already exists → report it and write nothing. An inactive one → ask whether to
+   activate it rather than create a second.
+4. **Read the Status values** — `GET /sobjects/EngagementInteraction/describe`, field `Status`. Use the
+   org's active values in their order (shipped: New, In Progress, Completed). Never invent values.
+5. **Deploy the path** (dry-run first), master record type:
+
+   ```xml
+   <PathAssistant xmlns="http://soap.sforce.com/2006/04/metadata">
+     <active>true</active>
+     <entityName>EngagementInteraction</entityName>
+     <fieldName>Status</fieldName>
+     <masterLabel>Engagement Interaction Path</masterLabel>
+     <recordTypeName>__MASTER__</recordTypeName>
+     <pathAssistantSteps><picklistValueName>New</picklistValueName></pathAssistantSteps>
+     <pathAssistantSteps><picklistValueName>In Progress</picklistValueName></pathAssistantSteps>
+     <pathAssistantSteps><picklistValueName>Completed</picklistValueName></pathAssistantSteps>
+   </PathAssistant>
+   ```
+
+   File: `pathAssistants/Engagement_Interaction_Path.pathAssistant-meta.xml`. If Engagement Interaction
+   has record types the reps use, ask which; one path per record type.
+6. **Verify** with the Tooling query from step 3 — `IsActive = true`.
+
+Guidance text per step (*Key fields*, *Guidance for success*) is optional; offer it, don't invent it.
+
+### Step 5 — Let users access Knowledge articles
+
+Help: *"Follow the Service Setup Assistant to add users who can create knowledge articles."* The
+skill reaches the same end state directly:
+
+1. **Detect Knowledge** — retrieve the `KnowledgeSettings` metadata; read `enableKnowledge`
+   and `enableLightningKnowledge`.
+2. If Lightning Knowledge is off: this is **one-way** (it cannot be turned off once on) and the plan
+   must have named it. Deploy `KnowledgeSettings` with `enableKnowledge` true and
+   `enableLightningKnowledge` true; read back. Turning Knowledge on needs at least one Knowledge
+   user — the running admin is usually flagged by the same step; check.
+3. **Knowledge users** — `SELECT Id, Name, UserPermissionsKnowledgeUser FROM User WHERE Id IN (…reps…)`.
+   Flagging a user consumes a Knowledge feature license: report seats, **confirm**, then
+   `PATCH /sobjects/User/{id}` with `UserPermissionsKnowledgeUser: true`. Read back.
+4. **Article record type** — `SELECT DeveloperName, Name, IsActive FROM RecordType WHERE SobjectType = 'Knowledge__kav'`.
+   If none, deploy a `How_To` record type on `Knowledge__kav` (label *How To*, active) and add it to
+   the contact center profile's `recordTypeVisibilities` in a partial Profile deploy. Ask if the
+   org uses a different article type name (some orgs use *FAQ*). The Knowledge object's API name
+   may differ if the admin renamed it at enablement — read it from the Knowledge settings first.
+5. **Knowledge LSF Permission Set** — Act 2 assigns it where the org has it. Mention it here if Act 2
+   reported it missing.
+6. Data categories and article visibility are optional; report what exists (list `DataCategoryGroup`
+   metadata) and leave them to the admin.
+
+## Act end state
+
+- Path Settings on; an active Engagement Interaction path on Status, read back.
+- Lightning Knowledge on; confirmed reps flagged as Knowledge users; an active article record type
+  visible to the contact center profile.
+
+## Gotchas
+
+- **Path deploy before Path Settings fails.** Two transactions.
+- **Lightning Knowledge is permanent.** Never turn it on without the plan having said so.
+- **`UserPermissionsKnowledgeUser` fails without a seat** — report `LICENSE_LIMIT_EXCEEDED` in plain
+  words ("you're out of Knowledge user licenses"), don't retry.
+- **Don't create duplicate paths.** One active path per object + record type.
+
+## Permission sets this Act may assign
+
+None directly. The Knowledge User flag on rep users is confirmed per user like a permission set.