@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/industries-fundraising-gift-entry-settings-configure/SKILL.md

@@ -1,120 +0,0 @@
----
-name: industries-fundraising-gift-entry-settings-configure
-description: "Use this skill when users want to setup configuration for Nonprofit Cloud Fundraising's Gift Entry page. Trigger when users mention fundraising, gift, entry, settings, fundraising gift entry settings."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesFundraising.userIsFundraisingAdmin"
----
-
-# Managing Fundraising Gift Entry Settings
-
-## When to Use This Skill
-
-Setup configuration for Nonprofit Cloud Fundraising's Gift Entry page. Three independent surfaces gated by the Fundraising Admin role + the Fundraising org-pref: (1) FieldMappingConfigItem rules that map donor gift fields to target object/field -- READ ONLY today (get-configuration-view); the batch-upsert/batch-delete writes are withheld (rejected), non-functional over the headless path -- see save-configuration-items / delete-configuration-items' rejection reasons; (2) the org-level Gift Entry Grid preference -- fully functional (read / toggle / verify); (3) named grid templates with the only-one-holds single-gift-default flag -- READ ONLY today (get-gift-entry-grid-templates); set-single-gift-default is withheld (rejected), non-functional over the headless path -- see its own rejection reason; delete-gift-entry-grid-template is navigate-only (permanently, not a rejection) -- it hands the user off to the Setup page rather than exposing a callable delete. Grid-template read additionally requires the same Gift Entry Grid customization feature gate as the grid-template writes.
-
-## Workflow
-
-Three independent surfaces; only the reads and the toggle are executable today. Field-mapping: get-configuration-view is the only executable step -- its batch-upsert (save-configuration-items) and batch-delete (delete-configuration-items) siblings are rejected, non-functional over the headless path. Grid org pref: is-enabled / toggle / verify -- fully functional, use freely. Templates: get-gift-entry-grid-templates is the only executable step -- its set-single-gift-default sibling is rejected, non-functional over the headless path. delete-gift-entry-grid-template is navigate-only (permanently, not merely rejected): it's rewritten in place to an api_type: setup_page hand-off with no callable op, since the Setup UI's delete confirmation is irreversibility-gated and its eligibility checks are client-side only.
-
-Root cause of the rejected writes (live-org dispatch confirmed, 2026-08-26): every non-empty payload against the 4 object-argument writes fails with a request-validation error before any business logic runs -- a known deserialization defect in how those write operations bind their inbound payload, tracked for a fix; not a payload, gate, or schema mistake on the caller's side. The zero-arg reads and the boolean-arg toggle are unaffected and dispatch normally.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have IndustriesFundraising userIsFundraisingAdmin access (check: `Fundraising Admin role`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `toggle-gift-entry-grid-org-preference`: call `verify-toggle-gift-entry-grid-org-preference` (`GET /headless/invoke/platform/fundraising-gift-entry-settings/is-gift-entry-grid-org-preference-enabled`)
-- After (write): call `verify-delete-gift-entry-grid-template` (`GET /headless/invoke/platform/fundraising-gift-entry-settings/get-gift-entry-grid-templates`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-configuration-view` | read | proposed | `GET /headless/invoke/platform/fundraising-gift-entry-settings` | — |
-| `is-gift-entry-grid-org-preference-enabled` | read | proposed | `GET /headless/invoke/platform/fundraising-gift-entry-settings/is-gift-entry-grid-org-preference-enabled` | — |
-| `toggle-gift-entry-grid-org-preference` | write | proposed | `PATCH /headless/invoke/platform/fundraising-gift-entry-settings/toggle-gift-entry-grid-org-preference` | — |
-| `verify-toggle-gift-entry-grid-org-preference` | verify | — | `GET /headless/invoke/platform/fundraising-gift-entry-settings/is-gift-entry-grid-org-preference-enabled` | `toggle-gift-entry-grid-org-preference` |
-| `get-gift-entry-grid-templates` | read | proposed | `GET /headless/invoke/platform/fundraising-gift-entry-settings/get-gift-entry-grid-templates` | — |
-| `delete-gift-entry-grid-template` | discovery | proposed | — | `get-gift-entry-grid-templates` |
-| `verify-delete-gift-entry-grid-template` | verify | — | `GET /headless/invoke/platform/fundraising-gift-entry-settings/get-gift-entry-grid-templates` | — |
-
-### Read operations
-
-#### `get-configuration-view`
-
-Get configuration view.
-
-**Call:** `GET /headless/invoke/platform/fundraising-gift-entry-settings`   — status: `proposed`
-
-**Output:** Returns `{settings: [row, ...]}` -- FieldMappingConfigItem rows scoped to ProcessType = GiftEntry (Tooling-backed, sourceFieldLabel system-enriched), NOT a MappingType filter. Empty array when no Fundraising-scoped mappings exist. Each row has exactly 7 properties: sourceFieldName, sourceFieldLabel, destinationObjectName, destinationFieldName, sequence (int), fieldMappingConfigId, id. NOTE: the response is `settings`, not `{fields, templates}` -- the field-mapping surface and the grid-template surface are separate reads; templates come from `get-gift-entry-grid-templates`.
-
-#### `is-gift-entry-grid-org-preference-enabled`
-
-Read the org-level Gift Entry Grid preference boolean. The preference lives in the Fundraising settings service; no Metadata OrgPreferenceSettings or Tooling/sObject exposes it.
-
-**Call:** `GET /headless/invoke/platform/fundraising-gift-entry-settings/is-gift-entry-grid-org-preference-enabled`   — status: `proposed`
-
-**Output:** Returns the org-level Gift Entry Grid preference as a bare boolean wrapped in the envelope: `{status_code: 200, body: true|false}`. The preference lives in the Fundraising settings service (no Metadata `OrgPreferenceSettings` type covers it), so this is the canonical read.
-
-#### `get-gift-entry-grid-templates`
-
-Get gift entry grid templates.
-
-**Call:** `GET /headless/invoke/platform/fundraising-gift-entry-settings/get-gift-entry-grid-templates`   — status: `proposed`
-
-**Output:** Returns `{templates: [row, ...]}` where each row carries `developerName`, `masterLabel`, `description`, `isSingleGiftDefault`, `isActive`. Only one row's `isSingleGiftDefault` is true at any time (only-one-holds invariant enforced by the controller when `set-single-gift-default` runs). OOTB template `Default` is always present and pre-set as the single-gift default on a stock org.
-
-**Notes:** gate: Additionally feature-gated on the Gift Entry Grid customization feature -- the same access check covers this read too, not just the set-default/delete writes.
-
-### Write operations
-
-#### `toggle-gift-entry-grid-org-preference`
-
-Toggle the org-level Gift Entry Grid preference (enable boolean). The preference lives in the Fundraising settings service; no Metadata OrgPreferenceSettings or Tooling/sObject exposes it.
-
-**Call:** `PATCH /headless/invoke/platform/fundraising-gift-entry-settings/toggle-gift-entry-grid-org-preference`   — status: `proposed`
-
-**Inputs:**
-
-- `enable` *(`boolean`)* — Toggle the enable preference on or off.
-
-**Notes:** envelope: Arg-taking method (boolean). Dispatches successfully on this org -- verified bidirectional (OFF->ON and ON->OFF), reversible, no confirmation gate. The object-argument writes (save-configuration-items, delete-configuration-items, set-single-gift-default, delete-gift-entry-grid-template) fail for an unrelated, genuine reason -- see each step's functional_defect note.
-
-### Verify operations
-
-#### `verify-toggle-gift-entry-grid-org-preference`
-
-Verify the toggle's effect: re-call is-gift-entry-grid-org-preference-enabled and assert it returns the boolean just set. The companion read observes the same Fundraising service-layer state the toggle writes.
-
-**Call:** `GET /headless/invoke/platform/fundraising-gift-entry-settings/is-gift-entry-grid-org-preference-enabled`
-
-**Depends on:** `toggle-gift-entry-grid-org-preference`
-
-#### `verify-delete-gift-entry-grid-template`
-
-Re-call get-gift-entry-grid-templates and check which template currently carries the single-gift-default flag. delete-gift-entry-grid-template is navigate-only (never headlessly executable), so this read does not depend on it -- it just lists current templates independent of whether a human ever deletes one via the Setup page.
-
-**Call:** `GET /headless/invoke/platform/fundraising-gift-entry-settings/get-gift-entry-grid-templates`
-
-**Notes:** role_after_rejection: delete-gift-entry-grid-template is converted to a navigate-only setup_page hand-off (never headlessly executable -- see its description/source rationale), not merely rejected. This read remains useful standing alone: an agent can call it to list current templates and check which one carries the single-gift-default flag before routing a human through the Setup page to delete one.
-
-### Other operations
-
-#### `delete-gift-entry-grid-template`
-
-Navigation-only -- do not attempt an API call; hand off to the Setup page (view_url) for a human admin to delete a custom Gift Entry Grid template themselves. There is no headlessly-callable version of this step: the Setup UI gates template deletion behind an explicit irreversibility confirmation ("...you can't recover it later...") and template-list eligibility (can't delete the current single-gift-default or the synthesized OOTB "Default" row) is enforced client-side only, in the Lightning grid-template component, not by the controller/service layer. A headless caller bypassing that UI would delete past the user's consent with no eligibility guard. This holds independent of, and would still hold after, the unrelated inbound-model deserialization defect that also currently breaks this step's underlying controller call (see notes.functional_defect) -- fixing that defect would not make this step safe to execute headlessly.
-
-**Status:** `proposed`
-
-**Depends on:** `get-gift-entry-grid-templates`
-
-**Notes:** envelope: N/A -- navigate-only, no dispatch envelope. (Corrects the base SOR's note, which claimed OOTB templates are filtered pre-DML server-side -- they are not: eligibility is enforced client-side only, same as this step's description already explains; moot now regardless, since this step no longer dispatches.); functional_defect: Same root cause as the other object-argument writes -- a known deserialization defect that returns an error on every non-empty payload (tracked, fix pending). Moot for headless dispatch regardless -- this step is converted to navigate-only below on a separate, permanent basis, so that defect is not the operative reason it's non-executable.

package/skills/industries-fundraising-rfm-configure/SKILL.md

@@ -1,128 +0,0 @@
----
-name: industries-fundraising-rfm-configure
-description: "Use this skill when users want to manages the AffinityScoreDefinition that drives Nonprofit Cloud RFM (Recency, Frequency, Monetary) and CAP donor scoring. Trigger when users mention fundraising, rfm, fundraising rfm."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesFundraising.userIsFundraisingAdmin"
----
-
-# Managing Fundraising Rfm
-
-## When to Use This Skill
-
-Manages the AffinityScoreDefinition that drives Nonprofit Cloud RFM (Recency, Frequency, Monetary) and CAP donor scoring. Reads/upserts the FundraisingScoringConfigModel for a given AffinityScoreType (RFM or CAP) — source/target object fields, score ranges, range count, lookback months. Save also regenerates and upserts the RFM_Score_Calculation Data Processing Engine job. Lists custom queryable sObjects available as source/target entities, and reports whether the DPE job is in flight (used to gate Save). All operations require the Fundraising Admin role guard plus View Setup.
-
-## Workflow
-
-Discover source/target sObjects via get-custom-entities-in-org and the existing config via get-fundraising-scoring-config-model (RFM or CAP). Gate save on is-dpe-job-currently-running == false. Save upserts the AffinityScoreDefinition, then separately (non-atomically) regenerates the RFM_Score_Calculation DPE; a DPE-regen failure leaves the AffinityScoreDefinition persisted with no rollback. Verify by re-reading the config.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have IndustriesFundraising userIsFundraisingAdmin access (check: `Fundraising Admin role`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `save-fundraising-scoring-config-model`: call `verify-save-fundraising-scoring-config-model` (`GET /headless/invoke/platform/fundraising-rfm/get-fundraising-scoring-config-model`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-custom-entities-in-org` | read | implemented | `GET /headless/invoke/platform/fundraising-rfm` | — |
-| `get-fundraising-scoring-config-model` | read | proposed | `GET /headless/invoke/platform/fundraising-rfm/get-fundraising-scoring-config-model` | — |
-| `save-fundraising-scoring-config-model` | write | proposed | `PATCH /headless/invoke/platform/fundraising-rfm/save-fundraising-scoring-config-model` | `is-dpe-job-currently-running`, `get-fundraising-scoring-config-model` |
-| `verify-save-fundraising-scoring-config-model` | verify | — | `GET /headless/invoke/platform/fundraising-rfm/get-fundraising-scoring-config-model` | `save-fundraising-scoring-config-model` |
-| `is-dpe-job-currently-running` | read | proposed | `GET /headless/invoke/platform/fundraising-rfm/is-dpe-job-currently-running` | — |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  get_custom_entities_in_org["get-custom-entities-in-org (read)"]
-  get_fundraising_scoring_config_model["get-fundraising-scoring-config-model (read)"]
-  save_fundraising_scoring_config_model["save-fundraising-scoring-config-model (write)"]
-  verify_save_fundraising_scoring_config_model["verify-save-fundraising-scoring-config-model (verify)"]
-  is_dpe_job_currently_running["is-dpe-job-currently-running (read)"]
-  is_dpe_job_currently_running --> save_fundraising_scoring_config_model
-  get_fundraising_scoring_config_model --> save_fundraising_scoring_config_model
-  save_fundraising_scoring_config_model --> verify_save_fundraising_scoring_config_model
-```
-
-### Read operations
-
-#### `get-custom-entities-in-org`
-
-Returns custom queryable sObjects (SObjectInfo records with per-user CRUD/FLS flags) available as RFM scoring source or target entities. No parameters. No public Connect/Tooling/Metadata/sObject alternative covers the typed SObjectInfo shape; the controller is the documented Setup-page interface.
-
-**Call:** `GET /headless/invoke/platform/fundraising-rfm`   — status: `implemented`
-
-**Output:** List of SObjectInfo records — each carries apiName, entityLabel, entityLabelPlural, keyPrefix, custom (true), customSetting, associateEntityType, associateParentEntity, plus per-user CRUD/FLS flags accessible/queryable/searchable/createable/deletable/updateable.
-
-#### `get-fundraising-scoring-config-model`
-
-Reads the AffinityScoreDefinition for the given affinityScoreType (RFM or CAP) and returns it as a FundraisingScoringConfigModel. Returns null when no definition exists yet; any affinityScoreType outside {RFM, CAP} is rejected as invalid input. AURA-IS-CANONICAL: substituting raw Tooling SOQL on AffinityScoreDefinition drops the AffinityScoreType allowlist and the typed FundraisingScoringConfigModel shape.
-
-**Call:** `GET /headless/invoke/platform/fundraising-rfm/get-fundraising-scoring-config-model`   — status: `proposed`
-
-**Inputs:**
-
-- `affinityScoreType` *(`String`)*
-
-**Output:** FundraisingScoringConfigModel wrapping a single affinityScoreDefinitionConfig field (mappedEntity + per-field accessors). When no AffinityScoreDefinition exists yet for the given affinityScoreType, the response body is an empty object ({}), NOT null — consumers checking for null-on-absent will misclassify a fresh org as an error.
-
-**Notes:** error_contract: Any affinityScoreType value not exactly equal to "RFM" or "CAP" (case-sensitive) returns HTTP 500 with errorCode CONTROLLER_ERROR and message "Select a valid affinity score type." The same 500 is returned for lowercase "rfm", empty string, or a missing parameter — the enum check runs before any request-shape validation. Consumers should treat this as an input-validation contract, not a server fault.; case_sensitivity: affinityScoreType is case-sensitive at the controller boundary — only "RFM" and "CAP" (upper-case) are accepted.
-
-#### `is-dpe-job-currently-running`
-
-Returns true when the RFM_Score_Calculation Data Processing Engine job is actively executing; any other dpeJobDeveloperName is rejected as invalid input. AURA-IS-CANONICAL: the controller hard-restricts dpeJobDeveloperName to RFM_Score_Calculation, a server-enforced allowlist that a generic Tooling AsyncApexJob query cannot replicate.
-
-**Call:** `GET /headless/invoke/platform/fundraising-rfm/is-dpe-job-currently-running`   — status: `proposed`
-
-**Inputs:**
-
-- `dpeJobDeveloperName` *(`String`)*
-
-**Output:** Boolean — true when the RFM_Score_Calculation DPE job is currently executing in the org, false otherwise.
-
-**Notes:** error_contract: Any dpeJobDeveloperName value not exactly equal to "RFM_Score_Calculation" returns HTTP 500 with errorCode CONTROLLER_ERROR and message "Select a valid DPE job developer name." This is a server-enforced hard allowlist, not a soft picklist — the controller has one and only one job name it will report on.; allowlist_reminder: dpeJobDeveloperName MUST be the literal string "RFM_Score_Calculation". Do not attempt to poll status of arbitrary DPE jobs through this endpoint.
-
-### Write operations
-
-#### `save-fundraising-scoring-config-model`
-
-Validates all six inboundModel fields are non-null and affinityScoreType is in {RFM, CAP}, persists the AffinityScoreDefinition, then regenerates and upserts the corresponding RFM_Score_Calculation DPE definition in the same call. AURA-IS-CANONICAL: a raw Tooling upsert breaks atomicity by orphaning the DPE regeneration.
-
-**Call:** `PATCH /headless/invoke/platform/fundraising-rfm/save-fundraising-scoring-config-model`   — status: `proposed`
-
-**Inputs:**
-
-- `inboundModel` *(`FundraisingScoringConfigInboundModel`)* — Value for inbound model.
-  - schema: `#/components/schemas/FundraisingScoringConfigInboundModel`
-
-**Depends on:** `is-dpe-job-currently-running`, `get-fundraising-scoring-config-model`
-
-**Notes:** error_contract: Any missing or null inboundModel field, OR an affinityScoreType outside {RFM, CAP}, returns HTTP 500 with errorCode CONTROLLER_ERROR and the generic message "Select a valid inbound model." The save path unifies 6-field non-null validation and enum-allowlist enforcement into one error string — consumers cannot infer which field failed from the message alone and should pre-validate all six inboundModel fields client-side before calling.; atomicity: The AffinityScoreDefinition upsert (step 1) commits independently before DPE regeneration (step 3); any failure after step 1 — including but not limited to DPE regen errors — leaves the definition persisted with no rollback. Callers that receive a 500 should read back via get-fundraising-scoring-config-model before retrying, to avoid re-sending a definition that already committed.; read_before_write: Callers should first invoke get-fundraising-scoring-config-model for the same affinityScoreType to determine whether an existing definition needs to be merged, since the save is an upsert (the controller does not accept a partial patch of individual fields).; aura_canonical_rationale: AURA-IS-CANONICAL: no Connect API alternative exists for saving an AffinityScoreDefinition. Do not substitute with a raw Tooling API PATCH — that path bypasses the controller-enforced allowlist gate and the atomic DPE-regen coupling that this step provides.; validator_rules: All six inboundModel fields are required (non-null); additionally, content-level validation enforces: source weights must sum to exactly 1; each weight must be in (0, 1]; no duplicate source fields; no source field may equal a target field; all referenced sObjects and fields must exist and be queryable. Any of these failures returns the same generic 500 "Select a valid inbound model." Pre-validating all six fields for non-null is necessary but not sufficient.; permissions_prerequisite: DPE regeneration requires the running user to have the Data Pipelines permission; without it, save commits the AffinityScoreDefinition but regen fails with a 500 CONTROLLER_ERROR "We couldn't create or update the related Data Processing Engine definition... You don't have the required Data Pipelines permission."; recurring_refresh_scope: This skill produces the activated RFM_Score_Calculation DPE definition. Recurring score refresh scheduling is out of scope for this skill — no skill in this corpus schedules recurring DPE recalculation. Keeping scores fresh on a cadence requires the customer to configure their own scheduled automation (e.g., a Scheduled Flow or Apex Scheduler) that triggers recalculation.
-
-### Verify operations
-
-#### `verify-save-fundraising-scoring-config-model`
-
-Reads back the AffinityScoreDefinition for the same affinityScoreType to confirm the save persisted; the saved field lists, score ranges, and counts must round-trip through the FundraisingScoringConfigModel.
-
-**Call:** `GET /headless/invoke/platform/fundraising-rfm/get-fundraising-scoring-config-model`
-
-**Inputs:**
-
-- `affinityScoreType` *(`String`)*
-
-**Depends on:** `save-fundraising-scoring-config-model`
-
-**Notes:** aura_canonical_rationale: AURA-IS-CANONICAL: same rationale as save-fundraising-scoring-config-model. The verify step re-reads via the same Aura dispatcher path; no Connect API alternative exists.

package/skills/industries-fundraising-settings-configure/SKILL.md

@@ -1,145 +0,0 @@
----
-name: industries-fundraising-settings-configure
-description: "Use this skill when users want to configures the Fundraising org preference and the singleton FundraisingConfig persistence row for Nonprofit Cloud / Industries Fundraising. Trigger when users mention fundraising, settings, fundraising settings."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesFundraising.userIsFundraisingAdmin"
----
-
-# Managing Fundraising Settings
-
-## When to Use This Skill
-
-Configures the Fundraising org preference and the singleton FundraisingConfig persistence row for Nonprofit Cloud / Industries Fundraising. Note: set-fundraising-org-preference is a one-way, org-wide, irreversible enable with no disable path (source-confirmed) -- dispatchable, but a caller MUST obtain an explicit, dedicated confirmation of that irreversibility from the requesting admin before calling it; navigate-fundraising-turn-on remains available as a human-driven alternative. saveFundraisingSettings persists FundraisingConfig fields: failed/lapsed transaction auto-status thresholds, installment grace days, donorMatchingMethod (Duplicate_Management_Rules | No_Matching -- source-confirmed exactly these 2 members exist; Duplicate_Management_Rules is the default value, not a separate third enum constant -- there is no hidden or unofferred value), donor external-ID custom field, recurring auto-create + auto-close flags, and NextGen Commitment Processing batch size / max threads / parallel toggle (only max threads is range-validated -- see save-fundraising-settings notes). updateDataCloudPermSet assigns the Data Cloud permission set required for the Fundraising / Data Cloud integration. The LWC toggles for Philanthropic Research / Gift Planning / Gift Agreement / Gift-* validations are NOT in this controller -- those route through sibling Industries Fundraising controllers.
-
-## Workflow
-
-All 4 base methods stay on the Aura controller path for headless execution -- no public Connect / Tooling / Metadata / sObject substitution preserves the full contract (composite view-model assembly, server-enforced field-validation ranges, hardcoded Data Cloud perm-set + Fundraising Admin role gate). The 4th, setFundraisingOrgPreference, is a one-way, org-wide, irreversible enable with no disable path -- dispatchable, but ONLY after obtaining an explicit, dedicated confirmation of that irreversibility from the requesting admin (distinct from any general confirm-to-write checkpoint); the Setup UI gates the equivalent "Turn On" toggle behind the same kind of explicit irreversibility-acceptance modal. Use navigate-fundraising-turn-on instead when the admin would rather accept that modal themselves.
-
-For source-controlled deployment of a subset of the persisted FundraisingConfig row, the Metadata API type `FundraisingConfig` (directory `fundraisingConfigs/`, suffix `.fundraisingConfig`) is a documented partial-coverage alternative. Its documented Fields spec covers 6 of 10 inboundModel fields via `.fundraisingConfig` XML: donorMatchingMethod, failedTransactionCount, installmentExtDayCount, lapsedUnpaidTrxnCount, shouldClosePaidRcrCmt, shouldCreateRcrSchdTrxn. A 7th, donorExternalIdField, appears in the type's sample XML but not in its documented Fields table -- treat that one as unconfirmed rather than relying on it. It does NOT reach the NextGen Commitment Processing knobs (isNextGenCmtPrcsParallel, nextGenCmtPrcsBatchSize, nextGenCmtPrcsMaxThreads), does NOT drive the org-preference enable, and does NOT perform the write-on-read default-row initialization getSettingsViewModel does. Use the Metadata API path when an admin wants source-controlled deployment of the 6 documented fields; use Aura for NextGen tuning, donorExternalIdField, and full-atomic writes.
-
-Order: (1) get-settings-view-model probes orgPreferenceEnabled + current FundraisingConfig values + DonorMatchingMethod picklist. (2) If orgPreferenceEnabled is false, obtain an explicit, dedicated confirmation of the one-way/irreversible/no-disable-path nature of the enable from the requesting admin, then call set-fundraising-org-preference; without that confirmation, call navigate-fundraising-turn-on instead to route the admin to accept the Setup UI's own irreversibility modal themselves. (3) Once enabled (the normal steady-state case, or immediately after step 2), save-fundraising-settings writes user-supplied FundraisingConfig field values. (4) update-data-cloud-perm-set is independent -- assigns the hardcoded Data Cloud perm set when the Fundraising / Data Cloud integration is needed. Verify writes by re-reading get-settings-view-model and comparing orgPreferenceEnabled / settingsFields (the two verify steps do exactly this).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have Fundraising Admin role access. (check: `Fundraising Admin role`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `set-fundraising-org-preference`: call `verify-set-fundraising-org-preference` (`GET /headless/invoke/platform/fundraising-settings/get-settings-view-model`)
-- After `save-fundraising-settings`: call `verify-save-fundraising-settings` (`GET /headless/invoke/platform/fundraising-settings/get-settings-view-model`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `set-fundraising-org-preference` | write | implemented | `PATCH /headless/invoke/platform/fundraising-settings/set-fundraising-org-preference` | — |
-| `get-settings-view-model` | read | implemented | `GET /headless/invoke/platform/fundraising-settings/get-settings-view-model` | — |
-| `save-fundraising-settings` | write | implemented | `PATCH /headless/invoke/platform/fundraising-settings/save-fundraising-settings` | `set-fundraising-org-preference` |
-| `update-data-cloud-perm-set` | write | implemented | `PATCH /headless/invoke/platform/fundraising-settings/update-data-cloud-perm-set` | — |
-| `verify-set-fundraising-org-preference` | verify | implemented | `GET /headless/invoke/platform/fundraising-settings/get-settings-view-model` | `set-fundraising-org-preference` |
-| `verify-save-fundraising-settings` | verify | implemented | `GET /headless/invoke/platform/fundraising-settings/get-settings-view-model` | `save-fundraising-settings` |
-| `navigate-fundraising-turn-on` | read | — | `FundraisingSettings.turnOn` | — |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  set_fundraising_org_preference["set-fundraising-org-preference (write)"]
-  get_settings_view_model["get-settings-view-model (read)"]
-  save_fundraising_settings["save-fundraising-settings (write)"]
-  update_data_cloud_perm_set["update-data-cloud-perm-set (write)"]
-  verify_set_fundraising_org_preference["verify-set-fundraising-org-preference (verify)"]
-  verify_save_fundraising_settings["verify-save-fundraising-settings (verify)"]
-  navigate_fundraising_turn_on["navigate-fundraising-turn-on (read)"]
-  set_fundraising_org_preference --> save_fundraising_settings
-  set_fundraising_org_preference --> verify_set_fundraising_org_preference
-  save_fundraising_settings --> verify_save_fundraising_settings
-```
-
-### Read operations
-
-#### `get-settings-view-model`
-
-Returns FundraisingSettingsModel: orgPreferenceEnabled (boolean), settingsFields (FundraisingConfig field-value wrapper, populated only when the org pref is on), and donorMatchingPicklist (JSON-encoded DonorMatchingMethod picklist). Side effect: when orgPreferenceEnabled=true but no FundraisingConfig row exists, the controller auto-creates the default row and returns it. No parameters; no public read-only alternative reconstructs the composite (org-pref flag + FundraisingConfig + picklist + write-on-read default). Requires View Setup and System Administrator access.
-
-**Call:** `GET /headless/invoke/platform/fundraising-settings/get-settings-view-model`   — status: `implemented`
-
-**Output:** FundraisingSettingsGetsettingsviewmodelRepresentation: orgPreferenceEnabled (boolean — whether Fundraising org pref is on; settingsFields and donorMatchingPicklist are unpopulated when false), settingsFields (Fields wrapper exposing the FundraisingConfig field accessors), donorMatchingPicklist (JSON-encoded DonorMatchingMethod picklist for client rendering). Naming note: the failed-transaction threshold round-trips under different names — save-fundraising-settings writes it as failedTransCount, but it reads back here as failingTransCount. When verifying a write, compare against failingTransCount, not failedTransCount.
-
-#### `navigate-fundraising-turn-on`
-
-Optional human-driven alternative to dispatching set-fundraising-org-preference directly: routes a human admin to the Fundraising Settings Setup page to turn on Nonprofit Cloud for Fundraising themselves, accepting the Setup UI's own irreversibility-acceptance modal in the process. The underlying setFundraisingOrgPreference() call is a one-way, org-wide, irreversible enable with no disable path (source-confirmed) -- an agent that has NOT obtained the dedicated irreversibility confirmation required to dispatch set-fundraising-org-preference directly should route the admin here instead of proceeding without it. Once enabled (whether via this navigation or a direct confirmed dispatch), the rest of this skill -- get-settings-view-model, save-fundraising-settings, update-data-cloud-perm-set -- is fully headlessly executable.
-
-**Call:** `FundraisingSettings.turnOn`
-
-### Write operations
-
-#### `set-fundraising-org-preference`
-
-Atomic enable: turns ON the Fundraising org preference and writes the default FundraisingConfig row in one transaction. Enable-only -- no parameters, no request body, no disable path anywhere in the call chain (source-confirmed: FundraisingSettingsController.setFundraisingOrgPreference -> FundraisingSettingsServiceImpl.setOrgPreference hardcodes ORG_PREFERENCE_FUNDRAISING_ENABLED, ORG_PREFERENCE_GIFT_ENTRY_GRID_ENABLED, and ORG_PREFERENCE_FR_ENHANCED_CMT_PRSCR_ENABLED to true with no branch). This is a one-way, org-wide, irreversible action -- the Setup UI gates the equivalent "Turn On" toggle behind an explicit irreversibility-acceptance modal (source-confirmed verbatim, label industries-fundraising.xml|FundraisingSettings|fundraisingSettingsModalBodyText: "After enabling Nonprofit Cloud for Fundraising, it can't be disabled. We recommend that you try Fundraising in a sandbox before turning it on in your Salesforce org."). A caller MUST obtain an explicit, dedicated confirmation of that irreversibility from the requesting admin before dispatching this step -- distinct from any general confirm-to-write checkpoint. navigate-fundraising-turn-on remains available as a human-driven alternative for an admin who'd rather accept that modal themselves. Verify with verify-set-fundraising-org-preference (re-reads get-settings-view-model and asserts orgPreferenceEnabled=true). Requires View Setup and System Administrator access.
-
-**Call:** `PATCH /headless/invoke/platform/fundraising-settings/set-fundraising-org-preference`   — status: `implemented`
-
-**Output:** No response body (controller method return type is void; PATCH returns 204 No Content on success). Verify by re-reading get-settings-view-model and asserting orgPreferenceEnabled=true.
-
-#### `save-fundraising-settings`
-
-Persists user-supplied values into the singleton FundraisingConfig row: failed-transaction auto-status threshold (failedTransCount, field-level validated 0-15), lapsed-unpaid threshold (lapsedUnpaidTransCount, field-level validated 0-15), installment grace days (installmentExtDayCount, field-level validated 0-365), donorMatchingMethod (Duplicate_Management_Rules | No_Matching -- source-confirmed exactly these 2 members exist; Duplicate_Management_Rules is the default value, not a separate third enum constant), donorExternalIdField (CustomFieldDefinition restricted by SupportedFundraisingDonorExternalFields), createRecurringScheduleTransaction + autoCloseRecurringCommitment flags, and NextGen Commitment Processing batch size (nextGenCmtPrcsBatchSize, NOT range-validated -- see notes) / max threads (nextGenCmtPrcsMaxThreads, field-level validated 0-5) / parallel toggle. See notes.validation_enforcement_layer for how the range checks behave and notes.error_fidelity_gap for the out-of-range failure mode. No public alternative. Requires View Setup and System Administrator access.
-
-**Call:** `PATCH /headless/invoke/platform/fundraising-settings/save-fundraising-settings`   — status: `implemented`
-
-**Inputs:**
-
-- `inboundModel` *(`FundraisingSettingsInboundModel`)* — Value for inbound model.
-  - schema: `#/components/schemas/FundraisingSettingsInboundModel`
-
-**Depends on:** `set-fundraising-org-preference`
-
-**Output:** No response body (controller method return type is void; PATCH returns 204 No Content on success). Verify by re-reading get-settings-view-model.settingsFields and comparing to the inboundModel that was sent.
-
-**Notes:** metadata_api_alternative: Documented partial-coverage sibling write surface: Metadata API type `FundraisingConfig` (directory `fundraisingConfigs/`, suffix `.fundraisingConfig`) deploys 6 of 10 inboundModel fields via source-controlled XML, per its documented Fields table.
-
-Field-name map (inboundModel → FundraisingConfig): donorMatchingMethod → donorMatchingMethod; failedTransCount → failedTransactionCount; installmentExtDayCount → installmentExtDayCount; lapsedUnpaidTransCount → lapsedUnpaidTrxnCount; createRecurringScheduleTransaction → shouldCreateRcrSchdTrxn; autoCloseRecurringCommitment → shouldClosePaidRcrCmt.
-
-Unconfirmed 7th field: donorExternalIdField → donorExternalIdField appears in the type's sample XML but is not in its documented Fields table — treat as unverified, not a confirmed sibling mapping.
-
-Not covered by FundraisingConfig (Aura-only): isNextGenCmtPrcsParallel, nextGenCmtPrcsBatchSize, nextGenCmtPrcsMaxThreads. Use Aura when any NextGen knob is set or when donorExternalIdField needs a confirmed write path; use FundraisingConfig for source-controlled deployment of the 6 documented fields.; validation_enforcement_layer: The 0-15 (failed/lapsed), 0-365 (installment), and 0-5 (max threads) ranges are enforced as a hard rejection with no partial write (live-confirmed: an out-of-range 999 write was rejected outright). nextGenCmtPrcsBatchSize has no equivalent range enforcement -- out-of-range values are silently accepted with no cap, unlike the other four fields. There is no public (non-Aura) write path that reproduces this same enforcement behavior, which is why this step has no substitution alternative.; error_fidelity_gap: Out-of-range writes fail as a bare 500 INTERNAL_ERROR, not a 400 or a validation-shaped error message (live-confirmed on the 999 negative-range probe). The guard works -- the value is rejected and no partial write occurs -- but an agent cannot distinguish "bad input I should retry with a corrected value" from "server fault, retrying won't help."
-
-#### `update-data-cloud-perm-set`
-
-Assigns the Data Cloud permission set required for the Fundraising / Data Cloud integration to the calling user. Returns boolean (true on success). Gated by Fundraising Admin role (server-enforced -- not duplicated by sObject CRUD). The target permission set is fixed, not admin-configurable; substituting with a raw PermissionSetAssignment Tooling create would force the agent to discover the permission-set name out-of-band and drop the admin-role gate this step enforces.
-
-**Call:** `PATCH /headless/invoke/platform/fundraising-settings/update-data-cloud-perm-set`   — status: `implemented`
-
-**Output:** Boolean — true when the Data Cloud permission-set assignment succeeded. The boolean is itself the verify signal; no separate read-back endpoint is exposed by this controller.
-
-**Notes:** access_guard_detail: Source-confirmed: this is the most tightly gated of the 4 steps. It carries the same View Setup and System Administrator access gate as all 4 methods, AND an additional controller-level Fundraising Admin role check none of the other 3 methods have.; cross_skill_grant_inconsistency: This step directly and unconditionally grants the Data Cloud Salesforce Connector permission set to the calling admin on every successful call. It is admin-gated and self-scoped -- it grants permissions to the calling admin only, not an org-wide or package consent grant.
-
-### Verify operations
-
-#### `verify-set-fundraising-org-preference`
-
-Read get-settings-view-model and assert orgPreferenceEnabled=true to confirm set-fundraising-org-preference took effect. Same controller method as the get-settings-view-model read step; getSettingsViewModel returns the org-pref flag the enable just flipped.
-
-**Call:** `GET /headless/invoke/platform/fundraising-settings/get-settings-view-model`   — status: `implemented`
-
-**Depends on:** `set-fundraising-org-preference`
-
-**Notes:** role_as_confirmation_support: Useful both before and after set-fundraising-org-preference: pre-check whether the org preference is already enabled (the normal steady-state case) before deciding whether the dedicated irreversibility confirmation and dispatch are even needed, and post-write to confirm the enable landed (orgPreferenceEnabled=true).
-
-#### `verify-save-fundraising-settings`
-
-Read get-settings-view-model and compare settingsFields against the inboundModel sent to save-fundraising-settings to confirm the FundraisingConfig values persisted. Same controller method as the get-settings-view-model read step; getSettingsViewModel returns the persisted FundraisingConfig wrapped in settingsFields. Note the failedTransCount/failingTransCount naming asymmetry documented on get-settings-view-model's output -- comparison logic must map failedTransCount to failingTransCount, not compare field names literally.
-
-**Call:** `GET /headless/invoke/platform/fundraising-settings/get-settings-view-model`   — status: `implemented`
-
-**Depends on:** `save-fundraising-settings`