Life Sciences Kam Coordinate

Life Sciences Cloud KAM End-to-End Orchestrator

Runs the complete Life Sciences Cloud setup for a key account management (KAM) user as six stages in strict sequence, gating each on the previous stage's success. Each stage delegates to a child skill or reference workflow (see Execution Order).

Scope Guard (evaluate FIRST)

Serve only requests for the full end-to-end LSC setup for a KAM user. A single stage/phase/step is never invokable here — never silently expand a partial ask into the whole flow. Before any work:

• Field sales rep persona (not KAM) → redirect to life-sciences-fieldsalesrep-coordinate; stop.
• Unrelated to LSC setup (at start or mid-run) → do not attempt it; say you did not understand and show what you can help with (full end-to-end LSC KAM setup, or standalone life-sciences-prerequisites-validate / life-sciences-territory-configure); stop.
• Single stage with its own standalone skill — prerequisites (1) or territory config (3) → redirect to that skill; stop.
• Single stage with no standalone skill — config deploy (2), participant role/sprint (4), data and plan templates (5), user provisioning (6) → explain these run only inside the full flow; stop. Do not launch the full flow unless the user then asks.

Continue only for the complete end-to-end KAM setup: the full flow in order with gates, each stage's work delegated to child skills / reference files.

---

Required Inputs

• Target org: the org to deploy to — selected by the user from connected orgs or a freshly authenticated org (Phase 0). Never assume a default org silently; the user confirms or selects it before any stage runs.

---

Execution Order (MANDATORY)

Terminology: Stage = one of the 6 units of work, each delegated to a child skill/reference; Phase = a named group inside a stage; Step = an atomic action inside a phase.

Run in this order, each gated on the previous (dependency diagram in references/orchestration-flow.md):

---

Workflow

Phase 0 — Org Selection (MANDATORY, runs first)

Establish which org to use every time — never silently reuse the default org.

1. List connected orgs with sf org list --json, then present the authenticated (non-expired) orgs as a numbered list (alias, username, org type, default marker), plus an option N to log in to a fresh org.
2. Ask the user to choose a number or N.
3. Handle the selection:
   • Existing org → capture its username/alias as the target org.
   • Fresh org (N) → ask for the login URL (https://login.salesforce.com, https://test.salesforce.com, or a My Domain URL) and an alias, then run the login command yourself: sf org login web --instance-url <url> --alias <alias> --set-default. Do not hand the command to the user to run — execute it directly. It opens a browser on the user's machine for them to complete the login interactively; the command then returns. After it finishes, re-run sf org list --json to confirm.
4. Confirm the target org back to the user and store it in OrchestrationState.targetOrg.

If sf org list returns no authenticated orgs, go straight to the fresh-org login (option N).

Phase 1 — Introduction and Confirmation

1. Present the workflow to the user — a "Life Sciences Cloud — Full KAM Setup Workflow" header, the target org, and the 6 stages in order with a one-line summary each: (1) Validate Prerequisites; (2) Deploy Starter Configuration (objects, profiles, config records incl. KAM & Sprint settings, layouts, flexipages); (3) Configure Territories; (4) Create Participant Role & Sprint; (5) Create KAM Data & Plan Templates (account, provider, product, territory data + goals, tasks, measures, published action plan template); (6) Provision KAM User (profile/permsets/territory + mobile metadata cache).

2. Ask for confirmation: "Ready to begin the full LSC KAM setup? (yes/no)"

3. Download the shared source folder FRESH (MANDATORY — hard gate, before any stage). Stages 2 (metadata + config records) and 5 (Data CSVs) read from .lsc-starter-config/LSStarterConfig/; those stages do NOT download or delete it — the orchestrator owns one fresh download here and one delete in Phase 9. Always re-pull — never reuse an existing folder (a stale copy would skip newly added components). Delete any pre-existing .lsc-starter-config first, then sparse-checkout the subtree fresh:

   rm -rf .lsc-starter-config lsstarter-tmp
   git clone --no-checkout --depth 1 --filter=blob:none \
     https://github.com/SalesforceLabs/LSStarterConfig.git lsstarter-tmp
   cd lsstarter-tmp && git sparse-checkout init --cone \
     && git sparse-checkout set Codey/LSStarterConfig && git checkout && cd ..
   mv lsstarter-tmp/Codey ./.lsc-starter-config && rm -rf lsstarter-tmp

   .lsc-starter-config/LSStarterConfig/ has its own sfdx-project.json (pins sourceApiVersion: 65.0) — deploy steps must run from inside it.

4. Download gate — verify before proceeding. Confirm .lsc-starter-config/LSStarterConfig/sfdx-project.json and .lsc-starter-config/LSStarterConfig/Data/ exist (e.g. ls .lsc-starter-config/LSStarterConfig/sfdx-project.json .lsc-starter-config/LSStarterConfig/Data).

   • If present → set sourceFolderDownloaded: true and proceed to Phase 2.
   • If missing/failed → STOP. Do NOT proceed to any stage — every stage depends on this folder. Report the failure (likely: no network / GitHub unreachable, git < 2.25, or disk/permission), leave sourceFolderDownloaded: false, and do not advance. Fix the cause and re-run, or download the folder manually into the CWD.

Phase 2 — Execute Stage 1: Prerequisites Validation

5. Run the prerequisites validation following the life-sciences-prerequisites-validate skill workflow exactly.

6. Gate check: If ALL prerequisites pass → proceed to Stage 2. If ANY fails → stop, present the failure table, and ask: "Continue anyway (skip failed prerequisites), or stop and fix them first?" Stop → end the workflow. Continue → proceed with a warning that later stages may fail.

Phase 3 — Execute Stage 2: Starter Config Deploy

7. Run the starter config deployment following references/stage-2-starter-config-overview.md exactly (all 13 deploy steps + the KAM/Sprint config-record edits); read its own reference files as directed. The KAM adaptation deploys only the KAM-relevant layouts (4) and flexipages (6) — all of them, automatically, with no selection prompt — and confirms the StandardValueSet picklist values with the admin (three business-framed groups) BEFORE deploying them, then writes those confirmed values into the KAMSettings_OrgLevel and SprintSettings_OrgLevel config records.

8. Gate check: Verify the LSC Custom Profile exists:

   sf data query --query "SELECT Id, Name FROM Profile WHERE Name = 'LSC Custom Profile'" --target-org <org> --json

   • If profile exists → proceed to Stage 3. If not found → stop and report deployment failure.

Phase 4 — Execute Stage 3: Territory Configuration

9. Run the territory configuration following the life-sciences-territory-configure skill workflow exactly. If an active territory model already exists, use it and show the hierarchy rather than creating a new one.

10. Gate check: Verify the territory model is Active and a level-3 territory exists:

    sf data query --query "SELECT Id, Name, DeveloperName, Territory2Model.State FROM Territory2 WHERE ParentTerritory2.ParentTerritory2Id != null AND Territory2Model.State = 'Active'" --target-org <org> --json

    • If found → capture the level-3 territory ID + name (OrchestrationState.territoryId) and tell the user this leaf territory is the single territory reused for Stage 5 (ProductTerritoryAvailability) and Stage 6 (UserTerritory2Association for both admin and KAM user). Proceed to Stage 4.
    • If not found → stop and report the issue.

Phase 5 — Execute Stage 4: Participant Role & Sprint

11. Create the participant role and sprint following references/stage-4-participant-role-and-sprint.md exactly. Only the MasterLabel/Name fields are confirmed with the admin; all other fields are auto-derived and shown for confirmation.

12. Gate check: Verify a ParticipantRole (DeveloperName = 'Rep_Execution_Specialist', IsActive = true) and a Sprint (Status Not Started) exist. If either is missing → stop and report.

Phase 6 — Execute Stage 5: KAM Data & Plan Templates

Both parts run as the admin, in order, from the single reference references/stage-5-data-and-plan-templates-overview.md (Part A = data, Part B = plan templates).

13. Create the KAM data (Part A) following the reference exactly. Pass the Stage-3 level-3 territory. Creates (from the Data CSVs): Account, HealthcareProvider, ObjectTerritory2Association, ProviderAcctTerritoryInfo, Product2, LifeSciMarketableProduct, ContactPointAddress, ProductTerritoryAvailability.

14. Part A gate check: Verify the Account, LifeSciMarketableProduct, and ProductTerritoryAvailability (on the Stage-3 territory) exist; capture the LifeSciMarketableProduct ID (Part B uses it). If any missing → stop.

15. Create the goals, tasks, measures, and action plan template (Part B) following the same reference exactly (stay on the admin login). Creates 2 GoalDefinition records, a GoalDefinitionProduct, an ActionPlanTemplate (+ auto ActionPlanTemplateVersion), 3 ActionPlanTemplateItem records, publishes the template (status → Final), creates an ActionPlanTemplateAssignment, and shares the 2 GoalDefinition records, the ActionPlanTemplate, and both ProviderAcctTerritoryInfo records to the Stage-3 leaf-territory Group (5 manual shares total) so the KAM user reaches them through the territory. Only the record names are confirmed with the admin.

16. Part B gate check: Verify the template is published (a Final ActionPlanTemplateVersion exists), an ActionPlanTemplateAssignment exists, and the leaf-territory shares exist (2 GoalDefinitionShare + 1 ActionPlanTemplateShare + 2 ProviderAcctTerritoryInfoShare whose UserOrGroupId is the Stage-3 territory Group). If not → stop.