@salesforce/afv-skills 1.64.0 → 1.65.0

package/skills/industries-contact-center-user-access-assign/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: industries-contact-center-user-access-assign
+description: "Act 2 of Contact Center for Health Cloud setup — give contact center reps access: check-report-confirm-assign the Contact Center for Health Cloud, Health Cloud Foundation, Knowledge LSF and OmniStudio User permission sets; create the Contact Center User profile (a Standard User clone) with Read, Create and Edit on Engagement Interaction, Engagement Topic, Engagement Attendee and Record Alert; verify Account Number field-level security; assign the profile on confirmation."
+metadata:
+  version: "1.0"
+---
+
+# Act 2 of 5 — User access (setup-page steps 1, 2 and 8)
+
+Part of the `contact-center-setup` skill. Runs after
+Act 1 (`contact-center-setup-act1-prereqs-enable`) has turned Contact Center for Health Cloud on.
+
+## What this Act does
+
+### Step 1 — Assign permissions and licenses to users
+
+1. Ask the admin **which users are contact center reps** (by name or by an existing profile / role).
+   Never assume the admin is a rep.
+2. For each rep, read assigned permission sets and licenses:
+   `SELECT AssigneeId, PermissionSet.Name FROM PermissionSetAssignment WHERE AssigneeId IN (…)` and
+   `SELECT AssigneeId, PermissionSetLicense.DeveloperName FROM PermissionSetLicenseAssign WHERE AssigneeId IN (…)`.
+3. Required for every rep (query by DeveloperName):
+
+   | UI label | DeveloperName | Note |
+   |---|---|---|
+   | Contact Center for Health Cloud | `ContactCenterforHealthCloud` | The admin got it in Act 1; reps still need it |
+   | Health Cloud Foundation | `HealthCloudFoundation` | |
+   | Knowledge LSF Permission Set | resolve by label → `Name` on the org | Only exists if the org has the Salesforce Knowledge feature license; absent = report, not an error |
+   | OmniStudio User | `OmniStudioUser` (and `OmniStudioExecution` if a second *OmniStudio User* set exists) | If there are two OmniStudio User sets, assign both |
+
+4. Report the per-user gap in plain language and **assign only what the admin confirms**:
+   `POST /sobjects/PermissionSetAssignment`. Permission set licenses are assigned automatically when
+   the permission set is assigned; if an assignment fails for a missing license, assign it with
+   `POST /sobjects/PermissionSetLicenseAssign` and retry. `DUPLICATE_VALUE` = already assigned.
+5. Read assignments back.
+
+### Step 2 — Contact Center User profile and object permissions
+
+1. **Detect the profile.** Ask what the reps' profile is called (suggest *Contact Center User*);
+   `SELECT Id, Name, UserLicense.Name FROM Profile WHERE Name = '<name>'`.
+2. **If missing — hand off the clone.** Cloning in Setup keeps Standard User's baseline permissions;
+   a profile created from metadata starts with almost nothing, so do not create it by deploy:
+   *"From Setup, enter Profiles in Quick Find, click Clone next to Standard User, name it Contact
+   Center User, and save. Tell me when it's there."* Then re-query.
+3. **Object permissions.** Read
+   `SELECT SobjectType, PermissionsRead, PermissionsCreate, PermissionsEdit FROM ObjectPermissions WHERE Parent.Profile.Name = '<name>' AND SobjectType IN ('EngagementInteraction','EngagementTopic','EngagementAttendee','RecordAlert')`.
+   For anything missing, deploy a **partial Profile** (only these elements) — Read, Create, Edit on all
+   four:
+
+   ```xml
+   <Profile xmlns="http://soap.sforce.com/2006/04/metadata">
+     <objectPermissions>
+       <object>EngagementInteraction</object>
+       <allowRead>true</allowRead><allowCreate>true</allowCreate><allowEdit>true</allowEdit>
+       <allowDelete>false</allowDelete><viewAllRecords>false</viewAllRecords><modifyAllRecords>false</modifyAllRecords>
+     </objectPermissions>
+     <!-- same for EngagementTopic, EngagementAttendee, RecordAlert -->
+     <fieldPermissions>
+       <field>Account.AccountNumber</field><readable>true</readable><editable>true</editable>
+     </fieldPermissions>
+   </Profile>
+   ```
+
+   The file name is the profile's API name (for a cloned profile, its name with spaces, e.g.
+   `Contact Center User.profile-meta.xml`). Dry-run, deploy, re-read `ObjectPermissions`.
+4. **Assign the profile** to the rep users — **confirm first** (changing a user's profile changes
+   everything they can do): `PATCH /sobjects/User/{id}` with `ProfileId`. Read back.
+
+### Step 8 — Verify automated setup actions (Account Number field-level security)
+
+Turning Contact Center on grants access to the Account **Account Number** field — identity
+verification searches on it. Verify for the contact center profile:
+`SELECT PermissionsRead, PermissionsEdit FROM FieldPermissions WHERE SobjectType = 'Account' AND Field = 'Account.AccountNumber' AND Parent.Profile.Name = '<name>'`.
+If missing, it rides in the same partial Profile deploy above (`fieldPermissions`). A cloned profile
+created **after** the toggle may not have inherited it — always check.
+
+## Act end state
+
+- Each confirmed rep holds the four permission sets (or the Knowledge set reported as unavailable).
+- The contact center profile exists with Read, Create, Edit on the four objects and Account Number
+  readable, all read back.
+- Confirmed reps are on that profile.
+
+## Gotchas
+
+- **Labels vs. names.** *Knowledge LSF Permission Set* has no fixed API name across orgs —
+  resolve it by `Label` and use the returned `Name`; zero rows means no Knowledge feature license.
+- **Profile deploys are partial; layouts are not.** Listing only `objectPermissions` and
+  `fieldPermissions` in a Profile deploy changes only those entries.
+- **Don't deploy a new profile.** Clone in Setup; then deploy the deltas.
+- **Rep vs. admin.** Assign to the rep users the admin names. The admin gets rep sets only if they ask.
+
+## Permission sets this Act may assign (on confirmation)
+
+Contact Center for Health Cloud, Health Cloud Foundation, Knowledge LSF Permission Set, OmniStudio
+User — see `ref:contact-center-setup/source/references/licensing-and-permission-sets`. Plus the profile assignment itself.

package/skills/industries-course-waitlist-config-configure/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: industries-course-waitlist-config-configure
+description: "Use this skill when users want to configure CourseWaitlistConfig records that drive Education Cloud course-waitlist behavior. Trigger when users mention course, waitlist, config, course waitlist config."
+metadata:
+  version: "1.0"
+  accessCheck: "UserPermissions.AccessEducationCloud"
+---
+
+# Managing Course Waitlist Config
+
+## When to Use This Skill
+
+Configure CourseWaitlistConfig records that drive Education Cloud course-waitlist behavior. Two Type values: WaitlistPosition (ranking rules — agent rows with the same Type form a contiguous WaitlistPositionFieldOrder sequence the controller maintains server-side: insert shifts higher rows by +1, update reorders middle rows, delete compacts to 1..N) and EnrollmentOfferExpiration (single-config offer-acceptance window). All four CRUD steps are AURA-IS-CANONICAL because the controller's position cascade cannot be reconstructed by raw Tooling Insert/Update/Delete or by Metadata API XML deploy.
+
+## Workflow
+
+Read with get-course-waitlist-configs first; rows return ordered by WaitlistPositionFieldOrder ASC. Use the returned recordId for update/delete. The position cascade fires server-side only when Type=WaitlistPosition and waitlistPositionFieldOrder is set; EnrollmentOfferExpiration creates/updates do not reorder siblings.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- User must have IndustriesEducation EducationCloudAccess access (check: `Education Cloud access`)
+- Org must have Academic Operations enabled (UDD orgAccess + userAccess on the CourseWaitlistConfig setupEntity). (check: `Education Cloud Academic Operations`)
+- User must have the AccessEducationCloud user permission (UDD userAccess). (check: `UserPermissions.AccessEducationCloud`)
+- Write/delete operations additionally require an admin user (UDD editAccess + createAccess + deleteAccess all combine isAdminUser with the org/user gates). (check: `Education Cloud admin access`)
+
+**Destructive operations — require explicit user confirmation:**
+
+- **`delete-course-waitlist-config`** — Deletes a CourseWaitlistConfig row by recordId. AURA-IS-CANONICAL — pre-delete the controller queries the row's Type; if it was WaitlistPosition, post-delete compactPositionsAfterDeletion renumbers every remaining WaitlistPosition row to a contiguous 1..N WaitlistPositionFieldOrder sequence to remove the gap. A raw Tooling Delete leaves a numbering gap (e.g. 1, 2, 4, 5).
+  - Rollback: No automatic rollback.
+
+## Verification Checklist
+
+After every write operation, confirm the effect by re-reading state:
+
+- After `create-course-waitlist-config`: call `verify-create-course-waitlist-config` (`GET /headless/invoke/platform/course-waitlist-config`)
+- After `update-course-waitlist-config`: call `verify-update-course-waitlist-config` (`GET /headless/invoke/platform/course-waitlist-config`)
+- After `delete-course-waitlist-config`: call `verify-delete-course-waitlist-config` (`GET /headless/invoke/platform/course-waitlist-config`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `get-course-waitlist-configs` | read | proposed | `GET /headless/invoke/platform/course-waitlist-config` | — |
+| `create-course-waitlist-config` | write | proposed | `PATCH /headless/invoke/platform/course-waitlist-config/create-course-waitlist-config` | — |
+| `update-course-waitlist-config` | write | proposed | `PATCH /headless/invoke/platform/course-waitlist-config/update-course-waitlist-config` | `get-course-waitlist-configs` |
+| `delete-course-waitlist-config` | delete | proposed | `DELETE /headless/invoke/platform/course-waitlist-config/delete-course-waitlist-config` | `get-course-waitlist-configs` |
+| `verify-create-course-waitlist-config` | verify | — | `GET /headless/invoke/platform/course-waitlist-config` | `create-course-waitlist-config` |
+| `verify-update-course-waitlist-config` | verify | — | `GET /headless/invoke/platform/course-waitlist-config` | `update-course-waitlist-config` |
+| `verify-delete-course-waitlist-config` | verify | — | `GET /headless/invoke/platform/course-waitlist-config` | `delete-course-waitlist-config` |
+
+### Dependency graph
+
+```mermaid
+graph TD
+  get_course_waitlist_configs["get-course-waitlist-configs (read)"]
+  create_course_waitlist_config["create-course-waitlist-config (write)"]
+  update_course_waitlist_config["update-course-waitlist-config (write)"]
+  delete_course_waitlist_config["delete-course-waitlist-config (delete)"]
+  verify_create_course_waitlist_config["verify-create-course-waitlist-config (verify)"]
+  verify_update_course_waitlist_config["verify-update-course-waitlist-config (verify)"]
+  verify_delete_course_waitlist_config["verify-delete-course-waitlist-config (verify)"]
+  get_course_waitlist_configs --> update_course_waitlist_config
+  get_course_waitlist_configs --> delete_course_waitlist_config
+  create_course_waitlist_config --> verify_create_course_waitlist_config
+  update_course_waitlist_config --> verify_update_course_waitlist_config
+  delete_course_waitlist_config --> verify_delete_course_waitlist_config
+```
+
+### Read operations
+
+#### `get-course-waitlist-configs`
+
+Lists every CourseWaitlistConfig row ordered by WaitlistPositionFieldOrder ASC. Each entry exposes Id, DeveloperName, MasterLabel, Type, Value, WaitlistPositionFieldOrder, SortOrder. AURA-IS-CANONICAL: UDD perApiAccess marks the entity Tooling-queryable, but no tooling_sobject_coverage evidence file is present in the corpus snapshot, so the substitution is held back as a coverage_gap (see notes).
+
+**Call:** `GET /headless/invoke/platform/course-waitlist-config`   — status: `proposed`
+
+**Output:** items: array<CourseWaitlistConfig> — each item carries Id (string), DeveloperName (string), MasterLabel (string), Type ("WaitlistPosition" | "EnrollmentOfferExpiration"), Value (string), WaitlistPositionFieldOrder (integer | null), SortOrder ("Ascending" | "Descending" | null). Empty list when no rows exist.
+
+### Write operations
+
+#### `create-course-waitlist-config`
+
+Creates a CourseWaitlistConfig via CourseWaitlistConfigService. AURA-IS-CANONICAL — when type=WaitlistPosition and waitlistPositionFieldOrder is set, the controller calls shiftPositionsForInsertion which UPDATES every existing WaitlistPosition row at-or-above the new position by +1, then inserts the new row. A raw Tooling Insert would land the row but break the position-uniqueness invariant; a Metadata deploy cannot perform a bulk sibling reorder in one transaction.
+
+**Call:** `PATCH /headless/invoke/platform/course-waitlist-config/create-course-waitlist-config`   — status: `proposed`
+
+**Inputs:**
+
+- `developerName` *(`String`)* — Name of the developer.
+- `masterLabel` *(`String`)* — Label shown for master.
+- `type` *(`String`)* — Value for the type field.
+- `value` *(`String`)* — Value for the value field.
+- `waitlistPositionFieldOrder` *(`Integer`)* — Numeric value for the waitlist position field order setting.
+- `sortOrder` *(`String`)* — Value for the sort order field.
+
+**Output:** Operation envelope: {success: true, recordId: <id of the new CourseWaitlistConfig row>}. ServiceException is wrapped as AuraHandledException by the controller — caller sees a logging-only and a generic error message.
+
+#### `update-course-waitlist-config`
+
+Updates an existing CourseWaitlistConfig row by recordId. AURA-IS-CANONICAL — when waitlistPositionFieldOrder changes, handlePositionUpdateIfNeeded → reorderPositionsForUpdate → calculateAdjustedPosition rewrites every sibling row in the affected window (move-up shifts middle rows down by 1; move-down shifts middle rows up by 1). developerName and type are not in the update signature — those are immutable post-create.
+
+**Call:** `PATCH /headless/invoke/platform/course-waitlist-config/update-course-waitlist-config`   — status: `proposed`
+
+**Inputs:**
+
+- `recordId` *(`String`)* — Id of the record.
+- `masterLabel` *(`String`)* — Label shown for master.
+- `value` *(`String`)* — Value for the value field.
+- `waitlistPositionFieldOrder` *(`Integer`)* — Numeric value for the waitlist position field order setting.
+- `sortOrder` *(`String`)* — Value for the sort order field.
+
+**Depends on:** `get-course-waitlist-configs`
+
+**Output:** Operation envelope: {success: true, recordId: <the same recordId passed in>}. ServiceException is wrapped as AuraHandledException.
+
+### Verify operations
+
+#### `verify-create-course-waitlist-config`
+
+Re-list all CourseWaitlistConfig rows and confirm the new recordId is present with the developerName/masterLabel/type/value supplied to create. Also confirms the post-cascade WaitlistPositionFieldOrder placement when type=WaitlistPosition.
+
+**Call:** `GET /headless/invoke/platform/course-waitlist-config`
+
+**Depends on:** `create-course-waitlist-config`
+
+#### `verify-update-course-waitlist-config`
+
+Re-list and locate the row by recordId; confirm masterLabel / value / waitlistPositionFieldOrder / sortOrder match the update inputs. When waitlistPositionFieldOrder changed, also confirm the sibling row positions reflect the cascade.
+
+**Call:** `GET /headless/invoke/platform/course-waitlist-config`
+
+**Depends on:** `update-course-waitlist-config`
+
+#### `verify-delete-course-waitlist-config`
+
+Re-list and confirm the deleted recordId is absent. When the deleted row was Type=WaitlistPosition, also confirm remaining WaitlistPosition rows have a contiguous 1..N WaitlistPositionFieldOrder (no gap).
+
+**Call:** `GET /headless/invoke/platform/course-waitlist-config`
+
+**Depends on:** `delete-course-waitlist-config`
+
+### Destructive operations
+
+#### `delete-course-waitlist-config`
+
+Deletes a CourseWaitlistConfig row by recordId. AURA-IS-CANONICAL — pre-delete the controller queries the row's Type; if it was WaitlistPosition, post-delete compactPositionsAfterDeletion renumbers every remaining WaitlistPosition row to a contiguous 1..N WaitlistPositionFieldOrder sequence to remove the gap. A raw Tooling Delete leaves a numbering gap (e.g. 1, 2, 4, 5).
+
+**Call:** `DELETE /headless/invoke/platform/course-waitlist-config/delete-course-waitlist-config`   — status: `proposed`
+
+**Inputs:**
+
+- `recordId` *(`String`)*
+
+**Depends on:** `get-course-waitlist-configs`
+
+**Output:** Operation envelope: {success: true, recordId: <the deleted recordId>}. ServiceException is wrapped as AuraHandledException.

package/skills/industries-crisis-center-settings-configure/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: industries-crisis-center-settings-configure
+description: "Use this skill when users want to read or toggle the Crisis Center org access preference for Health Cloud. Trigger when users mention crisis, center, settings, crisis center settings."
+metadata:
+  version: "1.0"
+  accessCheck: "(IndustriesSettingAccessCheck.USER_PERMISSION_CRISIS_CENTER_USER_ACCESS) || (UngroupedSettingAccessCheck.USER_PERMISSION_CUSTOMIZE_APPLICATION) || (setupUtil.hasViewSetup)"
+---
+
+# Managing Crisis Center Settings
+
+## When to Use This Skill
+
+Read or toggle the Crisis Center org access preference for Health Cloud. Requires View Setup, Customize Application and the Crisis Center user permission, and the org must have the Crisis Center license. Enabling also publishes a product-usage telemetry event that no Metadata or Tooling write reproduces.
+
+## Workflow
+
+Read the current boolean, toggle it with the boolean `value`, then re-read to confirm, because the toggle returns no body. A localized no-access error means one of the four gates (View Setup, Customize Application, the Crisis Center user permission, the Crisis Center license) is off, not a bad payload.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- Org has the Health Cloud Crisis Center license enabled. Without it, both the read and the toggle return an access error. (check: `Crisis Center license`)
+- Caller has View Setup access. (check: `setupUtil.hasViewSetup`)
+- Caller has the Customize Application user permission. (check: `UngroupedSettingAccessCheck.USER_PERMISSION_CUSTOMIZE_APPLICATION`)
+- Caller has the Crisis Center user permission. (check: `IndustriesSettingAccessCheck.USER_PERMISSION_CRISIS_CENTER_USER_ACCESS`)
+
+## Verification Checklist
+
+After every write operation, confirm the effect by re-reading state:
+
+- After `handleCrisisCenterToggle_2`: call `verify-crisis-center-org-pref` (`GET /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/get-crisis-center-org-pref`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `getCrisisCenterOrgPref_1` | read | implemented | `GET /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/get-crisis-center-org-pref` | — |
+| `handleCrisisCenterToggle_2` | write | implemented | `PATCH /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/handle-crisis-center-toggle` | `getCrisisCenterOrgPref_1` |
+| `verify-crisis-center-org-pref` | verify | implemented | `GET /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/get-crisis-center-org-pref` | `handleCrisisCenterToggle_2` |
+
+### Read operations
+
+#### `getCrisisCenterOrgPref_1`
+
+Returns whether the Crisis Center org access preference is enabled. Fails with a localized no-access error when the caller lacks View Setup, Customize Application or the Crisis Center user permission, or the org lacks the Crisis Center license.
+
+**Call:** `GET /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/get-crisis-center-org-pref`   — status: `implemented`
+
+**Output:** Boolean; true when the Crisis Center org access preference is enabled.
+
+**Notes:** verification_note: No public Connect, Tooling, Metadata or sObject API exposes this preference (live probes of the Setup Connect preference API and Tooling OrgPreferenceSettings both failed), so the controller read is the only surface.
+
+### Write operations
+
+#### `handleCrisisCenterToggle_2`
+
+Sets the Crisis Center org access preference to the boolean `value`. Same access gate as the read; a failed save returns the first save error. When `value` is true the controller also publishes a product-usage telemetry event. Returns no body.
+
+**Call:** `PATCH /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/handle-crisis-center-toggle`   — status: `implemented`
+
+**Inputs:**
+
+- `value` *(`boolean`)*
+
+**Depends on:** `getCrisisCenterOrgPref_1`
+
+**Notes:** verification_note: The license gate, the Crisis Center user-permission gate and the enable-only telemetry event are controller-only behaviour; no Metadata, Tooling or sObject write reproduces them, so the controller toggle is the canonical write.
+
+### Verify operations
+
+#### `verify-crisis-center-org-pref`
+
+Re-read the preference with getCrisisCenterOrgPref after handleCrisisCenterToggle; both read and write the same org preference, so the returned boolean must match the requested value.
+
+**Call:** `GET /headless/invoke/industries/industries-healthcare/crisis-center-setup-page/get-crisis-center-org-pref`   — status: `implemented`
+
+**Depends on:** `handleCrisisCenterToggle_2`
+
+**Output:** Boolean equal to the value passed to handleCrisisCenterToggle on success.

package/skills/industries-custom-object-settings-configure/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: industries-custom-object-settings-configure
+description: "Use this skill when users want to manage two Compliant Data Sharing rules for deleting a custom object's sharing permission: `CdsDeleteCOPEditOnParentPref` (require Edit access on the parent record before the permission can be deleted) and `CdsDeleteCOPByParentOwnerPref` (let the parent record's owner delete it). Trigger when users mention custom, object, settings, custom object settings."
+metadata:
+  version: "1.0"
+  accessCheck: "IndustriesCompliantDataSharing.userHasIndustriesConfigCompliantDataSharing && (UserPermissions.CustomizeApplication || UserPermissions.ModifyAllData)"
+---
+
+# Managing Custom Object Settings
+
+## When to Use This Skill
+
+Manage two Compliant Data Sharing rules for deleting a custom object's sharing permission: `CdsDeleteCOPEditOnParentPref` (require Edit access on the parent record before the permission can be deleted) and `CdsDeleteCOPByParentOwnerPref` (let the parent record's owner delete it). Reads the current values and toggles either one. Setup administrator access required.
+
+## Workflow
+
+Read the current settings first, then toggle.
+
+### Phase 1: Call getAccessCheckValues_1 to read the current state. It...
+
+Call getAccessCheckValues_1 to read the current state. It returns three flags: `CdsDeleteCOPEditOnParentPref` and `CdsDeleteCOPByParentOwnerPref` (the current on/off state of each deletion rule) and `OrgHasCDSCustomObjects` (whether Compliant Data Sharing is available in the org and support for custom objects is enabled).
+
+### Phase 2: Prerequisite — Compliant Data Sharing support for custom...
+
+Prerequisite — Compliant Data Sharing support for custom objects must be enabled before these settings can be saved. Check `OrgHasCDSCustomObjects` from step 1. If it is false, custom-object support is not enabled: an admin must first enable it on the Object Enablement Settings page by turning on the Custom Object entry. (Programmatically, that is the ObjectEnablementSettings skill — call updateEntityPreference with parentEntityName "Custom Object" and isEnabled true.) Until that is done, savePref_2 is rejected.
+
+### Phase 3: When OrgHasCDSCustomObjects is true, call savePref_2 with pref...
+
+When `OrgHasCDSCustomObjects` is true, call savePref_2 with `pref` set to one of the two rule names above and `enabled` set to the desired on/off value. Any other `pref` name is rejected.
+
+### Phase 4: Call verify-savePref_2 to confirm the change took effect...
+
+Call verify-savePref_2 to confirm the change took effect — savePref returns no body, so re-reading is the only confirmation.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- You must have Setup administrator access. Without it, the settings are not returned and cannot be saved. (check: `Setup administrator access`)
+- Your org must have access to configure Compliant Data Sharing. (check: `Compliant Data Sharing configuration access`)
+- Saving a setting additionally requires Compliant Data Sharing support for custom objects to be enabled. Enable it on the Object Enablement Settings page by turning on the Custom Object entry — the read step's `OrgHasCDSCustomObjects` flag tells you whether this is already satisfied. (check: `Compliant Data Sharing support for custom objects enabled`)
+
+## Verification Checklist
+
+After every write operation, confirm the effect by re-reading state:
+
+- After `savePref_2`: call `verify-savePref_2` (`GET /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/get-access-check-values`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `getAccessCheckValues_1` | read | implemented | `GET /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/get-access-check-values` | — |
+| `savePref_2` | write | implemented | `PATCH /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/save-pref` | `getAccessCheckValues_1` |
+| `verify-savePref_2` | verify | implemented | `GET /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/get-access-check-values` | `savePref_2` |
+
+### Read operations
+
+#### `getAccessCheckValues_1`
+
+Reads the current Compliant Data Sharing custom-object settings. Returns three flags keyed by name: `CdsDeleteCOPEditOnParentPref` and `CdsDeleteCOPByParentOwnerPref` (the current on/off state of each deletion rule) and `OrgHasCDSCustomObjects` (whether Compliant Data Sharing is available in the org and support for custom objects is enabled — this must be true before either rule can be saved). Compliant Data Sharing configuration access and Setup administrator access are required; a caller without the required access receives an access error instead of the flags.
+
+**Call:** `GET /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/get-access-check-values`   — status: `implemented`
+
+**Output:** Three boolean flags keyed by name: `CdsDeleteCOPEditOnParentPref`, `CdsDeleteCOPByParentOwnerPref`, and `OrgHasCDSCustomObjects`. Returns an access error when the caller lacks Compliant Data Sharing configuration access or Setup administrator access.
+
+### Write operations
+
+#### `savePref_2`
+
+Saves one Compliant Data Sharing deletion rule. Set `pref` to either `CdsDeleteCOPEditOnParentPref` (require Edit access on the parent record before a custom object's sharing permission can be deleted) or `CdsDeleteCOPByParentOwnerPref` (allow the parent record's owner to delete the sharing permission) — no other value is accepted. Set `enabled` to the desired on/off value. Saving requires Compliant Data Sharing configuration access and Setup administrator access, and the org must have Compliant Data Sharing support for custom objects enabled (see `OrgHasCDSCustomObjects` from the read step; enable the Custom Object entry on the Object Enablement Settings page if it is false). Returns no body; use the verify step to confirm.
+
+**Call:** `PATCH /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/save-pref`   — status: `implemented`
+
+**Inputs:**
+
+- `pref` *(`String`)*
+- `enabled` *(`boolean`)*
+
+**Depends on:** `getAccessCheckValues_1`
+
+### Verify operations
+
+#### `verify-savePref_2`
+
+Re-reads the settings and confirms the flag matching the `pref` you saved now equals the `enabled` value you sent. Because saving returns no body, this read-back is the only way to confirm the change persisted.
+
+**Call:** `GET /headless/invoke/industries/industries-compliant-datasharing/custom-object-settings/get-access-check-values`   — status: `implemented`
+
+**Depends on:** `savePref_2`

package/skills/industries-data-cloud-integration-configure/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: industries-data-cloud-integration-configure
+description: "Use this skill when users want to industries admin-setup wizard backing the Nonprofit Cloud Fundraising 'Data Cloud Integration' setup page, known to customers as \"Fundraising Intelligence Settings\". Trigger when users mention data, cloud, integration, data cloud integration."
+metadata:
+  version: "1.0"
+---
+
+# Managing Data Cloud Integration
+
+## When to Use This Skill
+
+Industries admin-setup wizard backing the Nonprofit Cloud Fundraising 'Data Cloud Integration' setup page, known to customers as "Fundraising Intelligence Settings". Generic AdminSetupController with three @AuraEnabled methods. The GET reads a setupConfig JSON (resolved relative to ui-industries-common-components/resources/setupConfig/) keyed by fileName and returns AdminSetupRepresentation: ordered groups containing dependency-ordered steps with action/actionResponse descriptors plus stepAccessCheck, preValidation, and stepCompletionCheck identifiers. The two PATCHes invoke server-side AdminSetupStepActionExecutor Spring beans by name; one accepts a String-to-String params map, the other does not. The setupConfig JSON is the source of truth for the step graph and the runtime registry of executable action names. No public Connect, Tooling, Metadata, or sObject equivalent exists for this surface — action names resolve at runtime to feature-specific beans, so substitution would lose both the dispatcher's access-guard and the per-step PermissionParser evaluation. Workflow: GET first to discover available step actions, then PATCH each in dependency order.
+
+## Workflow
+
+Call get-admin-setup-data first (with the page's fileName) to discover the current setupConfig's action names, dependency graph, and per-step access state. Then dispatch each step via execute-admin-setup-step-action when no caller inputs are required, or parameterized-execute-admin-setup-step-action when the step expects a String-to-String params map. Action names are runtime-resolved Spring bean names; do not invent them — read them from the GET response.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- User must have Industries AccessSetup access (controller-level guard on executeAdminSetupStepAction). (check: `View Setup permission`)
+- Org must have the Nonprofit Cloud Fundraising / Nonprofit Intelligence feature enabled. (check: `Nonprofit Intelligence access`)
+- Running user must be configured as a Fundraising admin. (check: `Fundraising Admin role`)
+- API version must be v248 or later (setup-manifest 'since' for this node). (check: `None`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `get-admin-setup-data` | read | proposed | `GET /headless/invoke/platform/data-cloud-integration` | — |
+| `execute-admin-setup-step-action` | write | proposed | `PATCH /headless/invoke/platform/data-cloud-integration/execute-admin-setup-step-action` | `get-admin-setup-data` |
+| `parameterized-execute-admin-setup-step-action` | write | proposed | `PATCH /headless/invoke/platform/data-cloud-integration/parameterized-execute-admin-setup-step-action` | `get-admin-setup-data` |
+
+### Read operations
+
+#### `get-admin-setup-data`
+
+Reads the setupConfig JSON named by fileName (resolved relative to ui-industries-common-components/resources/setupConfig/) and returns AdminSetupRepresentation. AURA-IS-CANONICAL — no public Connect/Tooling/Metadata/sObject alternative; setupConfig descriptors are Java resource files, not CRUD-able entities. Read-only; per-step stepAccessCheck/groupAccessCheck filters apply server-side.
+
+**Call:** `GET /headless/invoke/platform/data-cloud-integration`   — status: `proposed`
+
+**Inputs:**
+
+- `fileName` *(`String`)*
+
+**Output:** AdminSetupRepresentation: isSuccess (boolean), errors (ErrorRepresentation list — populated on parse/validation failure; only errorMessage carries content from the get path), featureName (echoes fileName), configurations (ordered AdminSetupGroupRepresentation list, filtered + renumbered by per-user groupAccessCheck — each group bundles dependency-ordered AdminSetupStepRepresentation steps carrying name, order, dependency indices, action+actionResponse descriptors, helpUrl/helpUrlLabel, preValidation/validationMessage, stepAccessCheck, stepCompletionCheck, ignoreStepProgress), disableReset (boolean — when true the wizard hides the reset control).
+
+**Notes:** setup_config_filename: For this node, fileName resolves to FundraisingIntelligenceSetup.json, confirmed via source and a live headless GET. Customer-facing page name: "Fundraising Intelligence Settings".; genie_gating: 4 of the 10 steps in FundraisingIntelligenceSetup.json (3 groups of 2/7/1; 7 ButtonNavigate, 1 Manual, 2 LaunchComponent) carry a stepAccessCheck gated on "Data Cloud platform enabled". A live headless GET confirmed these steps are filtered out of the returned step graph server-side when the org lacks Genie Platform — observed in both license states (6 steps unlicensed → 10 once licensed, matching the UI) — the gate is runtime-enforced, not a UI-only toggle.; completion_status_fidelity_gap: The GET returns each step's stepCompletionCheck bean name but not its evaluated result — step objects carry no completed field and groupStatus is null. The Setup UI runs those validators (green checks / % complete) but the headless path does not, and no operation exposes running them. The skill is structure-aware but not progress-aware: an agent can list and route steps but can't report which are already done. Suggested to the owning team: return evaluated completion status in the GET, or add an operation to run the completion-check beans.
+
+### Write operations
+
+#### `execute-admin-setup-step-action`
+
+Invokes the server-side AdminSetupStepActionExecutor Spring bean named by actionName (must match an action.name from a prior getAdminSetupData response). Gated by the controller-level View Setup permission access guard. Returns AdminSetupStepActionResultRepresentation. AURA-IS-CANONICAL — no public alternative because action names resolve at runtime to feature-specific beans, and substitution would drop the controller's access-guard.
+
+**Call:** `PATCH /headless/invoke/platform/data-cloud-integration/execute-admin-setup-step-action`   — status: `proposed`
+
+**Inputs:**
+
+- `actionName` *(`String`)* — Name of the action.
+
+**Depends on:** `get-admin-setup-data`
+
+**Output:** AdminSetupStepActionResultRepresentation: result (boolean — true when the resolved AdminSetupStepActionExecutor bean reported success; thrown exceptions surface as AuraHandledException and never reach result=false), error (ErrorRepresentation, populated only on recoverable executor-reported failures), custom (string-keyed map — always null on this no-args path, populated only by the parameterized variant).
+
+**Notes:** executor_allowlist_risk: This is a generic dispatcher that executes an AdminSetupStepActionExecutor Spring bean by caller-supplied actionName. Safe today because every action in FundraisingIntelligenceSetup.json is ButtonNavigate/Manual/LaunchComponent — no action currently maps to a mutating install/authorize bean. A live PATCH probe with a config action name returned 200 {"custom":{},"error":{}}, a benign no-op (no bean resolved, nothing mutated). Recommend an explicit allowlist of executable action names; re-review if the setupConfig ever registers an executor-backed install/authorize action.
+
+#### `parameterized-execute-admin-setup-step-action`
+
+Like execute-admin-setup-step-action but forwards a String-to-String params map to the executor bean — use when the step requires caller-supplied inputs. NOT decorated with the controller-level View Setup permission guard; access is enforced via the loaded setupConfig's stepAccessCheck (PermissionParser evaluation per group/step). Returns AdminSetupStepActionResultRepresentation with handler-defined custom map. AURA-IS-CANONICAL — runtime-bean dispatch + stepAccessCheck enforcement have no system-API analog.
+
+**Call:** `PATCH /headless/invoke/platform/data-cloud-integration/parameterized-execute-admin-setup-step-action`   — status: `proposed`
+
+**Inputs:**
+
+- `actionName` *(`String`)* — Name of the action.
+- `params` *(`Map<String, String>`)* — Value for params.
+
+**Depends on:** `get-admin-setup-data`
+
+**Output:** AdminSetupStepActionResultRepresentation: result (boolean — true on executor success; thrown exceptions become AuraHandledException), error (ErrorRepresentation on recoverable failure), custom (executor-bean-defined string-keyed output map — populated by the parameterized executor, distinct from the no-args variant which leaves it null).
+
+**Notes:** executor_allowlist_risk: This is a generic dispatcher that executes an AdminSetupStepActionExecutor Spring bean by caller-supplied actionName. Safe today because every action in FundraisingIntelligenceSetup.json is ButtonNavigate/Manual/LaunchComponent — no action currently maps to a mutating install/authorize bean. Recommend an explicit allowlist of executable action names; re-review if the setupConfig ever registers an executor-backed install/authorize action.; access_guard_gap: Unlike its sibling execute-admin-setup-step-action, this method carries no controller-level View Setup access guard of its own. It relies entirely on the setupConfig's per-step stepAccessCheck for access control. Not a rejection reason — no mutating bean is wired today — but flagged as a latent risk to revisit if that changes.