@salesforce/afv-skills 1.45.0 → 1.47.0

package/skills/life-sciences-prerequisites-validate/references/checks-user-and-package.md

@@ -0,0 +1,211 @@
+# Prerequisite Checks — User, Package, and Feature Setup
+
+Covers the user-access, managed-package, Life Sciences CE feature, and survey checks. For the org-level sharing/data settings (OWD, inventory, account plans, care plans, chatter, data protection, currencies, picklists, person accounts), see `checks-org-settings.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.
+
+---
+
+## User Profile and Permission Sets
+
+### Check 1a — System Administrator Profile
+
+```bash
+sf data query --query "SELECT Profile.Name FROM User WHERE Username = '<username>'" --target-org <org> --json
+```
+
+**Pass condition**: `Profile.Name` equals `System Administrator`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Users > Users**
+2. Find the user and click **Edit**
+3. Change **Profile** to `System Administrator`
+4. Click **Save**
+
+### Check 1b — LifeSciencesCommercialAdmin Permission Set
+
+```bash
+sf data query --query "SELECT PermissionSet.Name FROM PermissionSetAssignment WHERE AssigneeId IN (SELECT Id FROM User WHERE Username = '<username>') AND PermissionSet.Name = 'LifeSciencesCommercialAdmin'" --target-org <org> --json
+```
+
+**Pass condition**: At least one record returned.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Users > Permission Sets**
+2. Find `LifeSciencesCommercialAdmin` and click on it
+3. Click **Manage Assignments**
+4. Click **Add Assignment**
+5. Select the admin user and click **Assign**
+
+### Check 1c — HealthCloudStarter Permission Set
+
+```bash
+sf data query --query "SELECT PermissionSet.Name FROM PermissionSetAssignment WHERE AssigneeId IN (SELECT Id FROM User WHERE Username = '<username>') AND PermissionSet.Name = 'HealthCloudStarter'" --target-org <org> --json
+```
+
+**Pass condition**: At least one record returned.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Users > Permission Sets**
+2. Find `HealthCloudStarter` and click on it
+3. Click **Manage Assignments**
+4. Click **Add Assignment**
+5. Select the admin user and click **Assign**
+
+---
+
+## Managed Package Check
+
+### Check — lsc4ce Package Installed
+
+Query the `InstalledSubscriberPackage` object via the Tooling API to list installed packages, then check client-side whether one has the namespace prefix `lsc4ce`:
+
+```bash
+sf data query --query "SELECT Id, SubscriberPackage.NamespacePrefix, SubscriberPackage.Name FROM InstalledSubscriberPackage" --target-org <org> --json --use-tooling-api
+```
+
+> **Do NOT add a `WHERE SubscriberPackage.NamespacePrefix = 'lsc4ce'` clause.** On `InstalledSubscriberPackage` the `SubscriberPackage.*` relationship fields are selectable but **not filterable** — a `WHERE` on them fails with `field 'SubscriberPackage' can not be filtered in query call`. Query all installed packages (there are only a handful) and inspect the results for the `lsc4ce` prefix in the agent, not in SOQL.
+
+**Pass condition**: At least one returned record has `SubscriberPackage.NamespacePrefix == 'lsc4ce'` (the Life Sciences Cloud for Customer Engagement package is installed).
+
+**If failed — STOP all remaining checks** and display:
+
+> **BLOCKED: Life Sciences Cloud managed package not installed.**
+>
+> The managed package with namespace prefix `lsc4ce` (Life Sciences Cloud for Customer Engagement) is not installed in this org. All remaining prerequisite checks depend on this package.
+>
+> **Remediation:**
+> 1. Obtain an org with the Life Sciences Cloud for Customer Engagement managed package installed
+> 2. The package is typically provisioned through OrgFarm or installed by Salesforce as part of the Life Sciences Cloud license
+> 3. Contact your Salesforce account team or provisioning admin to get an org with the `lsc4ce` package
+>
+> Re-run this validation after the package is installed.
+
+**Do not proceed with any further checks if this fails.**
+
+---
+
+## Life Sciences Customer Engagement Setup
+
+All Life Sciences CE settings are stored in `IndustriesSettings` via the Tooling API. Query once and check multiple fields:
+
+```bash
+sf data query --query "SELECT Metadata FROM IndustriesSettings" --target-org <org> --json --use-tooling-api
+```
+
+Parse the `Metadata` object from the first record in the response.
+
+### Check 2a — Life Sciences Customer Engagement Enabled
+
+**Field**: `enableLifeSciencesCustomerEngagementBase`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Toggle **Life Sciences Customer Engagement** to enabled
+3. Click **Save**
+
+### Check 2b — Enable Settings for Package Installation
+
+**Field** (from IndustriesSettings Metadata): `enableLSC4CEPackage`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Under **Get Your Org Ready to Use Life Sciences Cloud for Customer Engagement**
+3. Click the **Verify & Enable Settings** button under "Enable Settings for Package Installation"
+4. Wait for the verification to complete
+
+### Check 2c — Account-Based Sharing
+
+**Field** (from IndustriesSettings Metadata): `enableAccountBasedSharing`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Under **Enable Life Sciences Cloud for Customer Engagement Features**
+3. Enable **Account-Based Sharing**
+4. Click **Save**
+
+### Check 2d — Best Contact Time Custom Sharing
+
+**Field** (from IndustriesSettings Metadata): `enableCPBestConTimeSharing`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Under **Enable Life Sciences Cloud for Customer Engagement Features**
+3. Enable **Best Contact Time Custom Sharing**
+4. Click **Save**
+
+### Check 2e — Contact Point Social Custom Sharing
+
+**Field** (from IndustriesSettings Metadata): `enableCPSocialCustomSharing`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Under **Enable Life Sciences Cloud for Customer Engagement Features**
+3. Enable **Contact Point Social Custom Sharing**
+4. Click **Save**
+
+### Check 2f — Parent Territory Product Alignment
+
+**Field** (from IndustriesSettings Metadata): `enablePATSTerritoryBasedSharing`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Under **Enable Life Sciences Cloud for Customer Engagement Features**
+3. Enable **Parent Territory Product Alignment**
+4. Click **Save**
+
+### Check 2g — Product Hierarchy Business Group Filter
+
+**Field** (from IndustriesSettings Metadata): `enableProdAdminBusinessGrpFilter`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Life Sciences > Life Sciences for Customer Engagement Setup**
+2. Under **Enable Life Sciences Cloud for Customer Engagement Features**
+3. Enable **Product Hierarchy Business Group Filter**
+4. Click **Save**
+
+---
+
+## Surveys
+
+### Check 3 — Surveys Enabled
+
+```bash
+sf data query --query "SELECT Metadata FROM SurveySettings" --target-org <org> --json --use-tooling-api
+```
+
+**Field** (from Metadata): `enableSurvey`
+
+**Pass condition**: Value is `true`.
+
+**Remediation if failed**:
+
+1. Navigate to **Setup > Feature Settings > Survey > Survey Settings**
+2. Toggle **Surveys** to enabled
+3. Click **Save**

package/skills/life-sciences-territory-configure/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: life-sciences-territory-configure
+description: "Use this skill to create and activate a Territory Type, Territory Model, and Territories for Life Sciences Cloud. Trigger when the user says 'set up territories', 'create territory model', 'configure territory hierarchy for Life Sciences', 'territory setup for LSC', or 'create territories for Life Sciences Cloud'. Creates a Geographical territory type, an LSC Territory Model, and a 3-level territory hierarchy (Region, District, Territory). Confirms names with the user, shows a preview, then deploys and activates the model. DO NOT TRIGGER when: user wants to validate prerequisites, assign users to territories, create territory assignment rules, or run 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 territory setup)."
+metadata:
+  version: "1.0"
+  minApiVersion: "65.0"
+  domains: ["Life Sciences"]
+  relatedSkills:
+    - life-sciences-fieldsalesrep-coordinate
+    - life-sciences-prerequisites-validate
+  cliTools:
+    - tool: ["sf"]
+      semver: ">=2.0.0"
+---
+
+# Life Sciences Territory Setup
+
+Creates and activates a Territory Type, Territory Model, and a 3-level Territory hierarchy for Life Sciences Cloud using the `sf` CLI.
+
+## Scope
+
+- **In scope**: Creating territory type, territory model, and territories; activating the territory model
+- **Out of scope**: Assigning users to territories, creating territory assignment rules, validating prerequisites
+
+### 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: setting up Life Sciences Cloud territories (this skill), and — if relevant — point them to `life-sciences-prerequisites-validate` for prerequisite checks 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 deploy to (from `sf config get target-org` or user-specified)
+
+---
+
+## Workflow
+
+### Phase 1 — Present Default Names and Get Confirmation
+
+1. **Show the user the default names** that will be used for the territory components. Read `references/territory-metadata.md` for the exact XML templates and default names.
+
+Present the names in a table:
+
+```markdown
+| Component | Default Name |
+|-----------|-------------|
+| Territory Type | Geographical |
+| Territory Model | LSC Territory Model |
+| Territory (Level 1 - Region) | RD - West 20D |
+| Territory (Level 2 - District) | DM - San Francisco 20D02 |
+| Territory (Level 3 - Territory) | TM - SPC - San Francisco North 20D02T11 |
+```
+
+2. **Ask the user** if they are fine with these names or want to change any of them. Ask for each component individually:
+   - "Are you fine with the Territory Type name **'Geographical'** or would you like to change it?"
+   - "Are you fine with the Territory Model name **'LSC Territory Model'** or would you like to change it?"
+   - "Are you fine with the Region territory name **'RD - West 20D'** or would you like to change it?"
+   - "Are you fine with the District territory name **'DM - San Francisco 20D02'** or would you like to change it?"
+   - "Are you fine with the Territory name **'TM - SPC - San Francisco North 20D02T11'** or would you like to change it?"
+
+3. **If the user wants to change a name**, ask them for the new name they'd like to use. Record the updated name.
+
+### Phase 2 — Preview and Confirm
+
+4. **Display a complete preview** of what will be created, showing the final XML for each component with the confirmed names. Use the templates from `references/territory-metadata.md` and substitute any user-provided names.
+
+Show the preview in this format:
+
+```text
+=== Territory Type ===
+Name: <confirmed name>
+Priority: 1
+
+=== Territory Model ===
+Name: <confirmed model name>
+
+=== Territory Hierarchy ===
+Level 1 (Region): <confirmed region name>
+  └── Level 2 (District): <confirmed district name>
+        └── Level 3 (Territory): <confirmed territory name>
+
+Access Levels (all territories):
+- Account: Read
+- Contact: Edit
+- Case: None
+- Opportunity: None
+```
+
+5. **Ask for final confirmation**: "Ready to create and deploy these territory components? (yes/no)"
+
+If user says no, go back to Phase 1.
+
+### Phase 3 — Create and Deploy
+
+6. **Create a temporary SFDX project structure** for deployment. Read `references/territory-metadata.md` for the exact file structure and XML content.
+
+The directory structure must be:
+
+```text
+territory-deploy/
+├── sfdx-project.json
+└── force-app/
+    └── main/
+        └── default/
+            └── territory2Models/
+                ├── <ModelApiName>.territory2Model-meta.xml
+                └── <ModelApiName>/
+                    ├── territory2Types/
+                    │   └── <TypeApiName>.territory2Type-meta.xml
+                    └── territories/
+                        ├── <Level1ApiName>.territory2-meta.xml
+                        ├── <Level2ApiName>.territory2-meta.xml
+                        └── <Level3ApiName>.territory2-meta.xml
+```
+
+7. **Generate API names** from user-confirmed display names:
+   - Remove special characters, spaces, and hyphens
+   - Use PascalCase for the API name
+   - Territory type API name is derived from the type display name
+   - Territory model API name is derived from the model display name (remove spaces)
+   - Territory API names are derived from territory display names (remove spaces, hyphens, special chars)
+
+8. **Write the metadata files** using the templates from `references/territory-metadata.md` with confirmed names.
+
+9. **Deploy the metadata** using:
+   ```bash
+   sf project deploy start --source-dir territory-deploy/force-app --target-org <org>
+   ```
+
+10. **Check deployment status** — if it fails, show the error and suggest remediation.
+
+    > **STOP-GATE (component count).** The single deploy package must land the **complete** hierarchy: 1 Territory2Type + 1 Territory2Model + 3 Territory2 records (one Region, one District, one Territory). Confirm the deploy result reports **0 component failures** AND verify the territories exist before activating:
+    > ```bash
+    > sf data query --query "SELECT COUNT(Id) c FROM Territory2 WHERE Territory2Model.DeveloperName = '<ModelApiName>'" --target-org <org> --json
+    > ```
+    > The count MUST be 3. A parent-reference failure (e.g. the District deploying before its Region) can land a partial hierarchy — a Level-3 territory with no path to its Region silently breaks downstream user/visit territory assignment. Do NOT activate the model (Phase 4) until all 3 territories are present with 0 deploy failures.
+
+### Phase 4 — Activate Territory Model
+
+11. **Report that the model deployed in Planning state** and ask the user if they want to activate it. Include this warning:
+
+    > **Note:** Once a Territory Model is activated, it can be deactivated but **cannot be deleted**. Do you want to proceed with activation?
+
+12. **If the user confirms activation**, activate the model by querying its record ID then updating its State to `'Activating'` (not `'Active'` — the platform transitions asynchronously from Activating → Active):
+
+    ```bash
+    # Query the model ID and current state
+    sf data query --query "SELECT Id, State FROM Territory2Model WHERE DeveloperName = '<ModelApiName>' LIMIT 1" --target-org <org> --json
+    ```
+
+    If the model is in `Planning` state, update it:
+
+    ```bash
+    sf data update record --sobject Territory2Model --record-id <ModelId> --values "State='Activating'" --target-org <org>
+    ```
+
+    See `references/territory-metadata.md` for the full activation logic including error handling.
+
+13. **Verify activation** — the platform transitions asynchronously from `Activating` → `Active`. Query to confirm:
+    ```bash
+    sf data query --query "SELECT Id, DeveloperName, State FROM Territory2Model WHERE DeveloperName='<ModelApiName>'" --target-org <org>
+    ```
+    If still `Activating`, wait a moment and query again until it reaches `Active`.
+
+14. **If the user declines activation**, report that the model is in Planning state and can be activated later from Setup.
+
+15. **Report success** — confirm to the user that all components are created, and report the model's current state (`Planning`, `Activating`, or `Active`).
+
+---
+
+## Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Create exactly one territory per level — one Level-1 Region, one Level-2 District, one Level-3 Territory (3 territories total) | Skill produces a single representative hierarchy branch, not a fully populated multi-child tree |
+| Always confirm names before creating | User may want to customize territory names for their org |
+| Show preview before deploying | User should see exactly what will be created |
+| Deploy all components together | Territory hierarchy has dependencies (parent references) |
+| Warn user before activation that model cannot be deleted once active | Irreversible action — user must explicitly consent |
+| Set State to `'Activating'` (not `'Active'`) when updating the record | The platform handles the async transition from Activating → Active |
+| Target the update by `--record-id <ModelId>` or `--where "DeveloperName='<ModelApiName>'"` | Both forms work for `sf data update record`; use whichever is convenient |
+| Clean up temp directory after deploy | Don't leave deployment artifacts behind |
+
+---
+
+## Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| Territory model already exists with same name | Check first with a query; ask user if they want a different name |
+| Territory type already exists | Check first; reuse existing type if it matches |
+| Deploy fails due to parent territory not found | Ensure all territories are in the same deployment package |
+| Setting State to `'Active'` directly fails with `INVALID_STATUS` | Always set State to `'Activating'` — the platform transitions to Active asynchronously |
+| Model state shows `Activating` after update | This is normal — activation is async. Wait and re-query until `Active` |
+| API name conflicts | Ensure generated API names don't conflict with existing metadata |
+
+---
+
+## Output Expectations
+
+Deliverables:
+- Created Territory Type with confirmed name
+- Created Territory Model with confirmed name
+- Created 3-level territory hierarchy with confirmed names
+- Territory Model activated (or manual activation steps if programmatic activation fails)
+- Confirmation message showing all created components and their status
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `references/territory-metadata.md` | During all phases — contains XML templates, file structure, and default values for territory components |

package/skills/life-sciences-territory-configure/references/territory-metadata.md

@@ -0,0 +1,262 @@
+# Territory Metadata Templates
+
+## Default Names
+
+| Component | Display Name | Default API Name |
+|-----------|-------------|-----------------|
+| Territory Type | Geographical | Geographical |
+| Territory Model | LSC Territory Model | LSCTerritoryModel |
+| Territory (Level 1 - Region) | RD - West 20D | RDWest20D |
+| Territory (Level 2 - District) | DM - San Francisco 20D02 | DMSanFrancisco20D02 |
+| Territory (Level 3 - Territory) | TM - SPC - San Francisco North 20D02T11 | TMSPCSanFranciscoNorth20D02T11 |
+
+---
+
+## File Structure
+
+```text
+territory-deploy/
+├── sfdx-project.json
+└── force-app/
+    └── main/
+        └── default/
+            └── territory2Models/
+                ├── <ModelApiName>.territory2Model-meta.xml
+                └── <ModelApiName>/
+                    ├── territory2Types/
+                    │   └── <TypeApiName>.territory2Type-meta.xml
+                    └── territories/
+                        ├── <Level1ApiName>.territory2-meta.xml
+                        ├── <Level2ApiName>.territory2-meta.xml
+                        └── <Level3ApiName>.territory2-meta.xml
+```
+
+---
+
+## sfdx-project.json
+
+```json
+{
+  "packageDirectories": [
+    {
+      "path": "force-app",
+      "default": true
+    }
+  ],
+  "namespace": "",
+  "sfdcLoginUrl": "https://login.salesforce.com",
+  "sourceApiVersion": "65.0"
+}
+```
+
+---
+
+## Territory Type XML Template
+
+File: `force-app/main/default/territory2Models/<ModelApiName>/territory2Types/<TypeApiName>.territory2Type-meta.xml`
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<Territory2Type xmlns="http://soap.sforce.com/2006/04/metadata">
+    <name>Geographical</name>
+    <priority>1</priority>
+</Territory2Type>
+```
+
+### Fields
+
+| Field | Default Value | Description |
+|-------|--------------|-------------|
+| `<name>` | Geographical | Display name of the territory type |
+| `<priority>` | 1 | Priority ranking (1 = highest) |
+
+---
+
+## Territory Model XML Template
+
+File: `force-app/main/default/territory2Models/<ModelApiName>.territory2Model-meta.xml`
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<Territory2Model xmlns="http://soap.sforce.com/2006/04/metadata">
+    <name>LSC Territory Model</name>
+</Territory2Model>
+```
+
+### Fields
+
+| Field | Default Value | Description |
+|-------|--------------|-------------|
+| `<name>` | LSC Territory Model | Display name of the territory model |
+
+---
+
+## Territory XML Templates
+
+All territories go under: `force-app/main/default/territory2Models/<ModelApiName>/territories/`
+
+### Level 1 — Region (Top-level territory)
+
+File: `<Level1ApiName>.territory2-meta.xml`
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<Territory2 xmlns="http://soap.sforce.com/2006/04/metadata">
+    <accountAccessLevel>Read</accountAccessLevel>
+    <caseAccessLevel>None</caseAccessLevel>
+    <contactAccessLevel>Edit</contactAccessLevel>
+    <name>RD - West 20D</name>
+    <opportunityAccessLevel>None</opportunityAccessLevel>
+    <territory2Type>Geographical</territory2Type>
+</Territory2>
+```
+
+### Level 2 — District (Child of Region)
+
+File: `<Level2ApiName>.territory2-meta.xml`
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<Territory2 xmlns="http://soap.sforce.com/2006/04/metadata">
+    <accountAccessLevel>Read</accountAccessLevel>
+    <caseAccessLevel>None</caseAccessLevel>
+    <contactAccessLevel>Edit</contactAccessLevel>
+    <name>DM - San Francisco 20D02</name>
+    <opportunityAccessLevel>None</opportunityAccessLevel>
+    <parentTerritory>RDWest20D</parentTerritory>
+    <territory2Type>Geographical</territory2Type>
+</Territory2>
+```
+
+### Level 3 — Territory (Child of District)
+
+File: `<Level3ApiName>.territory2-meta.xml`
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<Territory2 xmlns="http://soap.sforce.com/2006/04/metadata">
+    <accountAccessLevel>Read</accountAccessLevel>
+    <caseAccessLevel>None</caseAccessLevel>
+    <contactAccessLevel>Edit</contactAccessLevel>
+    <name>TM - SPC - San Francisco North 20D02T11</name>
+    <opportunityAccessLevel>None</opportunityAccessLevel>
+    <parentTerritory>DMSanFrancisco20D02</parentTerritory>
+    <territory2Type>Geographical</territory2Type>
+</Territory2>
+```
+
+### Territory Access Levels
+
+| Field | Value | Description |
+|-------|-------|-------------|
+| `<accountAccessLevel>` | Read | Read access to accounts in territory |
+| `<caseAccessLevel>` | None | No case access |
+| `<contactAccessLevel>` | Edit | Edit access to contacts in territory |
+| `<opportunityAccessLevel>` | None | No opportunity access |
+
+### Territory Hierarchy Relationships
+
+| Territory | Parent | Level |
+|-----------|--------|-------|
+| RDWest20D | (none - top level) | 1 - Region |
+| DMSanFrancisco20D02 | RDWest20D | 2 - District |
+| TMSPCSanFranciscoNorth20D02T11 | DMSanFrancisco20D02 | 3 - Territory |
+
+---
+
+## API Name Generation Rules
+
+When the user provides a custom display name, derive the API name as follows:
+
+1. Remove all special characters (hyphens, periods, commas, parentheses)
+2. Remove all spaces
+3. Ensure it starts with a letter
+4. Use only alphanumeric characters
+5. Keep it concise but recognizable
+
+Examples:
+- "RD - West 20D" → `RDWest20D`
+- "DM - San Francisco 20D02" → `DMSanFrancisco20D02`
+- "LSC Territory Model" → `LSCTerritoryModel`
+- "Geographical" → `Geographical`
+
+---
+
+## Deployment Commands
+
+### Deploy all territory metadata
+
+```bash
+sf project deploy start --source-dir territory-deploy/force-app --target-org <org>
+```
+
+### Activate the territory model
+
+The activation uses `sf data update record` to set State to `'Activating'` (NOT `'Active'`). The platform handles the async transition from Activating → Active.
+
+> **Warning to present to user before activation:** Once a Territory Model is activated, it can be deactivated but **cannot be deleted**.
+
+**Step 1 — Query the model ID and current state:**
+
+```bash
+sf data query \
+    --query "SELECT Id, State FROM Territory2Model WHERE DeveloperName = '<ModelApiName>' LIMIT 1" \
+    --target-org <org> \
+    --json
+```
+
+Parse the result to extract the record `Id` and `State`. If the model is not found, report an error.
+
+**Step 2 — If State is `Planning`, update to `Activating`:**
+
+By record ID:
+
+```bash
+sf data update record \
+    --sobject Territory2Model \
+    --record-id <ModelId> \
+    --values "State='Activating'" \
+    --target-org <org>
+```
+
+Or target by DeveloperName with `--where` (verified equivalent — no record ID lookup needed):
+
+```bash
+sf data update record \
+    --sobject Territory2Model \
+    --where "DeveloperName='<ModelApiName>'" \
+    --values "State=Activating" \
+    --target-org <org>
+```
+
+**Important:** Use `State=Activating` — setting to `'Active'` directly will fail with `INVALID_STATUS: A territory model cannot change from the Planning state to the Active state`. The platform advances Activating → Active on its own once the async job completes.
+
+**Step 3 — If the update succeeds**, report activation initiated. The model will transition asynchronously to `Active`.
+
+**Step 4 — If the model is NOT in `Planning` state** (e.g. already `Active` or `Activating`), report the current state and take no action.
+
+### Verify activation
+
+```bash
+sf data query --query "SELECT Id, DeveloperName, State FROM Territory2Model WHERE DeveloperName='<ModelApiName>'" --target-org <org>
+```
+
+Report the returned `State`. If it is `Activating`, wait and query again until it reaches `Active`.
+
+---
+
+## Pre-deployment Checks
+
+Before deploying, verify:
+
+1. No existing territory model with the same DeveloperName:
+   ```bash
+   sf data query --query "SELECT Id, DeveloperName, State FROM Territory2Model WHERE DeveloperName='<ModelApiName>'" --target-org <org>
+   ```
+
+2. No existing territory type with the same DeveloperName:
+   ```bash
+   sf data query --query "SELECT Id, DeveloperName FROM Territory2Type WHERE DeveloperName='<TypeApiName>'" --target-org <org>
+   ```
+
+If either exists, inform the user and ask if they want to use a different name or reuse the existing component.