life-sciences-kam-coordinate

Life Sciences Cloud KAM エンドツーエンドオーケストレーター

キーアカウントマネジメント（KAM）ユーザー向けの Life Sciences Cloud セットアップ全体を、厳密な順序で実行する6つのステージとして処理します。各ステージは、前のステージが成功した場合にのみ進みます。各ステージの作業は、子スキルまたはリファレンスワークフローに委任されます（「実行順序」を参照）。

スコープガード（最初に評価）

KAMユーザー向けのLSCセットアップ全体に関するリクエストのみを受け付けます。単一のステージ／フェーズ／ステップをここから呼び出すことはできません。部分的な依頼を、全体のフローに黙って拡張しないでください。作業を開始する前に、以下を確認します。

• フィールドセールス担当者のペルソナ（KAMではない）→ life-sciences-fieldsalesrep-coordinate に案内します。そこで終了します。
• LSCセットアップと無関係な依頼（開始時または実行途中）→ 対応しません。依頼の内容が理解できなかったことを伝え、対応できる内容（KAM向けLSCエンドツーエンドセットアップ、または単独の life-sciences-prerequisites-validate ／ life-sciences-territory-configure）を示します。そこで終了します。
• 専用のスタンドアロンスキルがある単一ステージ — 前提条件（1）またはテリトリー設定（3）→ そのスキルに案内します。そこで終了します。
• スタンドアロンスキルがない単一ステージ — 設定のデプロイ（2）、参加者のロール／スプリント（4）、データと計画テンプレート（5）、ユーザーのプロビジョニング（6）→ これらは全体フローの中でのみ実行されることを説明します。そこで終了します。ユーザーがその後に依頼しない限り、全体フローを開始しないでください。

KAM向けの完全なエンドツーエンドセットアップの場合にのみ続行します。ゲートを設けた全体フローを順番に実行し、各ステージの作業を子スキル／リファレンスファイルに委任します。

---

必須入力

• 対象の組織：デプロイ先の組織です。接続済みの組織からユーザーが選択するか、新たに認証した組織を使用します（フェーズ0）。デフォルトの組織を暗黙に仮定しないでください。いずれのステージを実行する前にも、ユーザーが組織を確認または選択します。

---

実行順序（必須）

用語： ステージ = 子スキル／リファレンスに委任される6つの作業単位のいずれかです。フェーズ = ステージ内の名前付きグループです。ステップ = フェーズ内の個別のアクションです。

以下の順序で実行し、前のステージを通過した場合にのみ次へ進みます（依存関係図は references/orchestration-flow.md を参照）。

#	ステージ	実行内容	ゲート（次へ進むには合格が必須）	出力
—	セットアップ：.lsc-starter-config/LSStarterConfig をダウンロード	—	フォルダーが存在する（必須 — 失敗時は即時停止）	CWD 内の共有ソースフォルダー
1	前提条件の検証	life-sciences-prerequisites-validate スキル	すべての前提条件がPASS	組織の準備完了を確認
2	Starter Config のデプロイ	references/stage-2-starter-config-overview.md	13件のデプロイステップとKAM設定レコードが成功	LSCカスタムプロファイル + KAM／スプリント設定
3	テリトリー設定	life-sciences-territory-configure スキル	テリトリーモデルがActive + L3テリトリー	レベル3テリトリーのID + 名前
4	参加者のロールとスプリント	references/stage-4-participant-role-and-sprint.md	参加者のロールとスプリントが作成される	ロール + スプリントID
5	KAMデータと計画テンプレート	references/stage-5-data-and-plan-templates-overview.md	アカウント／HCP／製品／テリトリーデータが作成される + 目標、テンプレート（Final）、項目、割り当てが作成される + 目標／テンプレート／PATIが末端テリトリーに共有される	アカウント + 製品マスターデータ + 公開済みActionPlanTemplate
6	KAMユーザーのプロビジョニング	references/stage-6-user-provisioning-overview.md	ユーザーが作成され、権限セットとテリトリーが割り当てられる。メタデータキャッシュが生成される	KAMユーザー名

---

ワークフロー

フェーズ 0 — 組織の選択（必須、最初に実行）

毎回、使用する組織を確認します。デフォルトの組織を黙って再利用してはいけません。

1. sf org list --json で接続済みの組織を一覧表示し、認証済み（有効期限切れでない）の組織を番号付きリストとして提示します（エイリアス、ユーザー名、組織タイプ、デフォルトのマーク）。さらに、新しい組織にログインするためのオプション N も提示します。
2. 番号または N を選ぶようユーザーに尋ねます。
3. 選択を処理します：
   • 既存の組織 → ユーザー名／エイリアスを対象組織として取得します。
   • 新しい組織（N） → ログイン URL（https://login.salesforce.com、https://test.salesforce.com、または My Domain URL）とエイリアスを尋ね、ログインコマンドを自分で実行します：sf org login web --instance-url <url> --alias <alias> --set-default。ユーザーにコマンドの実行を任せてはいけません。直接実行してください。ユーザーが対話形式でログインを完了できるよう、ユーザーのマシンでブラウザーが開き、コマンドはその後終了します。完了したら、確認のために sf org list --json を再実行します。
4. 対象組織をユーザーに確認し、OrchestrationState.targetOrg に保存します。

sf org list で認証済みの組織が見つからない場合は、新しい組織へのログイン（オプション N）に直接進みます。

フェーズ 1 — 導入と確認

1. ワークフローをユーザーに提示します — 「Life Sciences Cloud — Full KAM Setup Workflow」というヘッダー、対象組織、および順番に並べた 6 つのステージを、それぞれ 1 行で要約します：（1）前提条件の検証、（2）スターター設定のデプロイ（オブジェクト、プロファイル、KAM と Sprint の設定を含む設定レコード、レイアウト、フレックスページ）、（3）テリトリーの設定、（4）参加者ロールと Sprint の作成、（5）KAM データとプランテンプレートの作成（アカウント、プロバイダー、製品、テリトリーのデータと目標、タスク、メジャー、公開済みアクションプランテンプレート）、（6）KAM ユーザーのプロビジョニング（プロファイル／権限セット／テリトリーとモバイルメタデータキャッシュ）。

2. 確認を求めます：「LSC KAM の完全な設定を開始してよろしいですか？（yes/no）」

3. 共有ソースフォルダーを新たにダウンロードします（必須 — すべてのステージより前に実行するハードゲート）。 ステージ 2（メタデータと設定レコード）とステージ 5（データ CSV）は .lsc-starter-config/LSStarterConfig/ を読み込みます。これらのステージではダウンロードも削除も行いません。ここでオーケストレーターが 1 回だけ新たにダウンロードし、フェーズ 9 で 1 回だけ削除します。必ず再取得し、既存のフォルダーを再利用してはいけません（古いコピーでは新たに追加されたコンポーネントが反映されません）。既存の .lsc-starter-config を先に削除してから、スパースチェックアウトでサブツリーを新たに取得します：

   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/ には独自の sfdx-project.json があり（sourceApiVersion: 65.0 を指定）、デプロイ手順はこのフォルダー内から実行する必要があります。

4. ダウンロードゲート — 続行前に確認します。 .lsc-starter-config/LSStarterConfig/sfdx-project.json と .lsc-starter-config/LSStarterConfig/Data/ が存在することを確認します（例：ls .lsc-starter-config/LSStarterConfig/sfdx-project.json .lsc-starter-config/LSStarterConfig/Data）。

   • 存在する場合 → sourceFolderDownloaded: true に設定し、フェーズ 2 に進みます。
   • 見つからない／失敗した場合 → 停止します。いずれのステージにも進んではいけません — すべてのステージがこのフォルダーに依存します。失敗を報告します（原因として、ネットワークがない、GitHub に接続できない、git のバージョンが 2.25 未満、またはディスク／権限の問題が考えられます）。sourceFolderDownloaded: false のままにし、先に進んではいけません。原因を修正して再実行するか、フォルダーを CWD に手動でダウンロードしてください。

フェーズ 2 — ステージ 1 の実行：前提条件の検証

5. life-sciences-prerequisites-validate スキルのワークフローに厳密に従って、前提条件の検証を実行します。

6. ゲートチェック：すべての前提条件に合格した場合 → ステージ 2 に進みます。いずれかに不合格の場合 → 停止し、失敗の一覧表を提示して、「続行（失敗した前提条件をスキップ）しますか、それとも停止して先に修正しますか？」と尋ねます。停止 → ワークフローを終了します。続行 → 後続のステージで失敗する可能性があることを警告したうえで進みます。

フェーズ 3 — ステージ 2 の実行：スターター設定のデプロイ

7. スターター設定のデプロイを実行します。references/stage-2-starter-config-overview.md に厳密に従ってください（デプロイ手順 13 項目すべてと、KAM/Sprint の設定レコードの編集を含みます）。指示に従って、参照ファイルも読みます。KAM 向けの調整では、KAM 関連のレイアウト（4 件）とフレキシページ（6 件）のみを、選択プロンプトを表示せずにすべて自動でデプロイします。デプロイ前に、StandardValueSet の選択リスト値を管理者に確認します（業務内容に即した 3 つのグループ）。次に、確認済みの値を KAMSettings_OrgLevel と SprintSettings_OrgLevel の設定レコードに書き込みます。

8. ゲートチェック：LSC カスタムプロファイルが存在することを確認します。

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

   • プロファイルが存在する場合 → ステージ 3 に進みます。見つからない場合 → 停止し、デプロイの失敗を報告します。

フェーズ 4 — ステージ 3 の実行：テリトリー設定

9. テリトリー設定を実行します。life-sciences-territory-configure スキルのワークフローに厳密に従ってください。アクティブなテリトリーモデルがすでに存在する場合は、新しいモデルを作成せずにそれを使用し、階層を表示します。

10. ゲートチェック：テリトリーモデルがアクティブで、レベル 3 のテリトリーが存在することを確認します。

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

    • 見つかった場合 → レベル 3 のテリトリー ID と名前（OrchestrationState.territoryId）を記録し、このリーフテリトリーをステージ 5（ProductTerritoryAvailability）とステージ 6（管理者ユーザーと KAM ユーザー両方の UserTerritory2Association）で共通して使用する単一のテリトリーとしてユーザーに伝えます。ステージ 4 に進みます。
    • 見つからない場合 → 停止し、問題を報告します。

フェーズ 5 — ステージ 4 の実行：参加者ロールと Sprint

11. 参加者ロールと Sprint を作成します。references/stage-4-participant-role-and-sprint.md に厳密に従ってください。管理者に確認するのは MasterLabel／Name フィールドのみです。それ以外のフィールドはすべて自動導出し、確認のために提示します。

12. ゲートチェック：ParticipantRole（DeveloperName = 'Rep_Execution_Specialist'、IsActive = true）と Sprint（ステータスが Not Started）が存在することを確認します。どちらかが存在しない場合 → 停止し、報告します。

フェーズ 6 — ステージ 5 の実行：KAM データとプランテンプレート

どちらのパートも管理者として、単一のリファレンス references/stage-5-data-and-plan-templates-overview.md に従い、順番に実行します（パート A = データ、パート B = プランテンプレート）。

13. KAM データを作成する（パート A）。リファレンスに厳密に従います。ステージ 3 のレベル 3 のテリトリーを渡します。（データ CSV から）Account、HealthcareProvider、ObjectTerritory2Association、ProviderAcctTerritoryInfo、Product2、LifeSciMarketableProduct、ContactPointAddress、ProductTerritoryAvailability を作成します。

14. パート A のゲートチェック：Account、LifeSciMarketableProduct、および（ステージ 3 のテリトリー上の）ProductTerritoryAvailability が存在することを確認し、LifeSciMarketableProduct の ID を取得します（パート B で使用します）。いずれかが存在しない場合 → 停止。

15. 目標、タスク、測定指標、アクションプランテンプレートを作成する（パート B）。同じリファレンスに厳密に従います（管理者ログインのまま実行します）。2 件の GoalDefinition レコード、1 件の GoalDefinitionProduct、1 件の ActionPlanTemplate（および自動作成される ActionPlanTemplateVersion）、3 件の ActionPlanTemplateItem レコードを作成し、テンプレートを公開し（ステータス → Final）、ActionPlanTemplateAssignment を作成します。また、KAM ユーザーがテリトリー経由でアクセスできるように、2 件の GoalDefinition レコード、ActionPlanTemplate、および両方の ProviderAcctTerritoryInfo レコードをステージ 3 の末端テリトリー Group と共有します（手動共有は合計 5 件）。管理者が確認するのはレコードの名前のみです。

16. パート B のゲートチェック：テンプレートが公開済みであること（Final の ActionPlanTemplateVersion が存在すること）、ActionPlanTemplateAssignment が存在すること、末端テリトリーの共有が存在すること（UserOrGroupId がステージ 3 のテリトリー Group である GoalDefinitionShare 2 件 + ActionPlanTemplateShare 1 件 + ProviderAcctTerritoryInfoShare 2 件）を確認します。存在しない場合 → 停止。

フェーズ 7 — ステージ 6 の実行：KAM ユーザーのプロビジョニング

17. references/stage-6-user-provisioning-overview.md に厳密に従って、KAM ユーザーをプロビジョニングします。ステージ 3 のレベル 3 のテリトリーを渡します。ユーザー名に kam を含むユーザーを作成し、権限セット Health Cloud Starter、Life Sciences Key Account Management、Life Sciences Field Sales Representative、および Life Sciences Core を割り当て、管理者と KAM ユーザーの両方をレベル 3 のテリトリーに割り当てます（管理者に確認してください — ステージ 5 で ProductTerritoryAvailability に使用したものと必ず同じテリトリーにしてください）。さらに、Connect API を使用してモバイルメタデータキャッシュを生成します。

18. ゲートチェック（STOP-GATE — ステージ 6 の完了確認）。「ユーザー作成済み」を合格として扱わないでください。ユーザーが LSC Custom Profile 上で IsActive=true であること、ステージ 3 のテリトリーに対する UserTerritory2Association があること、メタデータキャッシュが Status='Active' に到達していること、割り当てられた権限セットの数が 4（{HealthCloudStarter, LifeSciencesKeyAccountManager, LifeSciencesFieldSalesRepresentative, LifeSciencesCore}）であることを確認します：

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

    2 未満の場合、またはテリトリーの割り当てかメタデータキャッシュがない場合は、完了する前に不足している部分を再実行します。

フェーズ 8 — 最終サマリー、クリーンアップ、実機検証

19. ワークフロー全体のサマリーを表示する — 「Life Sciences Cloud KAM Setup Complete」というヘッダーに続けて、各ステージごとに実際の値を含むブロックを 1 つずつ表示します：(1) 前提条件の確認完了、(2) デプロイされたオブジェクト／プロファイル／設定レコード、書き込まれた KAM および Sprint 設定、レイアウト + フレキシページ、28 個のトリガーハンドラー、(3) テリトリーモデル <model>（有効）+ レベル 3 <territory>、(4) 参加者ロール Rep Execution Specialist + Sprint <name>、(5) 取引先 + HCP、製品マスターデータ、<territory> 上の ProductTerritoryAvailability、2 つの目標定義、ActionPlanTemplate <name>（最終）+ 3 つの項目 + 割り当て、テリトリー <territory> に共有された目標 + テンプレート + 2 つの PATI、(6) LSC Custom Profile 上のユーザー <name>（<username>）、権限セット Health Cloud Starter + Life Sciences Key Account Management + Life Sciences Field Sales Representative + Life Sciences Core、テリトリー <territory>（管理者 + KAM）、モバイルメタデータキャッシュの生成完了。締めくくり：「The org is ready for Life Sciences Cloud key account management workflows.」

20. クリーンアップ — 共有ソースフォルダーを 1 回だけ削除する。 最終サマリー（全 6 ステージ完了）の後、CWD から次を実行します：

    rm -rf .lsc-starter-config
    

    これはサイレントに行います — クリーンアップの行を出力したり、削除について言及したりしないでください。ワークフローが失敗で停止し、ユーザーが再開する可能性がある場合はスキップしてください — 再開したステージがまだフォルダーを読み取れるように保持します。これがフロー全体で唯一の削除です。子スキルは決してこれを削除しません。

21. 実機（iPad）検証スクリプトを表示し、確認を待つ。 メタデータキャッシュが Status='Active' になり、サマリーが表示されたら、references/stage-6-ipad-validation-script.md からスクリプトをそのまま表示し（ログインにはステージ 6 の KAM ユーザーの資格情報を使用します）、その後ユーザーが実機での手順の成功を確認するまで待ちます。確認が取れたら、セットアップは完了です。

---

状態トラッキング

オーケストレーション全体の状態を維持します：

OrchestrationState = {
  targetOrg: string,
  sourceFolderDownloaded: boolean,   // downloaded in Phase 1, deleted in Phase 9
  territoryId?: string, territoryName?: string,   // captured in Stage 3, reused in Stages 5 & 6
  stages: [
    { name: "Prerequisites",       status: "pending|running|passed|failed|skipped" },
    { name: "StarterConfig",       status: "pending|running|passed|failed" },
    { name: "TerritorySetup",      status: "pending|running|passed|failed", territoryId?: string, territoryName?: string },
    { name: "ParticipantSprint",   status: "pending|running|passed|failed", roleId?: string, sprintId?: string },
    { name: "DataAndPlanTemplates",status: "pending|running|passed|failed", accountId?: string, marketableProductId?: string, templateVersionId?: string },
    { name: "UserProvisioning",    status: "pending|running|passed|failed", userId?: string, username?: string }
  ]
}

---

冪等なステージ遷移とフロー途中の変更

ステージは再入可能ではありません。各ステージを実行する前に、その status を確認します：running → 「Stage N is already in progress」と返信し、何も行いません、passed → 再実行の前に明示的な確認を求めます、failed → 再実行（リカバリー）、pending → 進めます。実行の開始時（ユーザー入力時ではなく）に running を設定し、誤った二重確認によってステージが 2 回実行されることがないようにします。

後続のステージが進行中／保留中に、ユーザーが以前のステージの入力に対する変更を要求した場合は、まず影響評価を実行します：適用せずに了承し、影響を受けるステージと受けないステージを特定し、選択肢（影響を受けるステージの再実行／前方のみ適用／キャンセル）を提示し、決定を待ちます。破壊的な変更の警告を明示します（有効化されたテリトリーモデルは削除できません。既存のユーザー／レコード／公開済みテンプレートは残ります）。

完全な動作マトリクス、影響評価テンプレート、変更ごとの影響マッピング、破壊的な変更の警告は references/state-machine-and-changes.md にあります。

---

ルール／制約

• 組織：最初に Phase 0 の組織選択を実行してください。デフォルトの組織を黙って再利用しないでください。
• 共有フォルダー：.lsc-starter-config/LSStarterConfig をダウンロードするのは一度だけです（Phase 1 の必須ゲート）。削除するのも一度だけです（Phase 9）。子スキルはこのファイルに触れません。Stage 2 と 5 で読み取るため、ファイルなしで進めると後続処理が失敗します。
• 順序：ステージは必ず 1→6 の順に実行し、各ステージは前のステージが成功した場合にのみ実行してください。後続ステージで使う各ステージの出力（ID、名前）を記録してください。
• テリトリーの不変条件：Stage 5（ProductTerritoryAvailability）と Stage 6（ユーザーのアラインメント）では、Stage 3 のレベル 3 のテリトリー（OrchestrationState.territoryId）を必ず再利用してください。そうしないと、KAM ユーザーにデータが表示されません。
• 確認：各ステージで管理者が確認できる項目として指定されているものだけを確認してください。それ以外は自動的に導出し、確認のために表示してください。
• 冪等性：確認なしで running／passed のステージを再実行しないでください（実行開始時に running に設定）。フロー途中の変更を適用する前に、影響を評価してください。

---

注意点

問題	解決方法
Phase 1 でソースのダウンロードに失敗する	そこで処理を停止してください。いずれのステージも実行しないでください。原因を修正するか、.lsc-starter-config/LSStarterConfig を手動で CWD にダウンロードしてから、再実行してください
接続済みの組織が見つからない	Phase 0 で新しい組織へのログイン（sf org login web）に直接進んでください
前回の実行で生成された成果物が存在する	子スキル／参照先は冪等性があり、アップサートにも対応しています。クエリで確認してから、スキップするか再実行してください
ステージが再トリガーされた、またはフロー途中で以前の入力が変更された	references/state-machine-and-changes.md を参照してください

---

再開／部分的な再実行

ユーザーがすでに一部のステージを完了している可能性がある場合は、どのステージを完了したか尋ねてください。その後、完了したと申告された各ステージを組織へのクエリで検証します（1 = 尋ねる、2 = LSC Custom Profile、3 = アクティブなモデル + L3 テリトリー、4 = ParticipantRole + Sprint、5 = Account + ProductTerritoryAvailability + Final バージョン + 割り当て、6 = kam ユーザー + 権限セット + テリトリー）。検証済みのステージはスキップし、最初の未完了ステージから再開してください。ステージごとの正確なクエリは、references/orchestration-flow.md → Resume Logic を参照してください。

---

参照ファイル一覧

ファイル	読むタイミング
references/orchestration-flow.md	開始時 — 依存関係図、ゲートと再開検出のクエリ、所要時間
references/state-machine-and-changes.md	ステージが再トリガーされた場合、またはフロー途中で入力が変更された場合
references/stage-2-starter-config-overview.md	Stage 2 — 13 ステップのデプロイ + KAM／Sprint 設定レコード（関連する参照ファイルへのリンクあり）
references/stage-4-participant-role-and-sprint.md	Stage 4 — 参加者ロール + スプリント
references/stage-5-data-and-plan-templates-overview.md	Stage 5 — KAM データの作成（Part A。データ参照ファイルへのリンクあり）+ 目標、タスク、評価指標、アクションプランのテンプレート（Part B）
references/stage-6-user-provisioning-overview.md	Stage 6 — ユーザーのプロビジョニング + メタデータキャッシュ（関連する参照ファイルへのリンクあり）
references/stage-6-ipad-validation-script.md	最終ステップ — メタデータキャッシュが Active になった後に表示される、デバイス（iPad）上での検証スクリプト