@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/industries-cds-general-settings-configure/SKILL.md

@@ -1,69 +0,0 @@
----
-name: industries-cds-general-settings-configure
-description: "Use this skill when users want to compliant Data Sharing (CDS) general settings: read or change the org-wide policy for what happens when a Salesforce user who holds CDS participant records, or belongs to a CDS participant group, is deactivated. Trigger when users mention cdsgeneral, settings, cdsgeneral settings."
-metadata:
-  version: "1.0"
----
-
-# Managing Cds General Settings
-
-## When to Use This Skill
-
-Compliant Data Sharing (CDS) general settings: read or change the org-wide policy for what happens when a Salesforce user who holds CDS participant records, or belongs to a CDS participant group, is deactivated. Either block the user deactivation until that participant access is removed, or allow it and have the user's participant records deactivated automatically. This is the CDS user-offboarding policy; sibling CDS setup pages cover object enablement, participant roles, and participant groups.
-
-## Workflow
-
-This page exposes one org-wide preference plus a retry hook.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org has IndustriesCompliantDataSharing enabled (OrgPermissions.CompliantDataSharing). Parent gate for the entire CDS setup tree — without it the setup node is not visible. (check: `Compliant Data Sharing enabled`)
-- Caller has UserPermissions.ConfigCompliantDataSharing + UserPermissions.ViewSetup, OR is sysadmin (CustomizeApplication + ModifyAllData). Per-method @ServiceComponentAccessGuard on every controller method. (check: `Compliant Data Sharing config access`)
-- Class-level @ServiceComponentAccessGuard layered before per-method gate — userHasIndustriesConfigCompliantDataSharing AND (ViewSetup OR sysadmin). Applied on every method dispatched into this controller. (check: `Manage Object Enablement Settings`)
-- Compliant Data Sharing must be enabled for at least one object (Setup > Compliant Data Sharing > Object Enablement Settings) before the user-deactivation preference has any effect. Without it the preference is still readable and writable, but no deactivation is ever refused, so a successful write changes nothing observable. (check: `Compliant Data Sharing enabled for at least one object`)
-- The participant-group half of the deactivation block - refusing to deactivate a user because they belong to a participant group - additionally requires the Groups org permission. Without it, only participant records are checked. (check: `Groups org permission for participant-group checks`)
-- Choosing SetParticipantRecordsToInactiveOnDeactivateUser requires the admin who later performs the user deactivation to hold EDIT field-level security on the IsActive field of every participant entity. Verified against a live org: this is granted by neither the System Administrator profile nor the FSC Sales permission set and must be added explicitly. Without it the deactivation is refused with "you don't have permission to update field IsActive of <entity>", which resembles the participant-record block but has a different cause and fix. (check: `Edit field-level security on participant IsActive`)
-
-**Operational rules:**
-
-- THE PREFERENCE has two values, and the option labels an admin sees in the UI are easy to misread, so rely on this description instead. PreventDeactivateUserWithParticipantRecords (the default) BLOCKS user deactivation: if the user holds any participant record, or belongs to any participant group, the deactivation is refused and the error points at the offending record or group. Nothing is deleted; the admin must remove the participant records and group memberships first, then deactivate. SetParticipantRecordsToInactiveOnDeactivateUser ALLOWS the deactivation and then deactivates that user's participant records automatically in an asynchronous follow-up job.
-- INERT UNLESS ENABLED PER OBJECT. The blocking behavior only engages when Compliant Data Sharing is turned on for at least one object. On an org where no object has it enabled, this preference can be written and read back successfully while changing nothing observable. Do not report a successful write as a behavior change without confirming object enablement. The participant-group half of the block additionally requires the Groups org permission.
-- ORDERING. Read the current value first; the read operation stands alone and does not require a prior write. Write, then read back to confirm the new value persisted.
-- HUMAN GATE THE API SKIPS. In the UI, changing this preference raises an "Are you sure you want to change the user deactivation behavior?" confirmation that the admin must accept. That gate is client-side only, so an API write applies immediately with no confirmation. Surface the consequence to the user and get their intent before writing.
-- WITHDRAWN OPERATION - DO NOT OFFER IT. The controller behind this page also exposes a bulk participant-record deactivation call, intended as the retry path for a failed asynchronous cleanup job. It is withdrawn and not callable here, because it fails with HTTP 500 on every invocation and the product's own admin retry link fails identically. Do not describe it as available, and do not offer to retry a failed cleanup from this page - there is currently no supported way to do that.
-- ERROR CONTRACT. The preference write returns HTTP 500 for input that is permanently wrong rather than a 4xx: an unrecognised preference value surfaces as 500. Do not treat a 500 from this page as a transient fault worth retrying - read the message and correct the request instead. Some messages carry internal implementation text rather than admin-facing guidance, so relay their substance to the user rather than the raw string.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `update-cds-participant-record-on-deactivate-user-org-value` | write | proposed | `PATCH /headless/invoke/platform/cdsgeneral-settings/update-cdsparticipant-record-on-deactivate-user-org-value` | — |
-| `verify-update-cds-participant-record-on-deactivate-user-org-value` | read | proposed | `GET /headless/invoke/platform/cdsgeneral-settings/get-cdsparticipant-record-on-deactivate-user-org-value` | — |
-
-### Read operations
-
-#### `verify-update-cds-participant-record-on-deactivate-user-org-value`
-
-Read the current org-wide user-deactivation behavior for Compliant Data Sharing participant records. Returns one of PreventDeactivateUserWithParticipantRecords (the default) or SetParticipantRecordsToInactiveOnDeactivateUser. Safe to call on its own as a baseline read before changing the setting, and again afterwards to confirm the new value persisted - it takes no inputs and has no prerequisite step.
-
-**Call:** `GET /headless/invoke/platform/cdsgeneral-settings/get-cdsparticipant-record-on-deactivate-user-org-value`   — status: `proposed`
-
-**Output:** The current value of the org-wide preference, as a string. Either PreventDeactivateUserWithParticipantRecords (the default - user deactivation is refused while the user holds participant records or belongs to a participant group) or SetParticipantRecordsToInactiveOnDeactivateUser (deactivation proceeds and the user's participant records are deactivated asynchronously).
-
-### Write operations
-
-#### `update-cds-participant-record-on-deactivate-user-org-value`
-
-Set the org-wide user-deactivation behavior for Compliant Data Sharing participant records. Accepts PreventDeactivateUserWithParticipantRecords (refuse to deactivate a user who holds participant records or belongs to a participant group) or SetParticipantRecordsToInactiveOnDeactivateUser (allow the deactivation and deactivate that user's participant records via an asynchronous follow-up job). Echoes the saved value back. The setting takes effect only on orgs where Compliant Data Sharing is enabled for at least one object. In the UI this change is gated behind a confirmation dialog that this API call does not apply.
-
-**Call:** `PATCH /headless/invoke/platform/cdsgeneral-settings/update-cdsparticipant-record-on-deactivate-user-org-value`   — status: `proposed`
-
-**Inputs:**
-
-- `selectedValue` *(`String`)* — Value for the selected value field.

package/skills/industries-claim-financial-settings-configure/SKILL.md

@@ -1,169 +0,0 @@
----
-name: industries-claim-financial-settings-configure
-description: "Use this skill when users want to manage ClaimFinancialSettings records (FSC Insurance Claim Management settings; keyPrefix 11Z) via sObject REST CRUD. Trigger when users mention claim, financial, settings, claim financial settings."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesPolicyadmin.orgHasInsurancePolicyAdministrationPref || IndustriesPolicyadmin.orgHasInsuranceClaimMgmtPref"
----
-
-# Managing Claim Financial Settings
-
-## When to Use This Skill
-
-Manage ClaimFinancialSettings records (FSC Insurance Claim Management settings; keyPrefix 11Z) via sObject REST CRUD. Singleton entity — at most ONE record per org; a second POST returns 400 FIELD_INTEGRITY_EXCEPTION "You can't create more than one Claim Financial Settings record." An admin's canonical workflow is therefore configure-or-reconfigure the single row, not fan-out create. Three required TEXT(255) status fields define the row — ClaimCovPendingAuthStatus, ClmCovPymtDtlPendAuthSts, ClaimPendingAuthorityStatus — plus standard MasterLabel, DeveloperName, Language (restricted picklist; invalid values return 400 INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST). DeveloperName provided on create is server-normalized (the platform assigns a canonical value derived from MasterLabel; do not depend on the caller-supplied DeveloperName round-tripping). Identity by Id for ad-hoc edits; upsert by DeveloperName is available but has limited utility given the singleton constraint. For source-controlled rollout, deploy via Metadata API (api_type metadata_api, POST /headless/metadata); Metadata READ is NOT supported (GET /headless/metadata for this type returns 400 UNSUPPORTED_OPERATION — read the row via sObject GET instead). No Aura controller exists; sObject REST, Tooling REST, and Metadata API deploy are the entire programmatic surface — pick by intent (CRUD / introspection / source-controlled deploy).
-
-## Workflow
-
-Standard sObject REST provides full CRUD + describe on ClaimFinancialSettings; no proprietary Aura controller is involved. Fields available at runtime come from /describe — the SOR doesn't enumerate them statically because the shape depends on the org's permission/profile setup. Run /describe first, then construct the payload from the createable fields list.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User needs CRUD access to ClaimFinancialSettings. (check: `<udd:crud:ClaimFinancialSettings>`)
-- Org has Insurance Claim Management or Insurance Policy Administration enabled — without one the entity is non-addressable and the setup node is hidden. (check: `Insurance Policy Administration enabled || Insurance Claim Management enabled`)
-- Running user holds Insurance Policy Admin or Insurance Claim Management user access — gates UI + API CRUD on the entity. (check: `Insurance Policy Admin access || Insurance Claim Management access`)
-- User needs access to manage ClaimFinancialSettings (CRUD on the ClaimFinancialSettings sObject). (check: `Insurance Policy Administration enabled || Insurance Claim Management enabled`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `describe` | read | — | `GET /services/data/v67.0/sobjects/ClaimFinancialSettings/describe` | — |
-| `list` | read | — | `GET /services/data/v67.0/query` | `describe` |
-| `get-by-id` | read | — | `GET /services/data/v67.0/sobjects/ClaimFinancialSettings/{Id}` | `list` |
-| `create` | write | — | `POST /services/data/v67.0/sobjects/ClaimFinancialSettings` | `describe` |
-| `update` | write | — | `PATCH /services/data/v67.0/sobjects/ClaimFinancialSettings/{Id}` | `get-by-id` |
-| `delete` | write | — | `DELETE /services/data/v67.0/sobjects/ClaimFinancialSettings/{Id}` | `get-by-id` |
-| `write-claim-financial-settings-via-metadata` | write | — | `POST /headless/metadata` | — |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  describe["describe (read)"]
-  list["list (read)"]
-  get_by_id["get-by-id (read)"]
-  create["create (write)"]
-  update["update (write)"]
-  delete["delete (write)"]
-  write_claim_financial_settings_via_metadata["write-claim-financial-settings-via-metadata (write)"]
-  describe --> list
-  list --> get_by_id
-  describe --> create
-  get_by_id --> update
-  get_by_id --> delete
-```
-
-### Read operations
-
-#### `describe`
-
-Returns DescribeSObjectResult — 3 required TEXT(255) status fields plus MasterLabel/DeveloperName/Language, FLS, createable/updateable. Field shape is statically known from UDD; describe verifies per-user FLS before write-payload construction.
-
-**Call:** `GET /services/data/v67.0/sobjects/ClaimFinancialSettings/describe`
-
-**Output:** DescribeSObjectResult — fields[] includes ClaimCovPendingAuthStatus, ClmCovPymtDtlPendAuthSts, ClaimPendingAuthorityStatus (each TEXT(255), nillable=false) plus MasterLabel, DeveloperName, Language and standard audit fields (CreatedBy/Date, LastModifiedBy/Date, SystemModstamp). recordTypeInfos and childRelationships are empty (no master-detail children).
-
-#### `list`
-
-SOQL list of ClaimFinancialSettings rows. UDD defaultFilterColumns are MasterLabel, ClaimCovPendingAuthStatus, ClmCovPymtDtlPendAuthSts, ClaimPendingAuthorityStatus — project these for setup-page-equivalent display.
-
-**Call:** `GET /services/data/v67.0/query`
-
-**Inputs:**
-
-- `where` *(`String`)* — Optional SOQL WHERE clause to filter Claim Financial Settings records.
-- `limit` *(`int`)* — Optional SOQL LIMIT value.
-- `q` *(`string`)*
-
-**Depends on:** `describe`
-
-**Output:** QueryResult — records[] of ClaimFinancialSettings (Id + each SELECTed field), totalSize, done, nextRecordsUrl when paginated. Empty records[] when no rows exist (an unconfigured org returns 0 settings records by default).
-
-#### `get-by-id`
-
-Retrieve a specific ClaimFinancialSettings record by Id.
-
-**Call:** `GET /services/data/v67.0/sobjects/ClaimFinancialSettings/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ClaimFinancialSettings record to fetch.
-
-**Depends on:** `list`
-
-**Output:** Single ClaimFinancialSettings record with all readable fields per user FLS.
-
-### Write operations
-
-#### `create`
-
-Create a new ClaimFinancialSettings record. Run /describe first to learn the required + createable fields.
-
-**Call:** `POST /services/data/v67.0/sobjects/ClaimFinancialSettings`
-
-**Inputs:**
-
-- `body` *(`object`)* — Field/value map for the new ClaimFinancialSettings. Populate from /describe's createableFields list.
-
-**Depends on:** `describe`
-
-**Output:** SaveResult — id (15/18-char Id, keyPrefix 11Z), success (true on 201), errors[] (empty on success). Subsequent retrieve / update / delete keyed on the returned id.
-
-**Rollback:** Call delete with the returned Id to undo the create.
-
-**Notes:** singleton_constraint: Only ONE ClaimFinancialSettings record allowed per org. A second POST returns 400 FIELD_INTEGRITY_EXCEPTION "You can't create more than one Claim Financial Settings record." Query first (list step, LIMIT 1) — if a row exists, use update instead of create.; developer_name_normalization: DeveloperName supplied in the request body is NOT preserved verbatim. The platform assigns a canonical DeveloperName derived from MasterLabel (verified: request "B4Expertise_retry2_create" was returned as "Claim_Financial_Settings"). Downstream lookups by DeveloperName must use the server-assigned value from the GET-after-create, not the caller-supplied value.
-
-#### `update`
-
-Update an existing ClaimFinancialSettings record. Merge-patch semantics.
-
-**Call:** `PATCH /services/data/v67.0/sobjects/ClaimFinancialSettings/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ClaimFinancialSettings to update.
-- `body` *(`object`)* — Partial field/value map — only include fields you want to change.
-
-**Depends on:** `get-by-id`
-
-**Output:** Empty 204 No Content on success. Errors return SaveError shape (statusCode, message, fields[]).
-
-**Rollback:** Re-PATCH with the prior field values (capture them via get-by-id before update). PATCH is idempotent at the wire layer but not at the value layer — the rollback must replay the prior values explicitly.
-
-**Notes:** merge_semantics: PATCH is partial-update (merge) — omitted fields are preserved. Confirmed via probe: PATCH {MasterLabel, Language} kept the 3 status fields unchanged in the subsequent GET.; enum_error_shape: Invalid Language value returns 400 INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST with message "Master Language: bad value for restricted picklist field: <value>". Query /describe fields[?name=Language].picklistValues[] for the accepted locale set.
-
-#### `delete`
-
-Delete a ClaimFinancialSettings record.
-
-**Call:** `DELETE /services/data/v67.0/sobjects/ClaimFinancialSettings/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ClaimFinancialSettings to delete.
-
-**Depends on:** `get-by-id`
-
-**Output:** Empty 204 No Content on success. 404 ENTITY_IS_DELETED when the row was already deleted; 400 if the user lacks delete access (per UDD deleteAccess gate).
-
-#### `write-claim-financial-settings-via-metadata`
-
-Deploy ClaimFinancialSettings members via Metadata API — the source-controlled rollout path. Use for FSC release bundles rather than ad-hoc CRUD; transport routes via /headless/metadata.
-
-**Call:** `POST /headless/metadata`
-
-**Inputs:**
-
-- `package` *(`object`)* — Metadata API package containing one or more ClaimFinancialSettings members keyed on fullName (=DeveloperName). Each member carries masterLabel + the 3 required status fields. destructiveChanges.xml may list fullNames to delete.
-
-**Output:** DeployResult — id (AsyncResult), state (Pending|InProgress|Succeeded|SucceededPartial|Failed), details (componentSuccesses[] / componentFailures[] per fullName).
-
-**Rollback:** Re-deploy with the prior package state, or attach destructiveChanges.xml listing the new fullNames to remove.
-
-**Notes:** read_unsupported: The Metadata API supports POST/PUT deploy for ClaimFinancialSettings but does NOT support READ. GET /headless/metadata?type=ClaimFinancialSettings&fullName=... returns 400 UNSUPPORTED_OPERATION "MetadataCrud does not support READ on type: ClaimFinancialSettings". Read the current row via sObject GET (steps get-by-id or list) before crafting a deploy package.

package/skills/industries-clinical-data-model-settings-configure/SKILL.md

@@ -1,136 +0,0 @@
----
-name: industries-clinical-data-model-settings-configure
-description: "Use this skill when users want to manages two Health Cloud org preferences via the Clinical Data Settings setup page: ORG_PREFERENCE_CLINICAL_DATA_MODEL (clinical data model) and ORG_PREFERENCE_ADVERSE_EVENTS (adverse event data model). Trigger when users mention clinical, data, model, settings, clinical data model settings."
-metadata:
-  version: "1.0"
-  accessCheck: "(HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD || HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD_STARTER) || (IndustriesLifeSciencesUddSettingAccessCheck.ORG_PERMISSION_ADVERSE_EVENTS)"
----
-
-# Managing Clinical Data Model Settings
-
-## When to Use This Skill
-
-Manages two Health Cloud org preferences via the Clinical Data Settings setup page: ORG_PREFERENCE_CLINICAL_DATA_MODEL (clinical data model) and ORG_PREFERENCE_ADVERSE_EVENTS (adverse event data model). All four operations route through the platform Aura controller (exposed via /headless/invoke/platform/clinical-data-model-settings/*). The page reads each preference's current boolean state and toggles each independently. Writes require an org licensed for Health Cloud OR Health Cloud Starter plus Customize Application/SysAdmin; the adverse-event toggle additionally requires the ORG_PERMISSION_ADVERSE_EVENTS feature flag. Enabling the clinical-data-model preference emits a LifeSciences telemetry event (CLINICAL_DM, clinicalDataModel.enabled). The HC Starter license variant lives in sibling SOR ClinicalDataModelSettingsStarter.
-
-## Workflow
-
-Two independent prefs, no inter-pref ordering. To inspect: call get-clinical-data-model-org-pref and get-adverse-event-data-model-org-pref. To change either: call its toggle write, then its verify read-back. License (HC|HC-Starter) + Customize Application/SysAdmin required for all writes.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must hold Customize Application OR System Administrator (Customize Application permission); required by both writes and the adverse-event read. (check: `Customize Application permission`)
-- Org must be licensed for Health Cloud OR Health Cloud Starter; both writes throw NoAccessException when neither license is present (controller checkAccessAndThrowException, lines 75-79). The HC Starter license variant has its own SOR (ClinicalDataModelSettingsStarter). (check: `HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD || HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD_STARTER`)
-- Toggling the Adverse Event Data Model preference additionally requires the ORG_PERMISSION_ADVERSE_EVENTS feature flag enabled in the org. Does NOT affect the clinical-data-model toggle (controller checkAdverseEventAccessAndThrowException, lines 84-90). (check: `IndustriesLifeSciencesUddSettingAccessCheck.ORG_PERMISSION_ADVERSE_EVENTS`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `toggle-clinical-data-model-pref`: call `verify-toggle-clinical-data-model-pref` (`GET /headless/invoke/platform/clinical-data-model-settings`)
-- After `toggle-adverse-model-pref`: call `verify-toggle-adverse-model-pref` (`GET /headless/invoke/platform/clinical-data-model-settings/get-adverse-event-data-model-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 |
-|-----------|---------|--------|------|------------|
-| `get-clinical-data-model-org-pref` | read | proposed | `GET /headless/invoke/platform/clinical-data-model-settings` | — |
-| `get-adverse-event-data-model-org-pref` | read | proposed | `GET /headless/invoke/platform/clinical-data-model-settings/get-adverse-event-data-model-org-pref` | — |
-| `toggle-clinical-data-model-pref` | write | proposed | `PATCH /headless/invoke/platform/clinical-data-model-settings/handle-clinical-data-model-pref-toggle` | — |
-| `verify-toggle-clinical-data-model-pref` | verify | — | `GET /headless/invoke/platform/clinical-data-model-settings` | `toggle-clinical-data-model-pref` |
-| `toggle-adverse-model-pref` | write | proposed | `PATCH /headless/invoke/platform/clinical-data-model-settings/handle-adverse-model-pref-toggle` | — |
-| `verify-toggle-adverse-model-pref` | verify | — | `GET /headless/invoke/platform/clinical-data-model-settings/get-adverse-event-data-model-org-pref` | `toggle-adverse-model-pref` |
-
-### Read operations
-
-#### `get-clinical-data-model-org-pref`
-
-Returns boolean — whether ORG_PREFERENCE_CLINICAL_DATA_MODEL is enabled org-wide. No access guard on this read; any authenticated caller can observe the state.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings`   — status: `proposed`
-
-**Output:** boolean — true when ORG_PREFERENCE_CLINICAL_DATA_MODEL is enabled in the org; false otherwise.
-
-#### `get-adverse-event-data-model-org-pref`
-
-Returns boolean — whether ORG_PREFERENCE_ADVERSE_EVENTS is enabled org-wide. Gated by Customize Application permission; no license check on this read.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings/get-adverse-event-data-model-org-pref`   — status: `proposed`
-
-**Output:** boolean — true when ORG_PREFERENCE_ADVERSE_EVENTS is enabled in the org; false otherwise.
-
-### Write operations
-
-#### `toggle-clinical-data-model-pref`
-
-Persists the new boolean state of ORG_PREFERENCE_CLINICAL_DATA_MODEL. Void return on success; throws NoAccessException without HC|HC-Starter license + Customize Application/SysAdmin. Enable emits a LifeSciences telemetry event (CLINICAL_DM, clinicalDataModel.enabled).
-
-**Call:** `PATCH /headless/invoke/platform/clinical-data-model-settings/handle-clinical-data-model-pref-toggle`   — status: `proposed`
-
-**Inputs:**
-
-- `value` *(`boolean`)* — Desired boolean state of ORG_PREFERENCE_CLINICAL_DATA_MODEL. Send
-strict JSON boolean `true` to enable, `false` to disable. The
-dispatcher applies Boolean.parseBoolean — case-insensitive string
-"true" also coerces to true; anything else coerces to false and
-silently disables the preference. Prefer the strict boolean form.
-
-**Notes:** error_contracts: {'wrong_verb': 'PATCH is the only accepted verb on this endpoint. POST / PUT / DELETE\nreturn 404 NOT_FOUND from the dispatcher. Do not attempt a POST create.', 'silent_coercion': 'The controller uses a Java primitive boolean binding — the dispatcher\ncalls Boolean.parseBoolean on the JSON value. Case-insensitive string\n"true" / "TRUE" IS coerced to true (verified iter 2: PATCH `{"value":\n"true"}` from a false state produced a true read-back). Every other\nshape — missing value key (empty {}), numeric 0/1, null, or any other\nstring — coerces to false and DISABLES the preference. Always send\nstrict JSON `{"value": true}` or `{"value": false}` to avoid ambiguity.\nChain the paired read to confirm the applied value.', 'extra_fields': 'Extra top-level fields in the body are silently ignored. Safe but\nnot useful — no schema validation error is raised.'}; response_shape: Successful PATCH returns HTTP 200 with an empty JSON object {}. The
-response does not echo the applied value. To confirm the write took
-effect, chain the verify-toggle-clinical-data-model-pref read step.; side_effects: Enabling this preference emits a LifeSciences telemetry event
-(CLINICAL_DM, clinicalDataModel.enabled). Repeated enable calls emit
-repeated telemetry — prefer idempotent gating by reading first.
-
-#### `toggle-adverse-model-pref`
-
-Persists the new boolean state of ORG_PREFERENCE_ADVERSE_EVENTS. Void return on success; throws NoAccessException without HC|HC-Starter license + ORG_PERMISSION_ADVERSE_EVENTS feature flag + Customize Application/SysAdmin. No telemetry side-effect.
-
-**Call:** `PATCH /headless/invoke/platform/clinical-data-model-settings/handle-adverse-model-pref-toggle`   — status: `proposed`
-
-**Inputs:**
-
-- `value` *(`boolean`)* — Desired boolean state of ORG_PREFERENCE_ADVERSE_EVENTS. Send strict
-JSON boolean `true` to enable, `false` to disable. The dispatcher
-applies Boolean.parseBoolean — case-insensitive string "true" also
-coerces to true; anything else coerces to false and silently disables
-the preference.
-
-**Notes:** error_contracts: {'wrong_verb': 'PATCH is the only accepted verb on this endpoint. POST / PUT / DELETE\nreturn 404 NOT_FOUND from the dispatcher.', 'silent_coercion': 'The controller uses a Java primitive boolean binding — the dispatcher\ncalls Boolean.parseBoolean on the JSON value. Case-insensitive string\n"true" / "TRUE" IS coerced to true. Every other shape — missing value\nkey (empty {}), numeric 0/1, null, or any other string — coerces to\nfalse and DISABLES the preference. Always send strict JSON\n`{"value": true}` or `{"value": false}` to avoid ambiguity. Chain the\npaired read (get-adverse-event-data-model-org-pref) to confirm the\napplied value.', 'extra_fields': 'Extra top-level fields in the body are silently ignored.'}; response_shape: Successful PATCH returns HTTP 200 with an empty JSON object {}. The
-response does not echo the applied value. Chain the paired
-verify-toggle-adverse-model-pref read step to confirm.; independence: This preference is fully independent of ORG_PREFERENCE_CLINICAL_DATA_MODEL.
-Toggling adverse-events does not affect the clinical-data-model state
-and vice versa; the two toggles can be issued in either order.
-
-### Verify operations
-
-#### `verify-toggle-clinical-data-model-pref`
-
-Verify the effect of toggle-clinical-data-model-pref: read back the current value via the companion read to confirm the write took effect.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings`
-
-**Depends on:** `toggle-clinical-data-model-pref`
-
-**Output:** Boolean read-back of ORG_PREFERENCE_CLINICAL_DATA_MODEL. Should
-match the value just written by toggle-clinical-data-model-pref;
-any mismatch means the write did not take effect (typically the
-body was silently coerced — see the paired toggle step's
-error_contracts.silent_coercion).
-
-#### `verify-toggle-adverse-model-pref`
-
-Verify the effect of toggle-adverse-model-pref by reading back via getAdverseEventDataModelOrgPref; the read returns the same ORG_PREFERENCE_ADVERSE_EVENTS the toggle just set.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings/get-adverse-event-data-model-org-pref`
-
-**Depends on:** `toggle-adverse-model-pref`
-
-**Output:** Boolean read-back of ORG_PREFERENCE_ADVERSE_EVENTS. Should match the
-value just written by toggle-adverse-model-pref; a mismatch means the
-write coerced (see the paired toggle step's
-error_contracts.silent_coercion).

package/skills/industries-clinical-data-model-settings-starter-configure/SKILL.md

@@ -1,105 +0,0 @@
----
-name: industries-clinical-data-model-settings-starter-configure
-description: "Use this skill when users want to manages two Health Cloud org preferences via the Clinical Data Model Settings Starter setup page (HC-Starter license variant of sibling SOR ClinicalDataModelSettings): ORG_PREFERENCE_CLINICAL_DATA_MODEL (clinical data model) and ORG_PREFERENCE_ADVERSE_EVENTS (adverse event data m. Trigger when users mention clinical, data, model, settings, starter, clinical data model settings starter."
-metadata:
-  version: "1.0"
-  accessCheck: "(HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD || HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD_STARTER) || (IndustriesLifeSciencesUddSettingAccessCheck.ORG_PERMISSION_ADVERSE_EVENTS)"
----
-
-# Managing Clinical Data Model Settings Starter
-
-## When to Use This Skill
-
-Manages two Health Cloud org preferences via the Clinical Data Model Settings Starter setup page (HC-Starter license variant of sibling SOR ClinicalDataModelSettings): ORG_PREFERENCE_CLINICAL_DATA_MODEL (clinical data model) and ORG_PREFERENCE_ADVERSE_EVENTS (adverse event data model). All four operations route through /headless/invoke/platform/clinical-data-model-settings-starter/* — same backing endpoint as the non-Starter SOR; the URL prefix differentiates the setup-tree node. Reads return each pref's current boolean state; writes toggle each independently. Writes require an org licensed for Health Cloud OR Health Cloud Starter plus Customize Application/SysAdmin; the adverse-event toggle additionally requires the ORG_PERMISSION_ADVERSE_EVENTS feature flag. Enabling the clinical-data-model preference emits a LifeSciences telemetry event (CLINICAL_DM, clinicalDataModel.enabled).
-
-## Workflow
-
-Two independent prefs, no inter-pref ordering. To inspect: call get-clinical-data-model-org-pref and get-adverse-event-data-model-org-pref. To change either: call its handle-*-toggle write, then its verify read-back. License (HC|HC-Starter) + Customize Application/SysAdmin required for all writes; the adverse-event write additionally requires ORG_PERMISSION_ADVERSE_EVENTS.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must hold Customize Application OR System Administrator (Customize Application permission); required by both writes and the adverse-event read. (check: `Customize Application permission`)
-- Org must be licensed for Health Cloud OR Health Cloud Starter; both writes throw NoAccessException via checkAccessAndThrowException when neither license is present. The non-Starter setup-page variant (ClinicalDataModelSettings) lives in a sibling SOR backed by the same controller. (check: `HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD || HealthCloudAccessCheck.ORG_HAS_HEALTH_CLOUD_STARTER`)
-- The Adverse Event Data Model toggle additionally requires the ORG_PERMISSION_ADVERSE_EVENTS feature flag enabled in the org (controller checkAdverseEventAccessAndThrowException). Does NOT affect the clinical-data-model toggle. (check: `IndustriesLifeSciencesUddSettingAccessCheck.ORG_PERMISSION_ADVERSE_EVENTS`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `handle-clinical-data-model-pref-toggle`: call `verify-handle-clinical-data-model-pref-toggle` (`GET /headless/invoke/platform/clinical-data-model-settings-starter`)
-- After `handle-adverse-model-pref-toggle`: call `verify-handle-adverse-model-pref-toggle` (`GET /headless/invoke/platform/clinical-data-model-settings-starter/get-adverse-event-data-model-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 |
-|-----------|---------|--------|------|------------|
-| `get-clinical-data-model-org-pref` | read | proposed | `GET /headless/invoke/platform/clinical-data-model-settings-starter` | — |
-| `get-adverse-event-data-model-org-pref` | read | proposed | `GET /headless/invoke/platform/clinical-data-model-settings-starter/get-adverse-event-data-model-org-pref` | — |
-| `handle-clinical-data-model-pref-toggle` | write | proposed | `PATCH /headless/invoke/platform/clinical-data-model-settings-starter/handle-clinical-data-model-pref-toggle` | — |
-| `verify-handle-clinical-data-model-pref-toggle` | verify | — | `GET /headless/invoke/platform/clinical-data-model-settings-starter` | `handle-clinical-data-model-pref-toggle` |
-| `handle-adverse-model-pref-toggle` | write | proposed | `PATCH /headless/invoke/platform/clinical-data-model-settings-starter/handle-adverse-model-pref-toggle` | — |
-| `verify-handle-adverse-model-pref-toggle` | verify | — | `GET /headless/invoke/platform/clinical-data-model-settings-starter/get-adverse-event-data-model-org-pref` | `handle-adverse-model-pref-toggle` |
-
-### Read operations
-
-#### `get-clinical-data-model-org-pref`
-
-Returns boolean — whether ORG_PREFERENCE_CLINICAL_DATA_MODEL is enabled org-wide. No access guard on this read; any authenticated caller can observe the state.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings-starter`   — status: `proposed`
-
-**Output:** boolean — true when ORG_PREFERENCE_CLINICAL_DATA_MODEL is enabled in the org; false otherwise.
-
-#### `get-adverse-event-data-model-org-pref`
-
-Returns boolean — whether ORG_PREFERENCE_ADVERSE_EVENTS is enabled org-wide. Gated by Customize Application permission; no license check on this read.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings-starter/get-adverse-event-data-model-org-pref`   — status: `proposed`
-
-**Output:** boolean — true when ORG_PREFERENCE_ADVERSE_EVENTS (IndustriesLifeSciencesUddSettingAccessCheck.ORG_PREFERENCE_ADVERSE_EVENTS) is enabled in the org; false otherwise.
-
-### Write operations
-
-#### `handle-clinical-data-model-pref-toggle`
-
-Persists the new boolean state of ORG_PREFERENCE_CLINICAL_DATA_MODEL. Void return on success; throws NoAccessException without HC|HC-Starter license + Customize Application/SysAdmin. Enable (value=true) emits a LifeSciences telemetry event (CLINICAL_DM, clinicalDataModel.enabled).
-
-**Call:** `PATCH /headless/invoke/platform/clinical-data-model-settings-starter/handle-clinical-data-model-pref-toggle`   — status: `proposed`
-
-**Inputs:**
-
-- `value` *(`boolean`)* — Toggle the value preference on or off.
-
-#### `handle-adverse-model-pref-toggle`
-
-Persists the new boolean state of ORG_PREFERENCE_ADVERSE_EVENTS. Void return on success; throws NoAccessException without HC|HC-Starter license + ORG_PERMISSION_ADVERSE_EVENTS feature flag + Customize Application/SysAdmin. No telemetry side-effect.
-
-**Call:** `PATCH /headless/invoke/platform/clinical-data-model-settings-starter/handle-adverse-model-pref-toggle`   — status: `proposed`
-
-**Inputs:**
-
-- `value` *(`boolean`)* — Toggle the value preference on or off.
-
-### Verify operations
-
-#### `verify-handle-clinical-data-model-pref-toggle`
-
-Verify the effect of handle-clinical-data-model-pref-toggle: read back the current value via the companion read to confirm the write took effect.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings-starter`
-
-**Depends on:** `handle-clinical-data-model-pref-toggle`
-
-#### `verify-handle-adverse-model-pref-toggle`
-
-Verify the effect of handle-adverse-model-pref-toggle by reading back via getAdverseEventDataModelOrgPref; the read returns the same ORG_PREFERENCE_ADVERSE_EVENTS the toggle just set.
-
-**Call:** `GET /headless/invoke/platform/clinical-data-model-settings-starter/get-adverse-event-data-model-org-pref`
-
-**Depends on:** `handle-adverse-model-pref-toggle`

package/skills/industries-collection-plan-settings-configure/SKILL.md

@@ -1,132 +0,0 @@
----
-name: industries-collection-plan-settings-configure
-description: "Use this skill when users want to configure org-level FSC Collection Plan preferences and the Promise-to-Pay (PTP) count. Trigger when users mention collection, plan, settings, collection plan settings."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesCollectionAccessCheck.ORG_HAS_COLLECTION"
----
-
-# Managing Collection Plan Settings
-
-## When to Use This Skill
-
-Configure org-level FSC Collection Plan preferences and the Promise-to-Pay (PTP) count. Toggles one of six Collection preferences by exact string id: CollectionContactCardPref, CollectionTimeline, CollectionRiskScoringCFE, CollectionDbBasedOps, CollectionAsaAgentPref, CollDialerCampaignPref; passing an unrecognized id is rejected. PTP writes (save-promise-count, save-promise-count-with-change-info) set the org-wide Promise-to-Pay count setting; the with-change-info variant returns {success, isChanged} for the confirmation-modal flow. Reads: get-access-check-values (six per-preference enablement booleans + userHasAccess / userHasCPAgentAccess / userHasCPASAAgentAccess role gates), get-ptp-value (current count, 0 when unset), can-enable-collections-agent-data-cloud-pref (composite probe — true only when CDP/Genie is provisioned AND five DMOs exist; required before turning on CollectionAsaAgentPref). All ops are gated by setup-admin access and the org's FSC Collections-feature provisioning check.
-
-## Workflow
-
-Read-then-write. Call get-access-check-values first to confirm userHasAccess and current Is*Enabled state. Before enabling CollectionAsaAgentPref, call can-enable-collections-agent-data-cloud-pref and require brwrCntctPref:true. After every write, run the corresponding verify step.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have IndustriesCollection AccessToCollectionIsAdmin access (admin Customize Application). (check: `Collections admin access`)
-- Org must have the FSC Collections feature provisioned. Each write is rejected when the caller is not a setup admin or the Collections feature isn't provisioned. (check: `the org's FSC Collections-feature provisioning check`)
-- Before calling handle-pref-enable with pref=CollectionAsaAgentPref and value=true, call can-enable-collections-agent-data-cloud-pref and require brwrCntctPref=true (CDP or Genie provisioned AND all 5 DMOs resolve). Verified live against a test org during factory-review: handlePrefEnable does NOT enforce this gate server-side — it accepts and persists the toggle even when brwrCntctPref is false. This precondition is UI-only; an agent MUST check it before writing this specific pref. (check: `Data Cloud eligibility before enabling CollectionAsaAgentPref`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `save-promise-count`: call `verify-save-promise-count` (`GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue`)
-- After `save-promise-count-with-change-info`: call `verify-save-promise-count-with-change-info` (`GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `handle-pref-enable` | write | implemented | `PATCH /headless/invoke/platform/collection-plan-settings/handle-pref-enable` | — |
-| `get-access-check-values` | read | implemented | `GET /headless/invoke/platform/collection-plan-settings` | — |
-| `save-promise-count-with-change-info` | write | implemented | `PATCH /headless/invoke/platform/collection-plan-settings/save-promise-count-with-change-info` | — |
-| `save-promise-count` | write | implemented | `PATCH /headless/invoke/platform/collection-plan-settings/save-promise-count` | — |
-| `can-enable-collections-agent-data-cloud-pref` | read | implemented | `GET /headless/invoke/platform/collection-plan-settings/can-enable-collections-agent-data-cloud-pref` | — |
-| `get-ptp-value` | read | implemented | `GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue` | — |
-| `verify-save-promise-count` | verify | implemented | `GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue` | `save-promise-count` |
-| `verify-save-promise-count-with-change-info` | verify | implemented | `GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue` | `save-promise-count-with-change-info` |
-
-### Read operations
-
-#### `get-access-check-values`
-
-Read six Is*Enabled pref flags (IsCollectionTimelineEnabled, IsCollectionRiskScoringCFEEnabled, IsCollectionDbBasedOpsEnabled, IsCollectionASAAgentEnabled, IsCollectionDialerCampaignEnabled, IsCollectionPersonAccountControlPrefEnabled) plus userHasAccess / userHasCPAgentAccess / userHasCPASAAgentAccess role gates for Setup-page toggle visibility. Aura is canonical — no public alternative.
-
-**Call:** `GET /headless/invoke/platform/collection-plan-settings`   — status: `implemented`
-
-**Output:** Map<String,Boolean> with 9 keys: 6 per-preference enablement booleans (one per Collection preference toggle) plus three role-gate booleans — userHasAccess (setup admin with Collections provisioned), userHasCPAgentAccess (setup admin with Collections-agent access provisioned), userHasCPASAAgentAccess (userHasAccess plus universal credit metering enabled).
-
-#### `can-enable-collections-agent-data-cloud-pref`
-
-Probe Data Cloud eligibility for CollectionAsaAgentPref. Returns {brwrCntctPref:<bool>}; true iff (CDP OR Genie) provisioned AND all five DMOs resolve (UnifiedLinkssotIndividualColl, Individual, ContactPointAddress, ContactPointEmail, ContactPointPhone). Required before enabling the pref. Aura is canonical — no public alternative.
-
-**Call:** `GET /headless/invoke/platform/collection-plan-settings/can-enable-collections-agent-data-cloud-pref`   — status: `implemented`
-
-**Output:** Map<String,Boolean> with single key brwrCntctPref. true when (CDP OR Genie Platform) provisioned AND all 5 DMOs (UnifiedLinkssotIndividualColl__dlm, Individual, ContactPointAddress, ContactPointEmail, ContactPointPhone) resolve via namespace-aware lookup. Drives the dCAccessForCollAgent UI gate.
-
-#### `get-ptp-value`
-
-Read the current org-wide Promise-to-Pay count setting; returns Integer, 0 when the value is unset. Aura is canonical — no Tooling/Metadata surface for this setting.
-
-**Call:** `GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue`   — status: `implemented`
-
-**Output:** Integer — current org-wide Promise-to-Pay count setting. Returns 0 when no value has been set.
-
-### Write operations
-
-#### `handle-pref-enable`
-
-Toggle one of six org prefs by exact id (CollectionContactCardPref, CollectionTimeline, CollectionRiskScoringCFE, CollectionDbBasedOps, CollectionAsaAgentPref, CollDialerCampaignPref); void return; AuraHandledException on save failure, IllegalStateException on unknown pref. Aura is canonical — no public alternative.
-
-**Call:** `PATCH /headless/invoke/platform/collection-plan-settings/handle-pref-enable`   — status: `implemented`
-
-**Inputs:**
-
-- `pref` *(`String`)* — Value for the pref field.
-- `value` *(`boolean`)* — Toggle the value preference on or off.
-
-**Output:** Empty body on success (200, void). On save-failure, AuraHandledException carries the SaveResult error message.
-
-#### `save-promise-count-with-change-info`
-
-Write the org-wide Promise-to-Pay count setting from a positive-Integer string; returns {success:true, isChanged:<bool>} where isChanged=true iff value differs from prior. Drives the confirmation-modal flow. Aura is canonical — no public alternative.
-
-**Call:** `PATCH /headless/invoke/platform/collection-plan-settings/save-promise-count-with-change-info`   — status: `implemented`
-
-**Inputs:**
-
-- `count` *(`String`)* — Value for the count field.
-
-**Output:** Map<String,Object> {success: true on persist, isChanged: true when newValue differs from prior getPTPValue, false otherwise}. ServiceException on parse-error or non-positive value.
-
-#### `save-promise-count`
-
-Write the org-wide Promise-to-Pay count setting from a positive-Integer string; returns boolean success. No change-detection — prefer save-promise-count-with-change-info when the agent must distinguish noops from real updates. Aura is canonical — no public alternative.
-
-**Call:** `PATCH /headless/invoke/platform/collection-plan-settings/save-promise-count`   — status: `implemented`
-
-**Inputs:**
-
-- `count` *(`String`)* — Value for the count field.
-
-**Output:** boolean — true on successful persist of the org-wide Promise-to-Pay count setting. ServiceException on parse-error or non-positive value.
-
-### Verify operations
-
-#### `verify-save-promise-count`
-
-Read back via getPTPValue; confirm the returned Integer equals the count just persisted by save-promise-count.
-
-**Call:** `GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue`   — status: `implemented`
-
-**Depends on:** `save-promise-count`
-
-#### `verify-save-promise-count-with-change-info`
-
-Read back via getPTPValue; confirm the returned Integer equals the count just persisted by save-promise-count-with-change-info.
-
-**Call:** `GET /headless/invoke/platform/collection-plan-settings/get-ptpvalue`   — status: `implemented`
-
-**Depends on:** `save-promise-count-with-change-info`