@salesforce/afv-skills 1.46.0 → 1.48.0

package/skills/life-sciences-kam-coordinate/references/stage-6-user-provisioning-overview.md

@@ -0,0 +1,89 @@
+# Stage 6 — KAM User Provisioning
+
+Creates the KAM end user, assigns the four KAM permission sets, sets a password, assigns both the user and the admin to the Stage-3 level-3 territory, and generates the mobile metadata cache. This is the final stage of `life-sciences-kam-coordinate`; the coordinator invokes it after the KAM data & plan templates (Stage 5) exist.
+
+## Stage Scope
+
+- **In scope**: creating one Active user (username contains `kam`) on the `LSC Custom Profile`, assigning 4 permission sets, setting a password, assigning the user + admin to the level-3 territory, and generating + verifying the mobile metadata cache
+- **Out of scope**: everything in Stages 1–5
+
+## Required Inputs
+
+- **Target org / admin**: admin alias or username (the metadata-cache generation runs as admin)
+- **KAM user details**: shown to the admin as **defaults for confirmation** before creation — the admin can edit **FirstName / LastName / Email**; the **username is auto-generated** (always containing `kam`) and the rest are fixed defaults (see the details reference)
+- **Stage-3 level-3 territory Id**: from `OrchestrationState.territoryId` — **MUST be the same territory used for `ProductTerritoryAvailability` in Stage 5**, or the KAM user sees no product/account data
+
+## Workflow
+
+### Phase A — Create the user
+
+1. Query the `LSC Custom Profile` Id.
+2. **Confirm the user details with the admin BEFORE creating.** Present the default/derived details as a table (see "Default User Details & Confirmation" in the details reference). The admin may edit **FirstName / LastName / Email**; the **username is auto-generated** (always containing `kam`) from the name, and the remaining fields are fixed defaults. If the admin edits the name, re-derive the username + alias and re-display. **Do NOT create the user until the admin confirms.**
+3. Create the user with the confirmed fields (username MUST contain `kam`, `IsActive=true`). Full field table, username rule, and error handling: **`references/stage-6-user-provisioning-details.md`**.
+4. Set the user's password with anonymous Apex, writing the temp file to a **project-local** relative path (never `/tmp`) and removing it right after — see the password section in the details reference.
+5. Capture the login URL (`sf org display`) for the credential handoff.
+
+### Phase B — Assign the four permission sets
+
+Assign **exactly four** permission sets:
+
+| Label | Expected API name |
+|-------|-------------------|
+| Health Cloud Starter | HealthCloudStarter |
+| Life Sciences Key Account Management | LifeSciencesKeyAccountManager |
+| Life Sciences Field Sales Representative | LifeSciencesFieldSalesRepresentative |
+| Life Sciences Core | LifeSciencesCore |
+
+Resolve the API names by label first (they may be namespace-prefixed) — see the details reference. Create a `PermissionSetAssignment` for each.
+
+> **STOP-GATE (permset count = 4).** After assigning, query the count filtered to non-profile-owned sets:
+> ```bash
+> sf data query --query "SELECT COUNT(Id) c FROM PermissionSetAssignment WHERE AssigneeId = '<userId>' AND PermissionSet.IsOwnedByProfile = false" --target-org <admin> --json
+> ```
+> This MUST return **exactly 4** (`{HealthCloudStarter, LifeSciencesKeyAccountManager, LifeSciencesFieldSalesRepresentative, LifeSciencesCore}`). More or fewer means the wrong sets were assigned — reconcile before proceeding.
+
+### Phase C — Territory assignment (user + admin)
+
+Assign **both** the KAM user and the admin to the Stage-3 level-3 territory via `UserTerritory2Association`. Confirm with the admin that this is the same territory used for `ProductTerritoryAvailability` in Stage 5. Field details + verification: the details reference.
+
+```bash
+sf data query --query "SELECT User.Name, User.Username, Territory2.Name FROM UserTerritory2Association WHERE Territory2Id = '<territoryId>'" --target-org <admin> --json
+```
+
+Expect ≥2 rows (KAM user + admin).
+
+### Phase D — Generate the mobile metadata cache
+
+Run entirely as the admin. Create the parent + child `LifeSciMobileMetadataRecord` (both `ValidationCompleted`), call the Connect API generate endpoint with `sf api request rest`, and poll until `Status='Active'`. Full commands, request body, and error table: **`references/stage-6-metadata-cache-generation.md`**.
+
+## Verification Gate
+
+```bash
+sf data query --query "SELECT Id, Username, Profile.Name, IsActive FROM User WHERE Username = '<username>'" --target-org <admin> --json
+sf data query --query "SELECT Id, Status FROM LifeSciMobileMetadataRecord ORDER BY LastModifiedDate DESC LIMIT 1" --target-org <admin> --json
+```
+
+Expect the user `IsActive=true` on `LSC Custom Profile`, permset count = 4, ≥2 territory rows, and a metadata record at `Status='Active'`.
+
+## Credential Handoff
+
+At the end, present the KAM username, the login URL, and the temporary password in the **single** credential-handoff summary. Do not print the password anywhere else.
+
+## Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Username MUST contain `kam` | KAM-user identification requirement |
+| Assign exactly 4 permission sets | KAM users get Health Cloud Starter + Life Sciences Key Account Management + Life Sciences Field Sales Representative + Life Sciences Core |
+| Assign the SAME level-3 territory used in Stage 5 | A mismatch hides all product/account data from the KAM user |
+| Assign BOTH the user and the admin to the territory | Admin visibility + user data access |
+| Write temp files (password Apex, mdgen body) project-local | Never `/tmp` or outside the project |
+| Deactivate, never delete, unwanted users | Deletion is unsafe; deactivation cascade-deletes territory associations |
+| Print the password only in the single credential-handoff summary | Credential hygiene |
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `references/stage-6-user-provisioning-details.md` | Phases A–C — user fields, username rule, permsets, password, territory, verification |
+| `references/stage-6-metadata-cache-generation.md` | Phase D — parent/child record creation + Connect API generate call + polling |

package/skills/life-sciences-kam-coordinate/references/state-machine-and-changes.md

@@ -0,0 +1,114 @@
+# Orchestration State Machine & Change Handling (KAM)
+
+Operational reference for `life-sciences-kam-coordinate`: the idempotent stage-transition rules, the mid-flow change-request impact assessment, and the resume/partial-re-run protocol. Read this alongside the workflow in `SKILL.md`.
+
+---
+
+## Idempotent Stage Transitions
+
+Stages are **not re-entrant**. If the user says "Proceed" or names a stage that is already running or completed, do NOT re-execute it.
+
+### Behavior Matrix
+
+| Current stage status | User says "Proceed" / "Run Stage N" | Response |
+|---|---|---|
+| `running` | Duplicate trigger | "Stage N is already in progress — I'll let you know when it completes." |
+| `passed` | Re-run request | "Stage N already completed successfully. Would you like to re-run it anyway? This is safe (all stages are idempotent) but will take extra time." |
+| `failed` | Retry request | Allow — re-run the stage (this is intentional recovery) |
+| `pending` | Advance request | Allow — normal forward progression |
+
+### Implementation Rules
+
+1. **Before executing any stage**, check its current `status` in `OrchestrationState`.
+2. **If `running`**: reply with the in-progress message and take no action. Do not queue a second execution.
+3. **If `passed`**: ask for explicit confirmation before re-running. Only re-run if the user says "yes, re-run it".
+4. **If `failed`**: treat as a retry — re-run without extra confirmation (the user is explicitly recovering).
+5. **Accidental double-confirms** (user says "yes" or "proceed" twice in quick succession) must never cause a stage to execute twice. The `status` field is the single source of truth — transition to `running` at the START of execution, not on user input.
+
+---
+
+## Mid-Flow Change Requests (Impact Assessment)
+
+If the user requests a change to inputs or decisions made in an earlier stage **while a later stage is in progress or pending**, perform an impact assessment before applying the change.
+
+### When This Applies
+
+- User wants to change the target org mid-flow
+- User wants to change territory names after territories were already deployed
+- User wants to change the KAM user's details after the profile/permsets were chosen
+- User wants to switch which layouts or flexipages were selected after deploy
+- User wants to change the ParticipantRole/Sprint, goal, or template names after they were created
+
+### Impact Assessment Protocol
+
+1. **Acknowledge the change request** without applying it immediately.
+
+2. **Identify affected stages** — determine which completed or in-progress stages would be impacted:
+
+   ```text
+   Change Request Impact Assessment
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+   Requested change: <describe the change>
+
+   Stages affected:
+     Stage <N>: <StageName> — <what would need to change/redo>
+     Stage <M>: <StageName> — <downstream impact>
+
+   Stages NOT affected:
+     Stage <X>: <StageName> — no impact
+
+   Estimated rework: <time/effort to re-do affected stages>
+   ```
+
+3. **Present options** to the user:
+   - **Apply change and re-run affected stages** — will undo/redo the impacted work
+   - **Apply change for remaining stages only** — keep what's done, apply change going forward (if possible without inconsistency)
+   - **Cancel the change** — continue with original inputs
+
+4. **Wait for user decision** before taking any action.
+
+### Impact Mapping
+
+| Change | Affects Stages | Re-run Required | Notes |
+|--------|--------------|-----------------|-------|
+| Target org | All stages | Yes — full restart | Nothing from prior org transfers |
+| Territory names | Stage 3, Stage 5, Stage 6 | Stage 3 re-deploy + Stage 5 re-associate + Stage 6 re-assign | Stage 5 `ProductTerritoryAvailability` and Stage 6 `UserTerritory2Association` both bind the level-3 territory; a new territory means re-doing both |
+| Layout/flexipage selection | Stage 2 only | Re-deploy updated profile + app | Does not affect Stages 3-6 |
+| KAM/Sprint config picklist values | Stage 2 only | Re-deploy config records | Upsert-safe |
+| ParticipantRole / Sprint name | Stage 4 only | Stage 4 only | Both are simple record creates |
+| Product / Account data | Stage 5 (Part A + Part B) | Stage 5 re-create + re-link | Part B `GoalDefinitionProduct` references the Part A `LifeSciMarketableProduct` |
+| Goal / template names | Stage 5 (Part B) only | Stage 5 (Part B) only | Un-publish is not possible — see destructive warnings |
+| User details (name, email, username) | Stage 6 only | Stage 6 only | Username must still contain `kam` |
+| Permission set list | Stage 6 only | Stage 6 only | Can add/remove assignments (target set is exactly 4) |
+
+### Destructive Change Warnings
+
+Some changes cannot be fully undone:
+
+| Change | Warning |
+|--------|---------|
+| Territory model already activated | "The territory model cannot be deleted once activated. A new model with a different name can be created, but the old one will remain." |
+| ActionPlanTemplate already published (Final) | "A published template version cannot be un-published. A new version (or a new template) can be created, but the Final version remains." |
+| User already created | "The existing user will remain. A new user with different details will be created as a separate record. Deactivate (never delete) any unwanted user; deactivation cascade-deletes its territory associations." |
+| Config records already deployed | "Config records are upsert-safe — re-deploying with changes will update existing records, not create duplicates." |
+
+Always surface these warnings as part of the impact assessment so the user makes an informed decision.
+
+---
+
+## Resume / Partial Re-run
+
+If the user has already completed some stages (e.g., from a prior session):
+
+1. Ask: "Have you already completed any of these stages?"
+2. For each claimed-complete stage, **verify** by querying the org:
+   - Stage 1: Ask user to confirm prerequisites are met
+   - Stage 2: Query for `LSC Custom Profile`
+   - Stage 3: Query for active territory model with level-3 territory
+   - Stage 4: Query for `ParticipantRole` (DeveloperName `Rep_Execution_Specialist`) + a `Sprint`
+   - Stage 5: Query for a `ProductTerritoryAvailability` (and Account) **and** a `Final` `ActionPlanTemplateVersion` + `ActionPlanTemplateAssignment`
+   - Stage 6: Query for the user with username containing `kam` on `LSC Custom Profile`
+3. Skip verified stages and resume from the first incomplete one.
+
+(The exact detection queries per stage are in `orchestration-flow.md` → Resume Logic.)

package/skills/life-sciences-prerequisites-validate/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: life-sciences-prerequisites-validate
+description: "Validate Life Sciences Cloud for Customer Engagement org prerequisites. Use when an admin needs to verify that all required settings, permissions, OWD sharing rules, and feature toggles are correctly configured before deploying Life Sciences Cloud. Checks user profile, permission sets, Life Sciences CE settings, surveys, OWD, inventory, account plans, care plans, Chatter, data protection, multi-currency, state/country picklists, and person accounts. Reports pass/fail for each check with remediation steps. TRIGGER when: user says 'check prerequisites', 'verify org setup for Life Sciences', 'LSC readiness check', 'pre-requisites for Life Sciences Cloud', 'validate org for LSC'. DO NOT TRIGGER when: user wants to automatically enable or configure these settings, or when the user asks for the full end-to-end Life Sciences Cloud setup / orchestration (that is the `life-sciences-fieldsalesrep-coordinate` orchestrator's job — this skill runs only as a standalone prerequisites check)."
+metadata:
+  version: "1.0"
+  minApiVersion: "65.0"
+  domains: ["Life Sciences"]
+  relatedSkills:
+    - life-sciences-fieldsalesrep-coordinate
+    - life-sciences-territory-configure
+  cliTools:
+    - tool: ["sf"]
+      semver: ">=2.0.0"
+---
+
+# Life Sciences Cloud Prerequisites Validation
+
+Validates that a Salesforce org meets all prerequisites for Life Sciences Cloud for Customer Engagement. Runs checks via the `sf` CLI against the currently authenticated org and produces a consolidated pass/fail report with remediation steps for any failures.
+
+## Scope
+
+- **In scope**: Validating org settings, user permissions, OWD sharing, and feature toggles required for Life Sciences Cloud CE
+- **Out of scope**: Automatically enabling or configuring settings that fail validation
+
+### Off-topic requests
+
+If the user asks for something unrelated to this skill (either at the start or mid-execution), do not attempt it. Tell the user you did not understand the request, then show what you *can* help with: validating Life Sciences Cloud org prerequisites (this skill), and — if relevant — point them to `life-sciences-territory-configure` for territory setup or `life-sciences-fieldsalesrep-coordinate` for the full end-to-end setup. Then stop and wait.
+
+---
+
+## Required Inputs
+
+Gather before proceeding:
+
+- **Target org**: The org alias or username to validate (from `sf config get target-org` or user-specified)
+- **Confirmation**: The logged-in user must be the admin whose profile and permission sets are being validated
+
+---
+
+## Workflow
+
+All checks run sequentially. Collect all results before presenting the final report.
+
+### Phase 1 — Validate Environment
+
+1. **Confirm org connection** — run `sf org display --target-org <org>` to verify the org is accessible. If it fails, stop and ask the user to authenticate.
+
+2. **Identify the logged-in user** — extract the username from the org display output.
+
+### Phase 2 — Run All Prerequisite Checks
+
+Run each check below. For each, record PASS or FAIL with the remediation steps. The checks use the canonical **Check 1 – Check 12** numbering from the reference files and the final report; the managed-package check is an un-numbered hard-stop gate, not one of the 12 scored categories. Checks 1–3 (and the managed-package gate) are in `references/checks-user-and-package.md`; Checks 4–12 are in `references/checks-org-settings.md`.
+
+> **STOP-GATE (report completeness).** Every check MUST produce a row in the final report — a check that errors (e.g. Multi-Currency returns HTTP 400 `INVALID_TYPE`, or an object isn't deployed) is a **FAIL row**, never a skipped/omitted row or a reason to abort the run. The report's row count MUST equal the full scored-check count (**12 categories**, Check 1 – Check 12). The **one** intended early exit is the managed-package gate (the un-numbered `lsc4ce` package check, step 4 below) — that legitimately stops the run with the "BLOCKED" message. In every other case, a query error is the FAIL signal: record it and continue. Do NOT let a single 4xx or unexpected-shape response silently drop a row or halt the sweep — a short report reads as "fewer things to fix" when the truth is "we didn't check."
+
+3. **Check 1 — user profile and permission sets** — read `references/checks-user-and-package.md` section "User Profile and Permission Sets" for the exact queries and validation logic.
+
+4. **Managed-package gate (un-numbered hard stop)** — read `references/checks-user-and-package.md` section "Managed Package Check". If the `lsc4ce` package is not installed, display the failure message and **stop** — do not proceed with remaining checks.
+
+5. **Check 2 — Life Sciences CE settings** — read `references/checks-user-and-package.md` section "Life Sciences Customer Engagement Setup" for the exact queries.
+
+6. **Check 3 — Surveys enabled** — read `references/checks-user-and-package.md` section "Surveys".
+
+7. **Check 4 — OWD sharing settings** — read `references/checks-org-settings.md` section "OWD Sharing" for the exact objects and expected values.
+
+8. **Check 5 — Inventory Count** — read `references/checks-org-settings.md` section "Inventory Count".
+
+9. **Check 6 — Sales Account Plans** — read `references/checks-org-settings.md` section "Sales Account Plans".
+
+10. **Check 7 — Care Plans** — read `references/checks-org-settings.md` section "Care Plans".
+
+11. **Check 8 — Chatter Settings** — read `references/checks-org-settings.md` section "Chatter Settings".
+
+12. **Check 9 — Data Protection and Privacy** — read `references/checks-org-settings.md` section "Data Protection and Privacy".
+
+13. **Check 10 — Multiple Currencies** — read `references/checks-org-settings.md` section "Multiple Currencies".
+
+14. **Check 11 — State and Country/Territory Picklists** — read `references/checks-org-settings.md` section "State and Country/Territory Picklists".
+
+15. **Check 12 — Person Accounts** — read `references/checks-org-settings.md` section "Person Accounts".
+
+### Phase 3 — Report
+
+16. **Generate consolidated report** — present results in a table:
+
+```markdown
+| # | Prerequisite                              | Status | Remediation (if failed/warning)  |
+|---|-------------------------------------------|--------|----------------------------------|
+| 1 | System Administrator + Permission Sets    | PASS/FAIL | <steps if failed>            |
+| 2 | Life Sciences CE Enabled                  | PASS/FAIL | <steps if failed>            |
+| ...                                                                                       |
+```
+
+Status values are **PASS**, **FAIL**, or **WARNING**. Most checks are PASS/FAIL. The **OWD Sharing** check (Check 4) is WARNING-level: when its values differ from the expected ones, report **WARNING** (with the recommended value in the remediation column), never FAIL — see `references/checks-org-settings.md` for the exact rule.
+
+Include a summary line: `X of 12 prerequisites passed. Y require action (Z warnings).`
+
+If all pass, confirm the org is ready for Life Sciences Cloud deployment.
+
+---
+
+## Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Run all checks even if early ones fail | Admin needs the full picture to remediate in one pass |
+| Use `sf` CLI with `--target-org` for every query | Ensures correct org context even with multiple orgs authenticated |
+| Never modify org settings | This skill validates only — it does not enable or configure anything |
+| Report exact Setup navigation paths | Admins need to know where to click in Setup UI |
+
+---
+
+## Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| Some settings are not queryable via Metadata API | Use Tooling API or org settings queries where Metadata API lacks coverage |
+| Person Accounts cannot be disabled once enabled | Only check if enabled; no rollback possible |
+| Multiple Currencies cannot be disabled once activated | Only check if activated; warn that this is irreversible if recommending enablement |
+| State/Country Picklists enabling is irreversible | Include this warning in remediation steps |
+
+---
+
+## Output Expectations
+
+Deliverables:
+- A formatted table showing pass/fail status for all 12 prerequisite categories
+- Remediation steps (Setup navigation paths and actions) for each failed check
+- Summary count of passed vs. failed checks
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `references/checks-user-and-package.md` | During Phase 2 (checks 3–6) — exact sf CLI commands, expected values, and remediation for the user profile/permission-set, managed-package, Life Sciences CE feature, and survey checks |
+| `references/checks-org-settings.md` | During Phase 2 (checks 7–15) — exact sf CLI commands, expected values, and remediation for the OWD sharing, inventory, account plans, care plans, chatter, data protection, currencies, picklists, and person-accounts checks |

package/skills/life-sciences-prerequisites-validate/references/checks-org-settings.md

@@ -0,0 +1,190 @@
+# Prerequisite Checks — Org-Level Sharing and Data Settings
+
+Covers the org-wide sharing and data-feature checks: OWD sharing, inventory count, sales account plans, care plans, chatter, data protection, multiple currencies, state/country picklists, and person accounts. For the user-access, managed-package, Life Sciences CE feature, and survey checks, see `checks-user-and-package.md`.
+
+Each section contains: the sf CLI command to run, how to interpret the result, and the remediation steps if the check fails.
+
+All Tooling API queries use `sf data query --target-org <org> --json --use-tooling-api`. Replace `<org>` with the target org alias.
+
+---
+
+## OWD Sharing
+
+### Check 4 — Organization-Wide Defaults
+
+Query OWD via `EntityDefinition` in the Tooling API:
+
+```bash
+sf data query --query "SELECT ExternalSharingModel, InternalSharingModel, QualifiedApiName FROM EntityDefinition WHERE QualifiedApiName IN ('Account','Case')" --target-org <org> --json --use-tooling-api
+```
+
+**Status: this is a WARNING-level check, not a hard FAIL.** OWD values are org-configuration preferences that depend on how Life Sciences Cloud is deployed. When they differ from the expected values below, record the row as **WARNING** (with the recommended value in the remediation column), not FAIL — do not block on it.
+
+**Expected values**:
+
+| Object | Expected InternalSharingModel | Expected ExternalSharingModel |
+|--------|-------------------------------|-------------------------------|
+| Account | Private | Private |
+| Case | Private | Private |
+
+> Note: In the API response, `Private` means "Private" OWD and `ReadWrite` means "Public Read/Write".
+
+**Remediation if the values differ (WARNING):**
+
+1. Navigate to **Setup > Security > Sharing Settings**
+2. Click **Edit** in the Organization-Wide Defaults section
+3. Recommended values:
+   - **Account**: Private
+   - **Case**: Private
+4. Click **Save**
+5. Confirm the changes when prompted (recalculation may take time)
+
+---
+
+## Inventory Count
+
+### Check 5 — Inventory Count Enabled
+
+**Field** (from IndustriesSettings Metadata): `enableVisitInventoryEnabled`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Inventory Management > Inventory Count Settings**
+2. Enable **Inventory Count**
+3. Click **Save**
+
+---
+
+## Sales Account Plans
+
+### Check 6 — Sales Account Plans Enabled
+
+**Field** (from IndustriesSettings Metadata): `enableLSC4CEKeyAccountManagement`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Sales > Accounts > Account Plans > Sales Account Plans**
+2. Toggle **Switch on Sales Account Plans** to enabled
+3. Click **Save**
+
+---
+
+## Care Plans
+
+### Check 7 — Care Plans Enabled
+
+**Field** (from IndustriesSettings Metadata): `enableCarePlansPreference`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Program and Case Management > Care Plan Settings**
+2. Enable **Care Plans**
+3. Click **Save**
+
+---
+
+## Chatter Settings
+
+### Check 8 — Chatter Enabled
+
+```bash
+sf data query --query "SELECT IsChatterEnabled FROM ChatterSettings" --target-org <org> --json --use-tooling-api
+```
+
+**Pass condition**: `IsChatterEnabled` is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Chatter > Chatter Settings**
+2. Enable **Chatter Settings**
+3. Click **Save**
+
+---
+
+## Data Protection and Privacy
+
+### Check 9 — Data Protection and Privacy Enabled
+
+```bash
+sf data query --query "SELECT Metadata FROM PartyDataModelSettings" --target-org <org> --json --use-tooling-api
+```
+
+**Field** (from Metadata): `enableConsentManagement`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Company Settings > Data Protection and Privacy**
+2. Enable **Data Protection and Privacy**
+3. Click **Save**
+
+---
+
+## Multiple Currencies
+
+### Check 10 — Multiple Currencies Activated
+
+```bash
+sf data query --query "SELECT Id FROM CurrencyType LIMIT 1" --target-org <org> --json
+```
+
+**Pass condition**: The query succeeds and returns at least one record. If the `CurrencyType` object is queryable, Multi-Currency is activated.
+
+**Alternative check**: If the above fails with `INVALID_TYPE`, Multi-Currency is NOT activated.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Company Settings > Company Information**
+2. Click **Edit**
+3. Check **Activate Multiple Currencies**
+4. Click **Save**
+5. Confirm the activation when prompted
+
+> **Warning**: Activating Multiple Currencies is irreversible. Include this warning when presenting remediation steps.
+
+---
+
+## State and Country/Territory Picklists
+
+### Check 11 — State and Country/Territory Picklists Enabled
+
+```bash
+sf data query --query "SELECT Metadata FROM AddressSettings" --target-org <org> --json --use-tooling-api
+```
+
+**Pass condition**: The `Metadata` response contains a `countriesAndStates` object with country data populated. If `countriesAndStates` is present and non-null, the feature is enabled.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Data > State and Country/Territory Picklists**
+2. Click **Enable** to enable state and country/territory picklists
+3. Follow the wizard to configure your picklist values
+
+> **Warning**: Enabling State and Country/Territory Picklists is irreversible. Include this warning when presenting remediation steps.
+
+---
+
+## Person Accounts
+
+### Check 12 — Person Accounts Enabled
+
+```bash
+sf data query --query "SELECT Id FROM RecordType WHERE SobjectType = 'Account' AND IsPersonType = true LIMIT 1" --target-org <org> --json
+```
+
+**Pass condition**: At least one record returned (a person-type RecordType exists on Account).
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Sales > Accounts > Person Accounts**
+2. Follow the steps to enable Person Accounts
+3. This requires Record Types to be enabled on Account first
+
+> **Warning**: Enabling Person Accounts is irreversible. Include this warning when presenting remediation steps.