@salesforce/afv-skills 1.45.0 → 1.47.0

package/skills/life-sciences-kam-coordinate/references/stage-2-starter-config-trigger-handlers.md

@@ -0,0 +1,123 @@
+# Trigger Handlers Reference
+
+## Handler List
+
+The following trigger handlers must be activated:
+
+1. AffiliationUniquenessGenericHandler
+2. AffiliationUniquenessHandler
+3. HardAffiliationHandler
+4. AffiliationReciprocalHandler
+5. HealthcareProviderAffiliationHandler
+6. AffiliationPrimaryChangeHandler
+7. AffiliationAccountUpdateHandler
+8. TerrAcctRcmdActionSharingHandler
+9. TerrAccRcmActStatusUpdateHandler
+10. CaseMSLQueueHandler
+11. CaseChangeOwnershipHandler
+12. CaseShareToCreatorHandler
+13. StagePathPermissionsHandler
+14. AccountPlanDeleteChildrenHandler
+15. AccountPlanChangeStatusHandler
+16. SetAccPlanPercentCompleteHandler
+17. AcctPlanObjDeleteChildrenHandler
+18. SetAccObjectPercentCompleteHandler
+19. ActionPlanDeleteChildrenHandler
+20. SetSprintPercentCompleteHandler
+21. SetGoalAsgmtPercentCompleteHandler
+22. SetActionPlanPercentCompleteHandler
+23. AssessmentTaskDeleteAPItemHandler
+24. AssessmentTaskSharingHandler
+25. TerritoryBusinessPlanDeleteHandler
+26. GoalAssignmentDeleteHandler
+27. TerritoryBusPlanChangeStatusHandler
+28. SetTerrBusPlanPrcntCompleteHandler
+
+## Activation Method
+
+Trigger handlers in Life Sciences Cloud are **`LifeScienceTriggerHandler`** records — a standard Tooling API entity (NOT a managed `lsc4ce__TriggerHandler__c` custom object). All queries and updates MUST use `--use-tooling-api`. Relevant fields:
+
+- `DeveloperName` — the handler name (e.g. `AffiliationUniquenessGenericHandler`)
+- `IsActive` — the active flag (Boolean)
+- `ObjectApiName` — the object the handler runs on
+
+> **Verified behavior:** the standard-API sobject name `lsc4ce__TriggerHandler__c` does NOT exist and returns `sObject type '...' is not supported`. `LifeScienceTriggerHandler` is only accessible via the Tooling API. A freshly-deployed org typically has ~185 handlers, all `IsActive=false` initially; the 28 below are the subset the starter config activates.
+
+### Preferred: Query then Update (Tooling API)
+
+First, get the handler's Id and current state:
+```bash
+sf data query --query "SELECT Id, DeveloperName, IsActive FROM LifeScienceTriggerHandler WHERE DeveloperName = '<HandlerName>'" --target-org <org> --use-tooling-api --json
+```
+
+Then activate by Id:
+```bash
+sf data update record --sobject LifeScienceTriggerHandler --record-id <Id> --values "IsActive=true" --target-org <org> --use-tooling-api
+```
+
+### Batch: query all inactive IDs in one call, then update each
+
+Individual query-then-update per handler is slow (each `sf` invocation has startup overhead; 28 sequential handlers can exceed 2 minutes). Fetch all still-inactive IDs in ONE query, then loop the updates.
+
+> **STOP-GATE (do not drop the last handler).** Build the update loop so it processes **every** returned ID. Two failure modes to avoid: **(1)** a naive `while read` over a *captured* ID list drops the final ID when that list has no trailing newline (the classic "27 of 28" bug); **(2)** an unquoted `for id in $IDS` loop relies on **bash word-splitting**, which **zsh does NOT do by default** — under zsh the whole multiline blob stays a single `$id`, every update fails on an invalid record-id, and you get **"0 of 28"**. Do NOT use either. The portable, shell-agnostic, drop-safe pattern is to pipe `jq` (which newline-terminates every record, including the last) into `while IFS= read -r id` via **process substitution** `< <(...)`: it behaves identically in bash and zsh and keeps the loop in the current shell so the counter survives. After the loop, always re-run the Verification query below and confirm the active count equals the full handler count (28) before proceeding — if it is short, identify the straggler(s) by name and activate each individually.
+
+Use a single query filtered to `IsActive = false` (already-active handlers are skipped automatically — re-running is safe but wasteful), then loop with one of the safe patterns:
+
+```bash
+ORG=<org>
+n=0; total=0
+# Pipe jq (newline-terminates EVERY record, incl. the last) into `while read` via
+# process substitution `< <(...)`. Portable across bash AND zsh; the loop stays in the
+# current shell so $n/$total survive. Never `for id in $IDS` (zsh won't word-split it).
+while IFS= read -r id; do
+  total=$((total+1))
+  sf data update record --sobject LifeScienceTriggerHandler --record-id "$id" \
+    --values "IsActive=true" --target-org "$ORG" --use-tooling-api >/dev/null && n=$((n+1))
+  echo "  ...$n activated"
+done < <(sf data query \
+  --query "SELECT Id FROM LifeScienceTriggerHandler WHERE IsActive = false AND DeveloperName IN ('AffiliationUniquenessGenericHandler','AffiliationUniquenessHandler','HardAffiliationHandler','AffiliationReciprocalHandler','HealthcareProviderAffiliationHandler','AffiliationPrimaryChangeHandler','AffiliationAccountUpdateHandler','TerrAcctRcmdActionSharingHandler','TerrAccRcmActStatusUpdateHandler','CaseMSLQueueHandler','CaseChangeOwnershipHandler','CaseShareToCreatorHandler','StagePathPermissionsHandler','AccountPlanDeleteChildrenHandler','AccountPlanChangeStatusHandler','SetAccPlanPercentCompleteHandler','AcctPlanObjDeleteChildrenHandler','SetAccObjectPercentCompleteHandler','ActionPlanDeleteChildrenHandler','SetSprintPercentCompleteHandler','SetGoalAsgmtPercentCompleteHandler','SetActionPlanPercentCompleteHandler','AssessmentTaskDeleteAPItemHandler','AssessmentTaskSharingHandler','TerritoryBusinessPlanDeleteHandler','GoalAssignmentDeleteHandler','TerritoryBusPlanChangeStatusHandler','SetTerrBusPlanPrcntCompleteHandler')" \
+  --target-org "$ORG" --use-tooling-api --json | jq -r '.result.records[].Id')
+echo "Activated $n of $total inactive handler(s)."
+```
+
+If every one of the 28 was already active, the query returns zero rows and the loop is a no-op — that is a valid PASS, not a failure.
+
+### Verification
+
+After activation, confirm the active count equals the full handler count (28) — count directly rather than eyeballing rows:
+```bash
+sf data query --query "SELECT COUNT(Id) active FROM LifeScienceTriggerHandler WHERE IsActive = true AND DeveloperName IN ('AffiliationUniquenessGenericHandler','AffiliationUniquenessHandler','HardAffiliationHandler','AffiliationReciprocalHandler','HealthcareProviderAffiliationHandler','AffiliationPrimaryChangeHandler','AffiliationAccountUpdateHandler','TerrAcctRcmdActionSharingHandler','TerrAccRcmActStatusUpdateHandler','CaseMSLQueueHandler','CaseChangeOwnershipHandler','CaseShareToCreatorHandler','StagePathPermissionsHandler','AccountPlanDeleteChildrenHandler','AccountPlanChangeStatusHandler','SetAccPlanPercentCompleteHandler','AcctPlanObjDeleteChildrenHandler','SetAccObjectPercentCompleteHandler','ActionPlanDeleteChildrenHandler','SetSprintPercentCompleteHandler','SetGoalAsgmtPercentCompleteHandler','SetActionPlanPercentCompleteHandler','AssessmentTaskDeleteAPItemHandler','AssessmentTaskSharingHandler','TerritoryBusinessPlanDeleteHandler','GoalAssignmentDeleteHandler','TerritoryBusPlanChangeStatusHandler','SetTerrBusPlanPrcntCompleteHandler')" --target-org <org> --use-tooling-api --json
+```
+The returned `active` count MUST be **28**. If it is fewer, list the still-inactive names (query the same set with `IsActive = false`), activate each straggler individually, and re-run this count until it reads 28. Do NOT proceed to the next step while any handler is inactive.
+
+### Error Handling
+
+| Error | Cause | Resolution |
+|-------|-------|------------|
+| `sObject type 'lsc4ce__TriggerHandler__c' is not supported` | Wrong object name / missing tooling flag | Use `LifeScienceTriggerHandler` with `--use-tooling-api` |
+| "No records found" | Handler `DeveloperName` doesn't exist in the org | The managed package may not have created it yet; skip and note |
+| Command times out activating all 28 | Sequential per-handler `sf` calls are slow | Fetch all inactive IDs in one query, then loop updates (see the safe-loop patterns above); skip already-active ones |
+| "27 of 28 activated" / last handler skipped | A `while read` over a *captured* list dropped the final unterminated line | Use the jq-piped `while IFS= read -r` via process substitution shown above; re-run the count check and activate any straggler individually |
+| "0 of 28 activated" (loop ran once, all IDs mashed into one value) | An unquoted `for id in $IDS` loop under **zsh**, which does not word-split unquoted params — `$IDS` stayed one multiline string | Use the jq-piped `while IFS= read -r` via process substitution shown above (portable across bash/zsh); never rely on `for` word-splitting |
+| "Insufficient access" | User lacks edit permission on the tooling entity | User needs appropriate permission set |
+
+### Progress Reporting
+
+Report activation progress:
+```text
+Activating trigger handlers: 15/28 complete...
+```
+
+If any handler fails, collect all failures and report at the end:
+```text
+3 handlers could not be activated:
+  - CaseMSLQueueHandler: No record found
+  - StagePathPermissionsHandler: Field not found
+  - AssessmentTaskSharingHandler: Insufficient access
+
+25/28 handlers activated successfully.
+Options:
+  1. Retry failed handlers
+  2. Skip and continue to next step
+```
+</content>

package/skills/life-sciences-kam-coordinate/references/stage-4-participant-role-and-sprint.md

@@ -0,0 +1,89 @@
+# Stage 4 — Participant Role & Sprint (KAM)
+
+Creates two records that later KAM stages depend on: a `ParticipantRole` (used by Account Plan participation) and a `Sprint` (the execution window for the KAM plan). Run entirely as the **admin** (`--target-org <admin>`). This is Stage 4 of `life-sciences-kam-coordinate`; the coordinator invokes it after territories (Stage 3) are active.
+
+Only the **name** of each record is shown to and confirmed with the admin (accept the default or supply a different name). Every other field is auto-derived and kept **internal — do NOT display it to the admin.**
+
+---
+
+## Record 1 — ParticipantRole
+
+**Show the admin only the "Participant Role Name"** (default `Rep Execution Specialist`) and ask them to accept the default or supply a different name. This name is stored internally in the `MasterLabel` field — do **NOT** surface the field name "MasterLabel" to the admin, and do **NOT** show any of the internal fields below.
+
+| Field | Value | Shown to admin? |
+|-------|-------|-----------------|
+| `MasterLabel` | the confirmed name, e.g. `Rep Execution Specialist` | Shown **as "Participant Role Name"** (never as "MasterLabel") |
+| `DeveloperName` | derived from the name: replace spaces with `_`, e.g. `Rep_Execution_Specialist` | Internal — not shown |
+| `IsActive` | `true` | Internal — not shown |
+| `ParentObject` | `AccountPlan` | Internal — not shown |
+| `DefaultAccessLevel` | `Edit` | Internal — not shown |
+
+> **DeveloperName derivation:** take the confirmed Participant Role Name and replace every space with `_` (e.g. `Rep Execution Specialist` → `Rep_Execution_Specialist`). Compute it internally; never ask the admin for it.
+
+```bash
+sf data create record --sobject ParticipantRole --target-org <admin> \
+  --values "MasterLabel='Rep Execution Specialist' DeveloperName=Rep_Execution_Specialist IsActive=true ParentObject=AccountPlan DefaultAccessLevel=Edit" --json
+```
+
+> `ParticipantRole` may be a Metadata/Tooling-backed entity in some orgs. If `sf data create record` reports the sObject is not createable via the data API, create it with the Tooling API (`--use-tooling-api`) or as metadata; the field values above are unchanged. Verify with a Tooling query if the standard query returns nothing.
+
+### Verify
+
+```bash
+sf data query --query "SELECT Id, MasterLabel, DeveloperName, IsActive, ParentObject, DefaultAccessLevel FROM ParticipantRole WHERE DeveloperName = 'Rep_Execution_Specialist'" --target-org <admin> --json
+```
+
+Expect exactly 1 record with `IsActive=true`. Capture its Id in `OrchestrationState`.
+
+---
+
+## Record 2 — Sprint
+
+Dates are relative to the run date. Compute them from the current date at run time — do **not** hardcode a date.
+
+**Before creation, show the admin only the Sprint Name** (default `Sprint 1 – Immunexis P&T Prep`) and ask them to accept the default or supply a different name. Do **NOT** show the dates or `Status` before creation.
+
+| Field | Value | Shown to admin? |
+|-------|-------|-----------------|
+| `Name` | the confirmed name, e.g. `Sprint 1 – Immunexis P&T Prep` | Shown before creation (accept default or change) |
+| `EffectiveStartDate` | Today (run date) | Internal — not shown before creation |
+| `EffectiveEndDate` | Start + 2 weeks (14 days) | Internal — not shown before creation |
+| `Status` | `Not Started` | Internal — not shown before creation |
+
+> **After the Sprint is created, display** its `Name`, Start Date, End Date, and Status to the admin — a post-creation summary. This is the only point at which the dates and `Status` are shown.
+
+Derive the dates so the two-week window is exact:
+
+```bash
+START=$(date +%F)
+END=$(date -v+14d +%F 2>/dev/null || date -d "+14 days" +%F)   # macOS / GNU date
+sf data create record --sobject Sprint --target-org <admin> \
+  --values "Name='Sprint 1 – Immunexis P&T Prep' EffectiveStartDate=$START EffectiveEndDate=$END Status='Not Started'" --json
+```
+
+> The em dash in the name (`–`, U+2013) is intentional — keep it as written. Wrap the value in single quotes so the shell preserves it.
+
+### Verify
+
+```bash
+sf data query --query "SELECT Id, Name, EffectiveStartDate, EffectiveEndDate, Status FROM Sprint ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+```
+
+Expect the sprint with `Status='Not Started'` and a 14-day window. Capture its Id.
+
+---
+
+## Confirmation Before Creating
+
+For **each** record, show the admin **only its name** — the Participant Role Name and the Sprint Name — and ask them to accept the default or supply a different one. Do **NOT** show the internal/auto-derived fields (`DeveloperName`, `IsActive`, `ParentObject`, `DefaultAccessLevel`, the Sprint dates, `Status`) before creating. After the Sprint is created, display its `Name`, Start Date, End Date, and Status as a post-creation summary.
+
+---
+
+## Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| `date -v+14d` fails | That is BSD/macOS syntax; on GNU/Linux use `date -d "+14 days" +%F` (the command above tries both) |
+| `DUPLICATE_DEVELOPER_NAME` on ParticipantRole | The role already exists (idempotent re-run) — query it and reuse rather than treating as an error |
+| Em dash mangled in the Sprint name | Ensure the terminal/locale is UTF-8 and the value is single-quoted; re-create if it landed as `?` or `-` |
+| `Status` rejected | The value must match the `SprintStatus` StandardValueSet confirmed in Stage 2 — `Not Started` is the default entry |

package/skills/life-sciences-kam-coordinate/references/stage-5-data-and-plan-templates-overview.md

@@ -0,0 +1,337 @@
+# Stage 5 — KAM Data & Plan Templates
+
+This single stage creates all the KAM master data **and** the plan templates that back the account plan, all as the **admin** (`--target-org <admin>`). This is Stage 5 of `life-sciences-kam-coordinate`; the coordinator invokes it after the participant role and sprint (Stage 4) exist and the territories (Stage 3) are active.
+
+The stage runs in two parts, in order:
+
+- **Part A — KAM Data Creation**: the account, provider, address, territory-association, and product master data (from the starter-config CSVs + an explicit HCO account bundle).
+- **Part B — Goals, Tasks, Measures & Action Plan Template**: the goal definitions, goal-product link, and the published, assigned action-plan template.
+
+Part B links to the `LifeSciMarketableProduct` created in Part A, so run Part A first and capture its Ids.
+
+## Stage Scope
+
+- **In scope**: Part A objects (Account, HealthcareProvider, ContactPointAddress, ObjectTerritory2Association, ProviderAcctTerritoryInfo, Product2, LifeSciMarketableProduct, ProductTerritoryAvailability — **plus an HCO account bundle**) and Part B records (2 `GoalDefinition`, 1 `GoalDefinitionProduct`, 1 `ActionPlanTemplate` + auto `ActionPlanTemplateVersion`, 3 `ActionPlanTemplateItem`, 6 `ActionPlanTemplateItemValue`, publishing the version → Final, 1 `ActionPlanTemplateAssignment`, and the leaf-territory shares — 2 `GoalDefinitionShare` + 1 `ActionPlanTemplateShare` + 2 `ProviderAcctTerritoryInfoShare`)
+- **Out of scope**: the Visit chain (not created in the KAM workflow), user provisioning + mobile metadata cache (Stage 6)
+
+## Everything runs as the ADMIN
+
+Unlike the field-sales-rep workflow, the KAM workflow creates **all** data as the **admin** (`--target-org <admin>`). The end user is not provisioned until Stage 6, so there is no rep to log in as and no rep/admin split. There is also **no manual iPad validation step** here — mobile metadata generation belongs to Stage 6.
+
+## Required Inputs
+
+- **Target org / admin**: the admin alias or username
+- **Stage-3 level-3 territory Id**: captured by the coordinator in `OrchestrationState.territoryId` — used for `ObjectTerritory2Association`, `ProviderAcctTerritoryInfo`, and `ProductTerritoryAvailability`. This MUST be the same territory later assigned to the KAM user in Stage 6.
+
+## Source folder
+
+All Part A CSVs come from `.lsc-starter-config/LSStarterConfig/Data/`. This stage is a pure consumer of the shared folder — it MUST NOT download or delete it (the coordinator owns the single download and delete). If the folder is absent, stop and report it must be provisioned by the coordinator.
+
+---
+
+# Part A — KAM Data Creation
+
+## Workflow
+
+1. **Read the live CSV for each object** — never hardcode values from the reference table. Full field-by-field mapping: `references/stage-5-data-creation-data.md`.
+2. **Create the records in dependency order**, capturing each returned Id for downstream foreign keys:
+
+   ```text
+   HCP Account → HealthcareProvider → ContactPointAddress
+               → ObjectTerritory2Association → ProviderAcctTerritoryInfo
+   HCO Account (Partners Healthcare) → HealthcareProvider → ContactPointAddress
+               → ObjectTerritory2Association → ProviderAcctTerritoryInfo
+   Product2 → LifeSciMarketableProduct → ProductTerritoryAvailability
+   ```
+
+   > The **HCO account bundle** (`Partners Healthcare` Account, its HealthcareProvider, ContactPointAddress, ObjectTerritory2Association, and ProviderAcctTerritoryInfo) uses explicit values, not the CSVs — both the Account and the HealthcareProvider use the `Health_Care_Organization` record type (query the RecordType Id by `DeveloperName`+`SobjectType` first). The HCO ContactPointAddress reuses the CSV address values with `ParentId` = the HCO Account, and the HCO OT2A/PATI reuse the CSV field values against the HCO Account and the **same Stage-3 level-3 territory**. See `references/stage-5-data-creation-data.md`.
+
+   Use `sf data create record --sobject <Object> --target-org <admin> --values "..." --json` for each, or a small tree/import if you prefer. Substitute the captured FK Ids and the Stage-3 `territoryId` where the reference marks a foreign key.
+3. **Capture the `LifeSciMarketableProduct` Id and the `Account` Id** in `OrchestrationState` — Part B links `GoalDefinitionProduct.ProductId` to the LifeSciMarketableProduct.
+
+## Part A Verification Gate
+
+```bash
+sf data query --query "SELECT Id FROM Account ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+sf data query --query "SELECT Id FROM LifeSciMarketableProduct ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+sf data query --query "SELECT Id, ProductId, TerritoryId FROM ProductTerritoryAvailability ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+```
+
+All three must return a record, and the `ProductTerritoryAvailability.TerritoryId` must equal the Stage-3 `territoryId`.
+
+## Part A Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Create everything as the admin | No end user exists until Stage 6 |
+| Do NOT create the Visit chain | KAM workflow has no visit data |
+| Read the live CSV; never hardcode | CSV values may change between runs |
+| Use the Stage-3 level-3 territory for all three territory FKs | The KAM user (Stage 6) is assigned this same territory; a mismatch hides all data |
+| Do NOT download or delete `.lsc-starter-config/` | Owned by the coordinator |
+
+## Part A Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| `ProductTerritoryAvailability` created against the wrong territory | Re-create with `TerritoryId` = the Stage-3 `territoryId` (the one Stage 6 assigns to the user) |
+| Product2 create fails on `RecordTypeId` | Do NOT set `RecordTypeId` on Product2 — it takes no record type |
+| A create fails on an FLS-gated field | As admin this is rare; omit the offending non-required field and continue (see the per-object notes in the data reference) |
+| `INVALID_CROSS_REFERENCE_KEY` on an FK | The parent record Id wasn't captured — re-query the parent and retry |
+
+---
+
+# Part B — Goals, Tasks, Measures & Action Plan Template
+
+Creates the goal definitions, the goal-product link, and the action-plan template (with its items) that back the KAM account plan, then publishes it (by setting its version to `Final`) and assigns it. Run entirely as the **admin** (`--target-org <admin>`), immediately after Part A — Part B links to the Part A `LifeSciMarketableProduct`.
+
+Only the record **names** are confirmed with the admin. All other fields are auto-derived from this reference and shown for confirmation.
+
+## Step 1 — Two GoalDefinition records
+
+Both are active. On `GoalDefinition` the active flag is **`Status`** (values `Active`/`Inactive`) — **not** `IsActive` (that field does not exist on this object). Set `Status=Active`. The goal-type field distinguishes them (`Strategic` vs `Individual`).
+
+| # | Name | Goal type | Status | Confirmed? |
+|---|------|-----------|--------|-----------|
+| 1 | `Immunexis: Secure Q3 Formulary Position` | Strategic | Active | Name only |
+| 2 | `Immunexis: Prepare Pharmacy & Therapeutics (P&T) Strategy` | Individual | Active | Name only |
+
+```bash
+sf data create record --sobject GoalDefinition --target-org <admin> \
+  --values "Name='Immunexis: Secure Q3 Formulary Position' Type=Strategic Status=Active" --json
+sf data create record --sobject GoalDefinition --target-org <admin> \
+  --values "Name='Immunexis: Prepare Pharmacy & Therapeutics (P&T) Strategy' Type=Individual Status=Active" --json
+```
+
+> The goal-type field is the picklist that carries `Strategic`/`Individual`. If `Type` is rejected, describe the object (`sf sobject describe --sobject GoalDefinition`) and use the actual field name (e.g. `GoalType`); the values `Strategic`/`Individual` are unchanged. Capture **both** Ids — the **Strategic** goal (#1) is referenced by both `GoalDefinitionProduct` and `ActionPlanTemplateAssignment`.
+
+---
+
+## Step 2 — GoalDefinitionProduct
+
+Links the **Strategic** goal to the Part A product.
+
+| Field | Value |
+|-------|-------|
+| `GoalDefinitionId` | Id of goal #1 (`Immunexis: Secure Q3 Formulary Position`) |
+| `ProductId` | the Part A `LifeSciMarketableProduct` Id (Immunexis 5mg) — from `OrchestrationState` |
+
+```bash
+sf data create record --sobject GoalDefinitionProduct --target-org <admin> \
+  --values "GoalDefinitionId=<strategicGoalId> ProductId=<lifeSciMarketableProductId>" --json
+```
+
+> `ProductId` is the **LifeSciMarketableProduct** Id from Part A, not the Product2 Id.
+
+---
+
+## Step 3 — ActionPlanTemplate
+
+| Field | Value | Confirmed? |
+|-------|-------|-----------|
+| `Name` | `Immunexis: Formulary Submission & Review Prep` | Name only |
+| `ActionPlanType` | `KAM` | Auto |
+| `TargetEntityType` | `AccountPlanObjective` | Auto |
+| `IsAdHocItemCreationEnabled` | `true` | Auto |
+
+> **Do NOT set `Status` on create** — `ActionPlanTemplate.Status` is **read-only** (not writable on create or update). It defaults to `Draft`, and it is later driven to `Final` by publishing the version (Step 5), which propagates back to the template. Including `Status=Draft` here is rejected.
+
+```bash
+sf data create record --sobject ActionPlanTemplate --target-org <admin> \
+  --values "Name='Immunexis: Formulary Submission & Review Prep' ActionPlanType=KAM TargetEntityType=AccountPlanObjective IsAdHocItemCreationEnabled=true" --json
+```
+
+Creating the template **auto-creates** an `ActionPlanTemplateVersion` (draft) — no `Status` flag is needed to trigger it. Query for it — the template items and the publish step operate on the version:
+
+```bash
+sf data query --query "SELECT Id, ActionPlanTemplateId, Version, Status FROM ActionPlanTemplateVersion WHERE ActionPlanTemplateId = '<templateId>' ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+```
+
+Capture the version Id.
+
+> The version fields are **`Version`** (int) and **`Status`** (picklist) — the same `Status` the publish step (Step 5) updates to `Final`. Do **not** use `VersionNumber`/`VersionStatus`; those columns do not exist and the query silently returns null for them. If a query is rejected, `sf sobject describe --sobject ActionPlanTemplateVersion` and use the reported names.
+
+---
+
+## Step 4 — Three ActionPlanTemplateItem records
+
+All three: `ItemEntityType=AssessmentTask`, `IsActive=true`, linked to the template version.
+
+| # | Name / Subject |
+|---|----------------|
+| 1 | `Identify key P&T committee members and influencers` |
+| 2 | `Gather HEOR data supporting our value proposition` |
+| 3 | `Compile the competitive landscape and formulary access gaps` |
+
+```bash
+sf data create record --sobject ActionPlanTemplateItem --target-org <admin> \
+  --values "ActionPlanTemplateVersionId=<versionId> Name='Identify key P&T committee members and influencers' ItemEntityType=AssessmentTask IsActive=true" --json
+# …repeat for items 2 and 3
+```
+
+**Capture each item's Id** — the `ActionPlanTemplateItemValue` records below reference it (`<item1Id>`, `<item2Id>`, `<item3Id>`).
+
+> The item-name field may be `Name` or `Subject` depending on the org — describe `ActionPlanTemplateItem` if `Name` is rejected and use the reported field; the three strings are unchanged. The link field to the version may be `ActionPlanTemplateVersionId` (confirm via describe).
+
+### Step 4b — Two ActionPlanTemplateItemValue per item
+
+For **each** `ActionPlanTemplateItem`, create **two** `ActionPlanTemplateItemValue` records — one for the task **Name**, one for the task **Category**. All six share `IsActive=true` and are linked to their item via `ActionPlanTemplateItemId`. Do **not** set `ItemEntityType` on `ActionPlanTemplateItemValue` — it is read-only (derived from the parent item) and setting it fails with "Unable to create/update fields: ItemEntityType". The `Category` values (`Survey`/`Claim`) come from the `AssessmentTaskCategory` StandardValueSet confirmed in Stage 2.
+
+| Item | `ActionPlanTemplateItemId` | `ItemEntityFieldName` | `Name` | `ValueLiteral` |
+|------|---------------------------|-----------------------|--------|----------------|
+| 1 — Identify key P&T committee members and influencers | `<item1Id>` | `AssessmentTask.Name` | `Name` | `Identify key P&T committee members and influencers` |
+| 1 — Identify key P&T committee members and influencers | `<item1Id>` | `AssessmentTask.Category` | `Category` | `Survey` |
+| 2 — Gather HEOR data supporting our value proposition | `<item2Id>` | `AssessmentTask.Name` | `Name` | `Gather HEOR data supporting our value proposition` |
+| 2 — Gather HEOR data supporting our value proposition | `<item2Id>` | `AssessmentTask.Category` | `Category` | `Claim` |
+| 3 — Compile the competitive landscape and formulary access gaps | `<item3Id>` | `AssessmentTask.Name` | `Name` | `Compile the competitive landscape and formulary access gaps` |
+| 3 — Compile the competitive landscape and formulary access gaps | `<item3Id>` | `AssessmentTask.Category` | `Category` | `Survey` |
+
+```bash
+# Item 1 — <item1Id>
+sf data create record --sobject ActionPlanTemplateItemValue --target-org <admin> \
+  --values "ActionPlanTemplateItemId=<item1Id> ItemEntityFieldName=AssessmentTask.Name Name=Name ValueLiteral='Identify key P&T committee members and influencers' IsActive=true" --json
+sf data create record --sobject ActionPlanTemplateItemValue --target-org <admin> \
+  --values "ActionPlanTemplateItemId=<item1Id> ItemEntityFieldName=AssessmentTask.Category Name=Category ValueLiteral='Survey' IsActive=true" --json
+
+# Item 2 — <item2Id>
+sf data create record --sobject ActionPlanTemplateItemValue --target-org <admin> \
+  --values "ActionPlanTemplateItemId=<item2Id> ItemEntityFieldName=AssessmentTask.Name Name=Name ValueLiteral='Gather HEOR data supporting our value proposition' IsActive=true" --json
+sf data create record --sobject ActionPlanTemplateItemValue --target-org <admin> \
+  --values "ActionPlanTemplateItemId=<item2Id> ItemEntityFieldName=AssessmentTask.Category Name=Category ValueLiteral='Claim' IsActive=true" --json
+
+# Item 3 — <item3Id>
+sf data create record --sobject ActionPlanTemplateItemValue --target-org <admin> \
+  --values "ActionPlanTemplateItemId=<item3Id> ItemEntityFieldName=AssessmentTask.Name Name=Name ValueLiteral='Compile the competitive landscape and formulary access gaps' IsActive=true" --json
+sf data create record --sobject ActionPlanTemplateItemValue --target-org <admin> \
+  --values "ActionPlanTemplateItemId=<item3Id> ItemEntityFieldName=AssessmentTask.Category Name=Category ValueLiteral='Survey' IsActive=true" --json
+```
+
+> Wrap each `ValueLiteral` in single quotes so the shell preserves spaces. Create all six values **before** publishing (Step 5) — a published template is immutable.
+
+---
+
+## Step 5 — Publish via the version (→ Final)
+
+**Publishing is driven through the version, not the template.** `ActionPlanTemplate.Status` is read-only and cannot be updated directly; `ActionPlanTemplateVersion.Status` **is** updateable, and setting it to `Final` propagates the published state back to the parent template. Do this only after all three items and their six item values exist — a published version is immutable. Update the `ActionPlanTemplateVersion` record using the `<versionId>` captured in Step 3, **not** the `<templateId>`:
+
+```bash
+sf data update record --sobject ActionPlanTemplateVersion --record-id <versionId> \
+  --values "Status=Final" --target-org <admin> --json
+```
+
+> Do **not** attempt `sf data update record --sobject ActionPlanTemplate ... Status=Final` — the template's `Status` is read-only and the update is rejected. The version is the only writable path.
+
+Verify — the version reads `Final`, and the template's `Status` has propagated to `Final`:
+
+```bash
+sf data query --query "SELECT Id, Status FROM ActionPlanTemplateVersion WHERE Id = '<versionId>'" --target-org <admin> --json
+sf data query --query "SELECT Id, Status FROM ActionPlanTemplate WHERE Id = '<templateId>'" --target-org <admin> --json
+```
+
+Both must return `Status='Final'`.
+
+---
+
+## Step 6 — ActionPlanTemplateAssignment
+
+Assigns the published version to the **Strategic** goal. `ActionPlanTemplateAssignment` has **no `ActionPlanTemplateId` field** — it links to the template **through the version** via `ActionPlanTemplateVersionId` (required).
+
+| Field | Value |
+|-------|-------|
+| `AssociatedObjectId` | Id of goal #1 (`Immunexis: Secure Q3 Formulary Position`) — the Strategic `GoalDefinition` |
+| `ActionPlanTemplateVersionId` | the `<versionId>` captured in Step 3 (required) |
+
+```bash
+sf data create record --sobject ActionPlanTemplateAssignment --target-org <admin> \
+  --values "AssociatedObjectId=<strategicGoalId> ActionPlanTemplateVersionId=<versionId>" --json
+```
+
+> `AssociatedObjectId` points at the **Strategic** GoalDefinition; `ActionPlanTemplateVersionId` is the published version from Step 3. There is no `ActionPlanTemplateId` field on this object — `No such column 'ActionPlanTemplateId'` means you passed the template Id; use the version Id instead.
+
+---
+
+## Step 7 — Share GoalDefinition, ActionPlanTemplate & ProviderAcctTerritoryInfo to the leaf territory
+
+The two `GoalDefinition` records, the `ActionPlanTemplate`, and the two `ProviderAcctTerritoryInfo` records (HCP + HCO, from Part A) are owned by the **admin**. For the KAM user — assigned to the Stage-3 level-3 (leaf) territory in Stage 6 — to see them, grant the **territory** access via manual share records: one `GoalDefinitionShare` per goal, one `ActionPlanTemplateShare` for the template, and one `ProviderAcctTerritoryInfoShare` per PATI record.
+
+Sharing to a territory means sharing to the territory's **Group**, not to the `Territory2` record. First resolve the group for the Stage-3 `territoryId`:
+
+```bash
+sf data query --query "SELECT Id, Type, RelatedId FROM Group WHERE RelatedId = '<territoryId>' AND Type IN ('Territory','TerritoryAndSubordinates')" --target-org <admin> --json
+```
+
+Two groups come back — `Territory` (users of exactly this territory) and `TerritoryAndSubordinates`. For a leaf territory they resolve to the same users; use the **`Territory`** group Id (`<territoryGroupId>`).
+
+Then create the share records — `AccessLevel=Edit`, `RowCause=Manual`:
+
+```bash
+# GoalDefinitionShare — one per GoalDefinition (Strategic + Individual)
+sf data create record --sobject GoalDefinitionShare --target-org <admin> \
+  --values "ParentId=<strategicGoalId> UserOrGroupId=<territoryGroupId> AccessLevel=Edit RowCause=Manual" --json
+sf data create record --sobject GoalDefinitionShare --target-org <admin> \
+  --values "ParentId=<individualGoalId> UserOrGroupId=<territoryGroupId> AccessLevel=Edit RowCause=Manual" --json
+
+# ActionPlanTemplateShare — the template
+sf data create record --sobject ActionPlanTemplateShare --target-org <admin> \
+  --values "ParentId=<templateId> UserOrGroupId=<territoryGroupId> AccessLevel=Edit RowCause=Manual" --json
+```
+
+Then share the `ProviderAcctTerritoryInfo` records. Both PATI records (HCP + HCO) were created in Part A against the Stage-3 `<territoryId>`; query them and create one `ProviderAcctTerritoryInfoShare` per record:
+
+```bash
+# Fetch both PATI records for the Stage-3 territory (HCP + HCO)
+sf data query --query "SELECT Id FROM ProviderAcctTerritoryInfo WHERE Territory2Id = '<territoryId>'" --target-org <admin> --json
+
+# ProviderAcctTerritoryInfoShare — one per PATI Id returned above
+sf data create record --sobject ProviderAcctTerritoryInfoShare --target-org <admin> \
+  --values "ParentId=<patiId> UserOrGroupId=<territoryGroupId> AccessLevel=Edit RowCause=Manual" --json
+```
+
+> The parent lookup on `GoalDefinitionShare`, `ActionPlanTemplateShare`, and `ProviderAcctTerritoryInfoShare` is **`ParentId`** (confirmed) — the record being shared. `AccessLevel` accepts `Read` or `Edit` for a manual share (`All` is reserved for the record owner). Share to the **Group** Id, never the `Territory2` Id directly — a `Territory2` Id in `UserOrGroupId` fails with `INVALID_CROSS_REFERENCE_KEY`. If the share fails with `insufficient access` on `RowCause`, drop `RowCause` (it defaults to `Manual`).
+
+---
+
+## Part B Verification Gate
+
+```bash
+sf data query --query "SELECT Id, Status FROM ActionPlanTemplateVersion WHERE Status = 'Final' ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+sf data query --query "SELECT Id, AssociatedObjectId, ActionPlanTemplateVersionId FROM ActionPlanTemplateAssignment ORDER BY CreatedDate DESC LIMIT 1" --target-org <admin> --json
+sf data query --query "SELECT Id, ParentId, UserOrGroupId FROM GoalDefinitionShare WHERE RowCause = 'Manual' ORDER BY CreatedDate DESC LIMIT 2" --target-org <admin> --json
+sf data query --query "SELECT Id, ParentId, UserOrGroupId FROM ActionPlanTemplateShare WHERE ParentId = '<templateId>' AND RowCause = 'Manual'" --target-org <admin> --json
+sf data query --query "SELECT Id, ParentId, UserOrGroupId FROM ProviderAcctTerritoryInfoShare WHERE RowCause = 'Manual' ORDER BY LastModifiedDate DESC LIMIT 2" --target-org <admin> --json
+```
+
+Expect a version with `Status='Final'` (the parent template's `Status` propagates to `Final`), an assignment whose `AssociatedObjectId` is the Strategic goal and whose `ActionPlanTemplateVersionId` is that published version, and the five share records (2 `GoalDefinitionShare` + 1 `ActionPlanTemplateShare` + 2 `ProviderAcctTerritoryInfoShare`) whose `UserOrGroupId` equals the leaf-territory `<territoryGroupId>`.
+
+---
+
+## Part B Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Run everything as admin | Setup-level configuration |
+| Confirm only the record names; auto-derive the rest | Per spec, names are the only user-supplied values |
+| Create all 3 items AND their 6 item values BEFORE publishing | A published (`Status=Final`) version is immutable — items/values can't be added after |
+| Publish by updating the **version** to `Status=Final`, never the template | `ActionPlanTemplate.Status` is read-only; the version's `Status` is the only writable path and propagates to the template |
+| `GoalDefinitionProduct.ProductId` = Part A LifeSciMarketableProduct | Not the Product2 Id |
+| `GoalDefinitionProduct` + `ActionPlanTemplateAssignment` reference the **Strategic** goal | Per spec |
+| Share both `GoalDefinition` records + the `ActionPlanTemplate` + both `ProviderAcctTerritoryInfo` records to the leaf-territory **Group** | Admin owns the records; the KAM user reaches them only through the territory share |
+
+## Part B Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| Field name rejected (`Type`, `Name`, version-link) | Describe the sObject and use the reported API name; the values/strings are unchanged |
+| Can't add items after publish | Publish is one-way — create a new version/template if items were missed |
+| `ActionPlanTemplate` create/update rejects `Status` | `Status` is read-only on this object — omit it on create (defaults to `Draft`); publish by updating the **version** to `Final`, which propagates to the template |
+| `No such column 'ActionPlanTemplateId' on ... ActionPlanTemplateAssignment` | This object has no `ActionPlanTemplateId` field — link via `ActionPlanTemplateVersionId=<versionId>` (the published version), not the template Id |
+| `GoalDefinitionProduct` create fails on ProductId | Use the LifeSciMarketableProduct Id from Part A, not Product2 |
+| `GoalDefinition` create fails on `IsActive` (`No such column`) | `GoalDefinition` has no `IsActive` field — its active flag is `Status` (`Active`/`Inactive`). Use `Status=Active` |
+| `Share` create fails with `INVALID_CROSS_REFERENCE_KEY` on `UserOrGroupId` | You passed the `Territory2` Id — pass the territory **Group** Id from the `Group WHERE RelatedId=<territoryId>` query instead |
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `references/stage-5-data-creation-data.md` | Part A — object→CSV mapping, per-object field values, dependency chain |