@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/industries-care-request-settings-configure/SKILL.md

@@ -1,218 +0,0 @@
----
-name: industries-care-request-settings-configure
-description: "Use this skill when users want to manage Care Request Configuration records, the Health Cloud Utilization Management setting that maps a care request type to a record type and the related care-request objects that request uses. Trigger when users mention care, request, settings, care request settings."
-metadata:
-  version: "1.0"
-  accessCheck: "HealthCloudUtilizationMgmt.userCanAccessOrAdminUtilMgmt"
----
-
-# Managing Care Request Settings
-
-## When to Use This Skill
-
-Manage Care Request Configuration records, the Health Cloud Utilization
-Management setting that maps a care request type to a record type and
-the related care-request objects that request uses. Covers everything the
-Care Request Settings Setup page does: list, view, create, edit,
-activate or deactivate, mark as default, and delete, via standard sObject
-REST on /services/data/v67.0/sobjects/CareRequestConfiguration. Call
-describe first for field names and the CareRequestType values (Drug
-Request, Service Request, Admission, Concurrent Review, Appeal,
-Complaint, Grievance, Referral) and CareRequestRecords values (Care
-Request Drug, Care Request Item, Care Diagnosis, Care Request Extension).
-CareRequestRecordType is effectively required: it holds the DeveloperName
-(not the Id) of a record type that must exist on BOTH CareRequest and
-Case, and on every object selected in CareRequestRecords. Otherwise the
-write fails with 400 UNKNOWN_EXCEPTION "The selected record type is not
-available for all the objects you have selected." For declarative
-deployments the Metadata API type CareRequestConfiguration (Tooling:
-/tooling/sobjects/CareRequestConfiguration) is the alternative;
-/headless/metadata does not support this type.
-
-## Workflow
-
-Order of calls: (1) describe CareRequestConfiguration for picklist values.
-(2) Confirm the record type: SELECT SobjectType FROM RecordType WHERE
-DeveloperName = '<name>' AND IsActive = true must return CareRequest and
-Case, plus each object chosen in CareRequestRecords (CareRequestDrug,
-CareRequestItem, CareDiagnosis, CareRequestExtension). If any is
-missing, the record types must be created first (Setup Object Manager or
-Metadata API RecordType; a Case record type also needs a support
-process). (3) Validate CareRequestType against the describe picklist
-values yourself: the platform stores any string, including unknown
-values, without error, and it does not require the field. (4) Defaults:
-the API does not stop two records with the same CareRequestRecordType
-from both having IsDefaultRecordType=true. Before marking one default,
-query existing defaults for that record type and set them to false so
-the admin ends up with one default. (5) IsActive defaults to false on
-create; send IsActive=true to make the configuration live. Language
-defaults to en_US. DeveloperName must be unique (400
-DUPLICATE_DEVELOPER_NAME). Update is a partial PATCH: omitted fields
-keep their values.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have Health Cloud Utilization Management enabled and the
-caller must hold Care Request Configuration access to read/write
-records via sObject or Tooling API. (check: `Care Request Configuration access`)
-- User needs CRUD access to CareRequestConfiguration. (check: `<udd:crud:CareRequestConfiguration>`)
-- User needs access to manage CareRequestConfiguration (CRUD on the
-CareRequestConfiguration sObject). (check: `Utilization Management access`)
-- Creating or editing a configuration needs an active record type,
-with the DeveloperName used in CareRequestRecordType, on both the
-CareRequest and Case objects, and on every object selected in
-CareRequestRecords. Case record types also require a support
-process. Create missing record types first in Setup Object Manager
-or with the Metadata API. (check: `Matching record type on CareRequest, Case, and selected related objects`)
-
-## 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/CareRequestConfiguration/describe` | — |
-| `list` | read | — | `GET /services/data/v67.0/query` | — |
-| `get-by-id` | read | — | `GET /services/data/v67.0/sobjects/CareRequestConfiguration/{Id}` | `list` |
-| `create` | write | — | `POST /services/data/v67.0/sobjects/CareRequestConfiguration` | `describe` |
-| `update` | write | — | `PATCH /services/data/v67.0/sobjects/CareRequestConfiguration/{Id}` | `get-by-id`, `describe` |
-| `delete` | write | — | `DELETE /services/data/v67.0/sobjects/CareRequestConfiguration/{Id}` | `get-by-id` |
-
-### 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)"]
-  list --> get_by_id
-  describe --> create
-  get_by_id --> update
-  describe --> update
-  get_by_id --> delete
-```
-
-### Read operations
-
-#### `describe`
-
-Retrieve the CareRequestConfiguration sObject describe to pull the
-field list, picklist values, FLS flags, and createable/updateable
-bits. Required pre-step for create and update to resolve picklist
-values for CareRequestType (8 enum values) and Language (standard
-Salesforce language codes).
-
-**Call:** `GET /services/data/v67.0/sobjects/CareRequestConfiguration/describe`
-
-**Output:** DescribeSObjectResult for CareRequestConfiguration — use this to build the field list for list / create / update payloads.
-
-#### `list`
-
-List CareRequestConfiguration records via SOQL. Useful filters:
-IsActive=true (live configurations), IsDefaultRecordType=true (defaults;
-more than one per record type is possible, so check for duplicates),
-CareRequestRecordType='<name>', and CareRequestType='<value>'. Pair with
-describe first to pick field names.
-
-**Call:** `GET /services/data/v67.0/query`
-
-**Inputs:**
-
-- `where` *(`String`)* — Optional SOQL WHERE clause to filter Care Request Configuration records.
-- `limit` *(`int`)* — Optional SOQL LIMIT value.
-- `q` *(`string`)*
-
-**Output:** Query response with records[] of CareRequestConfiguration — Id plus any SELECTed fields.
-
-#### `get-by-id`
-
-Retrieve a specific CareRequestConfiguration record by Id.
-
-**Call:** `GET /services/data/v67.0/sobjects/CareRequestConfiguration/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the CareRequestConfiguration record to fetch.
-
-**Depends on:** `list`
-
-**Output:** Single CareRequestConfiguration record with all readable fields per user FLS.
-
-### Write operations
-
-#### `create`
-
-Create a CareRequestConfiguration record. Send DeveloperName,
-MasterLabel, CareRequestRecordType, and CareRequestType; set
-IsActive=true to make it live (defaults to false). CareRequestRecordType
-is the DeveloperName of a record type that must exist on CareRequest,
-Case, and every object selected in CareRequestRecords, or the create
-returns 400 UNKNOWN_EXCEPTION on CareRequestRecordType.
-
-**Call:** `POST /services/data/v67.0/sobjects/CareRequestConfiguration`
-
-**Inputs:**
-
-- `body` *(`object`)* — Field/value map for the new CareRequestConfiguration. Populate from /describe's createableFields list.
-
-**Depends on:** `describe`
-
-**Output:** SaveResult — id, success, errors[]. On success, id is the new CareRequestConfiguration record Id; on failure, errors carries StatusCode plus message and offending fields.
-
-**Rollback:** Call delete with the returned Id to undo the create.
-
-**Notes:** error_contracts: Record type missing on CareRequest, Case, or any selected
-CareRequestRecords object: 400 UNKNOWN_EXCEPTION, "The selected record
-type is not available for all the objects you have selected.",
-fields=["CareRequestRecordType"]. Passing a record type Id instead of a
-DeveloperName fails the same way. Duplicate DeveloperName: 400
-DUPLICATE_DEVELOPER_NAME "Duplicate Label or Developer Name".; payload_fields: DeveloperName (unique, max 80 chars, API-name shape), MasterLabel (max
-80 chars), CareRequestRecordType (record type DeveloperName, max 255),
-CareRequestType (one of Drug Request | Service Request | Admission |
-Concurrent Review | Appeal | Complaint | Grievance | Referral; not
-validated by the platform), CareRequestRecords (semicolon-separated,
-from Care Request Drug | Care Request Item | Care Diagnosis | Care
-Request Extension), IsActive (default false), IsDefaultRecordType
-(default false), Language (default en_US).; not_enforced: The platform accepts an unknown CareRequestType, an omitted
-CareRequestType, and a second IsDefaultRecordType=true record for the
-same record type. Validate these before calling create.
-
-#### `update`
-
-Update an existing CareRequestConfiguration record. Merge-patch
-semantics: fields omitted from the body are preserved. If the body
-includes CareRequestRecordType, its value must still equal a valid
-DeveloperName of a RecordType on the CareRequest sObject — the same
-400 UNKNOWN_EXCEPTION fires on an invalid change.
-
-**Call:** `PATCH /services/data/v67.0/sobjects/CareRequestConfiguration/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the CareRequestConfiguration to update.
-- `body` *(`object`)* — Partial field/value map — only include fields you want to change.
-
-**Depends on:** `get-by-id`, `describe`
-
-**Output:** 204 No Content on success. On failure, returns a JSON array of errors with StatusCode, message, and offending fields.
-
-#### `delete`
-
-Delete a CareRequestConfiguration record.
-
-**Call:** `DELETE /services/data/v67.0/sobjects/CareRequestConfiguration/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the CareRequestConfiguration to delete.
-
-**Depends on:** `get-by-id`
-
-**Output:** 204 No Content on success. On failure, returns a JSON array of errors with StatusCode and message.

package/skills/industries-case-management-intelligence-settings-configure/SKILL.md

@@ -1,54 +0,0 @@
----
-name: industries-case-management-intelligence-settings-configure
-description: "Use this skill when users want to nonProfit Cloud Case Management Intelligence guided-setup wizard. Trigger when users mention case, mgmt, intelligence, settings, case mgmt intelligence settings."
-metadata:
-  version: "1.0"
-  accessCheck: "Industries.userCanAccessSetup"
----
-
-# Querying Case Mgmt Intelligence Settings
-
-## When to Use This Skill
-
-NonProfit Cloud Case Management Intelligence guided-setup wizard. get-admin-setup-data loads the wizard layout (configurations/groups/ordered-steps with server-evaluated stepStatus + per-step action descriptors) via fileName=CaseMgmtIntelligenceSetup.json. All three original controller methods substitute the Aura admin-setup operation with industries-healthcare-connect-api Connect endpoints (Aura is a thin pass-through). Note: execute-admin-setup-step-action and parameterized-execute-admin-setup-step-action are rejected for headless dispatch -- see navigate-case-mgmt-intelligence-setup. This node's own setupConfig declares no executor-backed action (4 steps: Manual, ButtonNavigate, LaunchComponent, ButtonNavigate), and the generic caller-supplied-actionName dispatcher those two steps use reaches a cross-feature executor that grants the Data Cloud Salesforce Connector permission set -- the same underlying grant this wizard's own LaunchComponent step auto-fires on mount, with no accept-click of its own and no enforced step-ordering precondition of its own either (the underlying wizard step's own configuration declares no dependency or preValidation). Gated at the Connect wire tier by a broad ~14-way Industries org-feature OR-list (HealthCloud-related checks and Public Sector Cloud LPI among them, plus several other Industries clouds -- not limited to Nonprofit Cloud or FSC-specific features).
-
-## Workflow
-
-Only get-admin-setup-data is executable for headless dispatch. Read it first to learn current stepStatus. Both write steps (execute-admin-setup-step-action, parameterized-execute-admin-setup-step-action) are rejected -- this node's own setupConfig has no executor-backed action, and the generic dispatcher reaches a cross-feature grant (see navigate-case-mgmt-intelligence-setup and the rejected steps' reason fields). Use navigate-case-mgmt-intelligence-setup to route the admin to the Setup page to drive the wizard (including its LaunchComponent step) themselves.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- View Setup permission (user must have Industries AccessSetup access) (check: `View Setup permission`)
-
-## 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 /connect/industries/adminSetup/{fileName}` | — |
-| `navigate-case-mgmt-intelligence-setup` | read | — | `CaseMgmtIntelligenceSettings.setup` | — |
-
-### Read operations
-
-#### `get-admin-setup-data`
-
-Load the wizard. fileName=CaseMgmtIntelligenceSetup.json (only valid value for this node). Returns AdminSetupRepresentation: featureName, ordered configurations[] (groups with ordered steps; each carries action descriptor, server-evaluated stepStatus, stepCompletionCheck, helpUrl), errors[], disableReset, isSuccess.
-
-**Call:** `GET /connect/industries/adminSetup/{fileName}`   — status: `proposed`
-
-**Inputs:**
-
-- `fileName` *(`String`)*
-
-**Notes:** error_contracts: 404 NOT_FOUND when the caller's org lacks a matching Industries-family org-feature — the Connect org-feature check is a broad ~14-way OR-list (HealthCloud-related checks and Public Sector Cloud LPI among them, plus several other Industries clouds — not limited to Nonprofit Cloud or FSC-specific features) that gates this read at the wire tier. Verified: probe against an org with no matching OR-list feature returned 404. 500 INVALID_INPUT when fileName != CaseMgmtIntelligenceSetup.json. Path segment must include the trailing .json literal as-is (no URL-encoding needed; probe with the literal .json in the path segment returns 404 (feature-gated), which is a routing hit, not a URL-layer intercept).
-
-#### `navigate-case-mgmt-intelligence-setup`
-
-Routes a human admin to the Case Mgmt Intelligence Settings Setup page to drive the wizard themselves. Replaces execute-admin-setup-step-action and parameterized-execute-admin-setup-step-action for headless dispatch: this node's own setupConfig has no executor-backed action, and the generic dispatcher those steps use reaches a cross-feature executor that grants the Data Cloud Salesforce Connector permission set -- the same underlying grant this wizard's own LaunchComponent step auto-fires on mount, not gated by an accept-click or by any enforced step-ordering precondition of its own (the underlying wizard step's own configuration declares no dependency or preValidation) -- the only practical gate is that a human has to open the Setup page and reach the step at all. An agent should navigate the admin here and let them drive the wizard themselves, not dispatch step actions on their behalf. get-admin-setup-data remains fully executable for reading wizard layout and stepStatus.
-
-**Call:** `CaseMgmtIntelligenceSettings.setup`