Life Sciences Fieldsalesrep Coordinate

Life Sciences Cloud End-to-End Orchestrator

Runs the complete Life Sciences Cloud setup workflow as five stages in strict sequence, gating each on the success of the previous stage. Each stage delegates to a child skill or a reference workflow, organized internally into phases and steps (defined under Execution Order below).

Scope Guard (evaluate FIRST)

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

• Unrelated to LSC setup (at start or mid-run) → do not attempt it. Tell the user you did not understand the request and show what you can help with (full end-to-end LSC setup, or standalone life-sciences-prerequisites-validate / life-sciences-territory-configure); stop.
• Stage with its own standalone skill — prerequisites (Stage 1) or territory config (Stage 3) → redirect to life-sciences-prerequisites-validate / life-sciences-territory-configure; stop.
• Stage with no standalone skill — config deploy (2), user provisioning (4), visit creation (5) → explain these run only as part of the full flow, not on their own; stop. Do not launch the full flow unless the user then asks for it.

Continue only for the complete end-to-end setup: orchestrating the full flow (prerequisites → config deploy → territory → user provisioning → visit creation) in order with gates. Each stage's actual work is delegated to child skills / reference files.

Required Inputs

Gather before proceeding:

• Target org: The org to deploy to — selected by the user from the list of connected orgs, or a freshly authenticated org (see Phase 0). Never assume a default org silently; always have the user confirm or select the target org before any stage runs.

Execution Order (MANDATORY)

Terminology: Stage = one of the 5 units of work (1–5), each delegated to a child skill or a reference workflow; Phase = a named group of work inside a stage; Step = an atomic action inside a phase. So "Stage 2 › Phase 1 › Step 3" reads top-to-bottom.

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

Workflow

Phase 0 — Org Selection (MANDATORY, runs first)

Before presenting the workflow, establish which org to use. Do this every time the user asks to set up Life Sciences Cloud — do not silently reuse the current default org.

1. List connected orgs:

   sf org list --json

   Parse the result and present the authenticated orgs (non-expired) to the user as a numbered list — include alias, username, org type (Dev Hub / Sandbox / Scratch / Production), and the default marker if any:

   Connected Orgs — select the target for Life Sciences Cloud setup
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
     1. ls-dev        alice@example.com          (Dev Hub)   [default]
     2. ls-sandbox    alice@example.com.sandbox  (Sandbox)
     3. partial-scr   test-xyz@example.com       (Scratch)
   
     N. Log in to a fresh org (opens a browser to authenticate a new org)

2. Ask the user to choose: "Which org would you like to use? Enter a number, or choose N to log in to a fresh org."

3. Handle the selection:

   • Existing org chosen → capture its username/alias as the target org for all subsequent steps.

   • Fresh org chosen (option N) → authenticate a new org interactively: ask for the login URL (My Domain / instance URL, e.g. https://mydomain.my.salesforce.com; https://login.salesforce.com for production, https://test.salesforce.com for a sandbox) and an alias (e.g. ls-setup), then run the login command yourself:

     sf org login web --instance-url <user-supplied-url> --alias <user-supplied-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 web login interactively; the command then returns. After it finishes, re-run sf org list --json to confirm the new org, then use it as the target org.

4. Confirm the target org back to the user before proceeding: "Using <alias> (<username>) as the target org for Life Sciences Cloud setup." Store this in OrchestrationState.targetOrg.

If sf org list returns no authenticated orgs, go straight to the fresh-org login flow (option N) — there is nothing to select from.

Phase 1 — Introduction and Confirmation

1. Present the workflow to the user:

   Life Sciences Cloud — Full Setup Workflow
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   
   This will execute 5 stages in sequence. Each stage is internally
   organized into phases and steps.
   
   Stage 1: Validate Prerequisites
            Checks org settings, permissions, and features
   
   Stage 2: Deploy Starter Configuration
            Deploys objects, profiles, config records, layouts, flexipages
   
   Stage 3: Configure Territories
            Creates territory type, model, and 3-level hierarchy
   
   Stage 4: Provision Field Sales Rep User
            Creates user, assigns profile/permsets, assigns to territory
   
   Stage 5: Create Sample Visit
            Logs in as the rep, creates account/provider/visit records,
            generates the mobile metadata cache
   
   Target org: <org>

2. Ask for confirmation: "Ready to begin the full Life Sciences Cloud setup? (yes/no)"

3. Download the shared source folder ONCE (MANDATORY — hard gate, before any stage). Both Stage 2 (Starter Config Deploy — metadata + config records) and Stage 5 (Sample Visit Creation — Data CSVs) read from .lsc-starter-config/LSStarterConfig/; those stages do NOT download or delete it — the orchestrator owns a single download here and a single delete in Phase 8. Sparse-checkout only that subtree (the repo is large) into the CWD:

   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/ contains its own sfdx-project.json (pins sourceApiVersion: 65.0) — the deploy step (Phase 3) must run from inside it. If the folder already exists in the CWD (from a prior run), reuse it (skip the download).

4. Download gate — verify the folder exists before proceeding. Confirm the download succeeded by checking that .lsc-starter-config/LSStarterConfig/sfdx-project.json and .lsc-starter-config/LSStarterConfig/Data/ are present (e.g. ls .lsc-starter-config/LSStarterConfig/sfdx-project.json .lsc-starter-config/LSStarterConfig/Data).

   • If present → set sourceFolderDownloaded: true in OrchestrationState and proceed to Phase 2.

   • If the download failed or the folder/contents are missing → STOP. Do NOT proceed to any stage — every stage depends on this folder. Report the failure and stop:

     STOP: Setup cannot start — source download failed
     
     Could not download .lsc-starter-config/LSStarterConfig from
     https://github.com/SalesforceLabs/LSStarterConfig.git
     Likely: no network / GitHub unreachable, git < 2.25 (no sparse-checkout),
     or insufficient disk space / write permission in the CWD.
     
     Mandatory prerequisite — no stage can run without it. Fix the cause and
     re-run, or download the folder manually into the CWD, then re-run.

     Leave sourceFolderDownloaded: false and do not advance the workflow.

Phase 2 — Execute Stage 1: Prerequisites Validation

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

6. Gate check: Review the results.

   • If ALL prerequisites pass → proceed to Stage 2
   • If ANY prerequisite fails → stop and present the failure report

   STOP: Stage 1 FAILED — Prerequisites not met
   
   <show the prerequisite failure table>
   
   Please resolve the failed prerequisites and re-run this workflow.

   Ask the user: "Would you like to continue anyway (skip failed prerequisites), or stop and fix them first?"

   • If user says stop → end the workflow
   • If user says 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 steps in order); read its own reference files as directed.

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 profile 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.

10. Gate check: Verify the territory model is Active and 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 level-3 territory found with Active model → capture the territory ID and name, proceed to Stage 4
• If not found → stop and report the issue

Phase 5 — Execute Stage 4: User Provisioning

11. Run the user provisioning following references/stage-4-user-provisioning-overview.md exactly; read its own reference file as directed. Pass the territory information captured from Stage 3.

12. Gate check: Verify the user exists, has the correct profile, all 4 permission sets, and territory assignment. Capture the rep username — Stage 5 logs in as this user.

    STOP-GATE (Stage 4 completeness). Do NOT accept "user created" as passing this gate — verify all four facets and STOP if any is short:

    sf data query --query "SELECT COUNT(Id) c FROM PermissionSetAssignment WHERE AssigneeId = '<newUserId>' AND PermissionSet.IsOwnedByProfile = false" --target-org <org> --json

    The permset count MUST be 4 ({LifeSciencesCore, LifeSciencesFieldSalesRepresentative, HealthCloudStarter, LifeSciencesKeyAccountManager}); the user MUST be IsActive=true on the LSC Custom Profile; and a UserTerritory2Association to the level-3 territory MUST exist. If the permset count is < 4 or any facet is missing, Stage 4 did not fully complete — re-run the missing part of references/stage-4-user-provisioning-overview.md (its own Phase 4/5 stop-gates cover this) before advancing to Stage 5. A rep missing a permset silently fails visit creation downstream with confusing permission errors.