field-service-data-capture-migrate

フィールドサービスのモバイルフローを Data Capture に移行する

このスキルは、完全に自動化された XML 変換ツールを使用して、従来の Field Service モバイルフロー（processType='FieldServiceMobile'）を DataCaptureFlow に移行します。変換ツールは、フィールド型の変換、実行グラフの再構成、変数の重複排除、プラットフォームイベントの削除など、既知のすべての移行パターンに対応します。

目標： Field Service のお客様を Mobile Screen Flows から移行し、Field Service のデジタルフォームにおける戦略的な方向性である Data Capture を活用できるようにします。

SKILL_ROOT="${SKILL_ROOT:-${PLUGIN_ROOT:-$HOME/.vibe/skills}/field-service-data-capture-migrate}"
SCR="$SKILL_ROOT/scripts"
OUT="${FSM_OUT:-$PWD}"  # *_DC files land in cwd; override via FSM_OUT.

---

移行する理由

機能	Mobile Screen Flow	Data Capture Flow
条件付き表示	いいえ — 別々の画面を使って回避	はい — 単一の画面内に標準搭載
フィールド間検証	いいえ — 「次へ」を押したときのみ検証	はい — リアルタイムで即時にフィードバック
オフライン	はい — 優れている（Briefcase の事前読み込み）	はい — より優れている。オフライン優先、自動保存／一時停止に対応
繰り返しセクション	はい — UX は中程度（Loop と画面を使用）	はい — UX が向上（標準の Repeater）
モバイル UX	はい — 良好	はい — より優れている。クリック数が少なく、画面内ロジックに対応
依存選択リスト	はい — モバイルのみ	一部対応 — 条件付きフィルタリングのみ（ロードマップ）
バックオフィスでの完了	はい — 対応	いいえ — ロードマップ
送信後のフォーム編集	いいえ — 制限あり	いいえ — ロードマップ
将来への対応	いいえ — レガシーな方式	はい — AI、Voice to Form、継続的な投資

---

自動移行ワークフロー

ステップ 0 — まず移行範囲を明確にする

組織にクエリを実行する前に、ユーザーの意図を確認してください。 リクエストが曖昧な場合（例：「フローを移行して」「組織のフローを移行して」）は、特定の 1 つのフロー、名前を指定した複数のフロー、組織内の Field Service モバイルフローすべてのどれを指しているのか、明確に確認してください。範囲が明確になってから、ステップ 1 に進んでください。 ユーザーが明示的に希望しない限り、すべてのフローにクエリを実行してはいけません。

ステップ 1 — フローを検出する

REST API エンドポイント： GET /services/data/v67.0/tooling/query。認証には Authorization: Bearer <token> を使用します。curl --config を使用してください。-H は ps／/proc 経由で漏えいします。

# All Field Service Mobile flows:
# SOQL: SELECT Id, MasterLabel, ProcessType, Status, VersionNumber FROM Flow
#       WHERE ProcessType = 'FieldServiceMobile' AND Status IN ('Active','Draft')
#       ORDER BY MasterLabel, VersionNumber DESC
curl -X GET "https://<instance>.my.salesforce.com/services/data/v67.0/tooling/query?q=SELECT+Id%2C+MasterLabel%2C+ProcessType%2C+Status%2C+VersionNumber+FROM+Flow+WHERE+ProcessType+%3D+%27FieldServiceMobile%27+AND+Status+IN+%28%27Active%27%2C%27Draft%27%29+ORDER+BY+MasterLabel%2C+VersionNumber+DESC" \
  --config <(printf 'header = "Authorization: Bearer %s"\n' "$TOKEN")

# One or more named flows — add: AND MasterLabel IN ('Work Order Wizard', 'Asset Inspection')

レスポンス形式：

{
  "size": 2, "totalSize": 2, "done": true,
  "records": [
    {"Id": "301xx000000001", "MasterLabel": "Asset Inspection", "ProcessType": "FieldServiceMobile", "Status": "Active", "VersionNumber": 5}
  ]
}

URL エンコード：スペース → +／%20、'→%27、,→%2C、(/)→%28／%29、=→%3D。

クエリ結果をユーザーに提示してください（表またはリスト）。ユーザーが特定のフローを指定していて、その中に見つからないものがあれば、すぐに報告してください。

ステップ 2 — フローの XML を取得する

フローファイルを直接受け取っていて、組織にアクセスしない場合： ステップ 1～2 をスキップし、各ファイルに対してその場でステップ 4 を実行します（サブフローを先に処理し、--is-subflow を指定）。<Name>_DC.flow-meta.xml を現在のディレクトリに書き込み、ステップ 5～6（組織のみが対象）はスキップしてください。それ以外の場合は、組織から取得します。

mkdir -p /tmp/fsm-migration/project && cd /tmp/fsm-migration/project
echo '{"packageDirectories":[{"path":"force-app","default":true}],"namespace":"","sourceApiVersion":"67.0"}' > sfdx-project.json

# Single flow:
sf project retrieve start --metadata "Flow:<FlowApiName>" --target-org <alias>
# Multiple (comma-separated, no spaces after commas):
sf project retrieve start --metadata "Flow:<Flow1>,Flow:<Flow2>" --target-org <alias>
# All flows (ONLY if the user explicitly confirmed "all" in Step 0):
sf project retrieve start --metadata "Flow" --target-org <alias>

重要： --metadata は、ステップ 0 でユーザーが選択した範囲と一致させてください。明示的に確認されない限り、すべてのフローを取得してはいけません。（このステップに相当する REST の方法はまだありません。references/architecture-notes.md を参照してください。）

ステップ 3 — 移行候補を検証する

FieldServiceMobile の processType が設定され、かつ <screens> 要素が少なくとも 1 つあるフローのみが、有効な候補です。

migratable=()
for f in force-app/main/default/flows/*.flow-meta.xml; do
  base=$(basename "$f" .flow-meta.xml)
  if grep -q "FieldServiceMobile" "$f"; then
    if grep -q "<screens>" "$f"; then
      echo "[MIGRATABLE] $base"; migratable+=("$f")
    else
      echo "[NO SCREENS] $base — cannot migrate (pure automation flow)"
    fi
  else
    processType=$(grep -oP '(?<=<processType>)[^<]+' "$f" || echo "unknown")
    echo "[NOT FSM] $base — processType is '$processType'"
  fi
done | sort
echo "Migratable flows: ${#migratable[@]}"

ユーザーが特定のフローを指定していて、その中に検証に失敗したものがある場合は、そこで停止して問題を報告してください。ユーザーが無効なフローをスキップすることを確認しない限り、一部だけを移行してはいけません。ユーザーが「すべて移行」と確認した場合は、移行可能なものに絞り込み、続行する前に件数を報告してください。純粋な自動化フロー（<screens> がないもの）はそのままにするか、AutoLaunched フローにしてください。該当するフローには注意を促しますが、移行はしないでください。

ステップ 3b — サブフローの依存関係ツリーを解決する（合成フロー）

サブフローを呼び出すフローは、リーフから順に移行する必要があります。呼び出し元は、参照するすべての _DC サブフローがデプロイ対象に存在するまで検証できません。

python3 "$SCR/discover_subflow_tree.py" \
  force-app/main/default/flows \
  force-app/main/default/flows/<CallerFlowApiName>.flow-meta.xml \
  --json /tmp/fsm-migration/subflow-tree.json

終了コード	意味	対応
0	すべてのノードが移行可能です	出力された順序で変換し（ステップ 4）、その後バンドルを検証します（ステップ 5）
1	1 つ以上の依存関係がブロックされている（FSM ではない、画面がない、循環している）か、見つかりません	停止 — 呼び出し元をデプロイしないでください。 ブロックしているノードを報告します。
2	使用方法に誤りがあります	flows ディレクトリと、少なくとも 1 つの呼び出し元パス（または --all）を渡してください

ステップ 4 の変換順には JSON の order 配列を使用し、ステップ 5 にはファイル一覧を使用してください。

ステップ 4 — 各フローを変換する

OUT="${FSM_OUT:-$PWD}"; mkdir -p "$OUT"
# Input: the retrieved project path below, or just <FlowApiName>.flow-meta.xml if handed the file.
python3 "$SCR/transform_flow.py" \
  force-app/main/default/flows/<FlowApiName>.flow-meta.xml \
  "$OUT/<FlowApiName>_DC.flow-meta.xml"

ステップ 3b のツリーで depth > 0 と報告されたすべてのノードには、--is-subflow を渡してください。 DataCaptureFlow のサブフローには Create／Update／Delete を含められません。--is-subflow は CUD を無条件に除去し（単に順序を変更するのではありません）、CUD のフォールトパス違反をフォールト切断の前処理に通します。通常の処理が正しいのは、最上位の呼び出し元（depth == 0）のみです。実際のサブフローでこれを省略すると、ステップ 3b で防止されるデプロイエラー「You can't use Create, Update, or Delete elements in a Data Capture flow subflow」が再発します。

python3 "$SCR/subflow_names.py" <FlowApiName> を使用して正しい出力ファイル名を導出してください。名前が上書きされている場合、単純な _DC サフィックスでは呼び出し元の書き換え後の参照と一致せず、バンドルのドライランが失敗します。

変換ツールは、変換されたフィールド、CUD の修正、警告を報告します。サポート対象外の要素（Apex／アクション呼び出し、サブフロー、フォールトパス、カスタムコンポーネント、不明なフィールド型）がある場合は、_incompleteMigration リストと `` XML コメントが生成されます。サポート対象外のフィールドスロットは、読み取り専用の DisplayText プレースホルダーになり、ShortText 入力に黙って変換されることはありません。

変換は並列で一括実行してください — 各フローの変換は独立しているため、逐次ループではなく、並列数を制限した xargs -P4 を使用してください。ステップ 3b で subflow-tree.json が生成された場合は、各フローの depth を調べて --is-subflow を追加するかどうか判断します。ツリーにないフロー（合成された依存関係がないフロー）は、常に最上位の呼び出し元です。

OUT="${FSM_OUT:-$PWD}"; mkdir -p "$OUT"
TREE=/tmp/fsm-migration/subflow-tree.json
find force-app/main/default/flows -maxdepth 1 -name '*.flow-meta.xml' -print0 \
  | while IFS= read -r -d '' f; do
      grep -q "FieldServiceMobile" "$f" && grep -q "<screens>" "$f" && printf '%s\0' "$f"
    done \
  | xargs -0 -I{} -P4 bash -c '
      f="{}"; base=$(basename "$f" .flow-meta.xml)
      dcname=$(python3 "'"$SCR"'/subflow_names.py" "$base")
      subflowFlag=""
      if [ -f "'"$TREE"'" ]; then
        depth=$(jq -r --arg n "$base" "(.order[] | select(.apiName == \$n) | .depth) // 0" "'"$TREE"'")
        [ "$depth" -gt 0 ] 2>/dev/null && subflowFlag="--is-subflow"
      fi
      python3 "'"$SCR"'/transform_flow.py" "$f" "'"$OUT"'/${dcname}.flow-meta.xml" $subflowFlag 2>&1 \
        | grep -E "(Transformed|SKIPPED|CUD|Warning)"
    '

合成ツリーでも安全です。各変換はリーフの出力を読み込まず（1 つのフローを入力し、1 つのフローを出力します）、ここでは順序付けは不要です。ステップ 3b のリーフから順に処理する順序が重要なのは、ステップ 5 のバンドルのドライランのみです。

出力名の衝突： subflow_names.py によって、2 つのソースフローが同じ dcname に解決されてはなりません。-P4 では、同じファイルへの同時書き込みになるためです。バッチに名前の上書きがある場合は、後で確認してください。find "${FSM_OUT:-$PWD}" -maxdepth 1 -name '*_DC.flow-meta.xml' | sort | uniq -d

ステップ 4b — 移行サマリーを生成する

SUM=/tmp/fsm-migration/summaries; mkdir -p $SUM /tmp/fsm-migration/spec
find force-app/main/default/flows -maxdepth 1 -name '*.flow-meta.xml' -print0 \
  | while IFS= read -r -d '' f; do
      grep -q "FieldServiceMobile" "$f" && grep -q "<screens>" "$f" && printf '%s\0' "$f"
    done \
  | xargs -0 -I{} -P4 bash -c '
      f="{}"; base=$(basename "$f" .flow-meta.xml)
      python3 "'"$SCR"'/convert_to_dc_spec.py" "$f" "/tmp/fsm-migration/spec/${base}.json"
      python3 "'"$SCR"'/generate_summary.py" \
        "/tmp/fsm-migration/spec/${base}.json" \
        "'"$SUM"'/${base}-migration-summary.md"
    '

サマリーには、コンポーネントのマッピング（[OK]／[WARNING]／[ERROR] の接頭辞）、条件ロジックの判断、サポート対象外のコンポーネント、動作に関する注記、オフラインでの事前準備に関する警告、手動のレビュー用チェックリスト、そして明確にラベル付けされたアドバイザリのプレースホルダー（AI 生成の文章を含めてよい唯一の場所）が記載されます。generate_summary.py は決定論的に動作し、必ずこの .md を書き出します。これはステップ 4c でキャンバスに渡す入力であると同時に、オフライン時のフォールバック成果物でもあります。

Step 4c — レビューの共有方法を確認して公開する

対話形式の場合は、必ず明示的に確認してください。暗黙に既定の方法を選ばないでください。「移行の概要を Slack に投稿しますか、それとも .md ファイルとしてダウンロードしますか？」Step 4b で作成したフローごとの .md はどちらの場合も存在します。この確認で決まるのは、Slack のキャンバスも作成するかどうかだけです。

• **Slack：**投稿先のチャンネルを確認し、回答を待ってください。チャンネルが決まる前にキャンバスを作成してはいけません（以前使ったチャンネルを提案する場合も、確認してください）。キャンバスの作成には slack_create_canvas MCP ツールを使います（Python からはアクセスできません）。フローごとに、${base}-migration-summary.md を読み込み、先頭の # Migration Summary: <formTitle> H1 を削除します（キャンバスではタイトルを別途指定します）。タイトルを Migration Summary: <formTitle> として、残りを内容に設定したキャンバスを作成します。slack_send_message でそのリンクをチャンネルに投稿し、Step 7 用に URL を記録します。チャンネルを記憶しておいてください。
• **ファイルのダウンロード：**Step 4b ですでに書き出した .md のパスを案内します。それ以上の作業は不要です。

**フォールバック：**ユーザーと対話できない場合、または Slack が利用できない／キャンバスでエラーが発生した場合は、.md のパスへ進みます。どちらの場合も実行は成功します。

Step 5 — 検証（ドライラン）

任意の、デプロイ前に行う非破壊的なゲートです。組織エイリアスが利用可能な場合に限ります。実行前に確認してください（実時間がかかりますが、出力の生成には必須ではありません。オフライン実行では省略しても成功します）。「デプロイ前に <alias> に対してドライラン検証を実行しますか？（yes/no）」SE が拒否した場合は、以下の終了コード 3 として扱い、Draft のみでデプロイしてください（このスキルでデプロイされるステータスは Draft だけです）。

**フローごとではなく、既定で 1 つのバンドルに対してドライランを実行してください。**これにより、ツリー内の _DC サブフロー参照がデプロイ対象セット内で解決されます（呼び出し元のサブフローがまだデプロイされていない場合、フローごとに分離したドライランは失敗します）。バンドルで複数のフローに対して失敗し、原因を特定する必要がある場合に限り、フローごとの実行に切り替えてください。

OUT="${FSM_OUT:-$PWD}"
set --
while IFS= read -r -d '' f; do set -- "$@" "$f"; done \
  < <(find "$OUT" -maxdepth 1 -name '*_DC.flow-meta.xml' -print0)
if [ "$#" -gt 0 ]; then
  "$SCR/validate_flow.sh" --bundle "<alias>" "$@"
  code=$?
  if [ "$code" -eq 1 ] && [ "$#" -gt 1 ]; then
    echo "Bundle dry-run failed — re-running per-flow to attribute the failure(s):"
    "$SCR/validate_flow.sh" "<alias>" "$@"
    code=$?
  fi
else
  echo "No migrated flows to validate."; code=0
fi

フローごとに実行するフォールバックでは、呼び出し元が _DC サブフローを参照していると、問題がなくても失敗します（そのサブフローは分離されたデプロイ対象セットに含まれないためです）。既知の呼び出し元に対する flow doesn't exist という失敗は、実際の不具合ではなく、この分離によるものとして扱ってください。

終了コード	意味	対応
0	すべてのフローの検証に成功	Step 6 に進み、デプロイします（Draft）
1	1 つ以上のフローでドライランに失敗したか、ファイルが見つからない	手動修正用に出力を組織内に置く場合は Draft としてデプロイします。それ以外の場合は、トランスフォーマーの不足箇所を修正して再検証してください。
2	使用方法のエラー（引数が 0 個）	上記の存在チェックで防止されるはずです
3	対象組織がないため、検証を省略	オフラインでは想定どおりです。出力は有効で、検証は保留されています

deploy_flow.sh はドライランの結果にかかわらず、常に Draft としてデプロイします。ドライランに失敗した場合は、デプロイはまだ行う価値がないことを意味します。

**任意のライブスモークテスト（手動。CI では実行しません）。**バンドルのドライランでスクリプトの仕様を確認でき、実際の組織に対して一度実行すれば、出力が実際にデプロイできることを確認できます。

"$SCR/validate_flow.sh" <org-alias> "${FSM_OUT:-$PWD}/<FlowApiName>_DC.flow-meta.xml"
# Expected: exit 0, "PASS  <FlowApiName>_DC.flow-meta.xml"

Step 6 — デプロイ（開始＋ロールバック用スナップショット）

OUT="${FSM_OUT:-$PWD}"
set --
while IFS= read -r -d '' f; do set -- "$@" "$f"; done \
  < <(find "$OUT" -maxdepth 1 -name '*_DC.flow-meta.xml' -print0)

"$SCR/deploy_flow.sh" <alias> "$@"

deploy_flow.sh は、書き込みを行う前に、対象となるすべてのフローについてデプロイ前の組織状態のロールバック用スナップショットを取得し、SE による明示的な確認（Proceed? [y/N]。無人デモで確認を省略するには --yes を指定）を受けてからデプロイします。すべてのデプロイはDraft のみです。ソースの内容にかかわらず、デプロイ用コピーの <status> は強制的に Draft に書き換えられるため、ここで Active をデプロイすることはできません。有効化は手動で行う Step 8 の作業です。

終了コード	意味	対応
0	デプロイ成功	Step 7 に進みます。ロールバック用のスナップショットのパスが表示されます。
1	デプロイ失敗、スナップショットのクエリ失敗、またはフローファイルの不足	停止してください。 Status: の下にあるコンポーネントエラーを確認します。
2	使用方法のエラー（フローファイルがない）	find が何も検出しませんでした。出力ディレクトリを確認します。
3	対象の組織がないためデプロイをスキップ	オフラインの場合は想定どおりです。何も書き込まれていません。
4	SE が確認プロンプトを拒否	何も書き込まれていません。スナップショットは参照用に保持されます。

ロールバック用スナップショット： /tmp/fsm-migration/rollback/<timestamp>/snapshot.json に書き込まれます。フローごとに existedBeforeDeploy の値と、デプロイ前に存在していた場合は以前のラベル、アクティブバージョン、最新バージョンの ID が記録されます。復元するには、スナップショットで特定したバージョンを再デプロイします。ただし、このデプロイ後にデプロイ済みの _DC フローを誰も編集していないことを確認してください。編集があった場合、その変更は失われます。

デプロイ順序： 呼び出し元より先にサブフロー（リーフ）をデプロイします。Step 3b の discover_subflow_tree.py が出力する order の順序を使用します。

Step 7 — 検証と報告

# REST API: GET /services/data/v67.0/tooling/query
# SOQL: SELECT MasterLabel, Status FROM Flow
#       WHERE ProcessType = 'DataCaptureFlow' AND Status IN ('Draft','Active') ORDER BY MasterLabel
curl -X GET "https://<instance>.my.salesforce.com/services/data/v67.0/tooling/query?q=SELECT+MasterLabel%2C+Status+FROM+Flow+WHERE+ProcessType+%3D+%27DataCaptureFlow%27+AND+Status+IN+%28%27Draft%27%2C%27Active%27%29+ORDER+BY+MasterLabel" \
  --config <(printf 'header = "Authorization: Bearer %s"\n' "$TOKEN")

応答形式：

{
  "size": 3, "totalSize": 3, "done": true,
  "records": [
    {"MasterLabel": "Asset Inspection_DC", "Status": "Active"}
  ]
}

# Functional equivalence check (runs on the SOURCE FieldServiceMobile flow, not the _DC output):
python3 "$SCR/analyze_flow.py" \
  force-app/main/default/flows/<FlowApiName>.flow-meta.xml \
  /tmp/fsm-migration/analysis/<FlowApiName>.json

ユーザーが手動で有効化する（Step 8）前に、警告があれば提示してください。

バッチ処理の後、Step 4c で選択した配信方法に合わせて集約実行レポートを公開します。以下を含めます。移行したフロー（件数と名前）、フローごとのドライラン／デプロイ結果（終了コード別）、集約した GREEN／YELLOW／RED／SKIP のリスク件数、コンポーネントの [WARNING]／[ERROR] の合計件数、フローごとのレポートへのリンク／パス。

• Slack： Step 4c のフローごとのキャンバスにリンクした集約キャンバスを 1 つ作成し、同じ送信先に投稿します。
• ファイルのダウンロード： Step 4b のフローごとの .md パスを集約レポートとして列挙します。別ファイルは不要です。

Step 8 — 有効化と旧バージョンの無効化

移行したフローを稼働させる方法はこれだけです。フローが自動で有効化されることはありません。Flow Builder で検証し、デバイスでテストしたら、DC フローを開いて Activate をクリックし、古い Field Service Mobile Flow を無効化します（無効のままにし、十分な検証が完了するまで削除しないでください）。

---

トランスフォーマーの仕組み

transform_flow.py は、フィールド型の変換、必須要素の挿入、ラベルの配置、CUD を末尾に配置するグラフの再構成（4 つのパターン、最大 50 回の収束反復）を扱う、直接的な XML-to-XML トランスフォーマーです。フィールド型の完全なマッピング表、自動修正の全リスト、および移行後に動作が変わる項目（ルックアップの実行順序、プラットフォームイベント、確認画面の配置、定数）については、references/transformer-rules.md を参照してください。

自動化できないパターン（Flow Builder の再設計が必要）

パターン	自動化できない理由	推奨される再設計
画面なし（純粋な自動化）	DataCaptureFlow には少なくとも 1 つの画面が必要です	Field Service Mobile Flow のままにするか、AutoLaunchedFlow に変換します
ループ内の画面	DC はループ内の画面をサポートしていません（検出して警告を表示）	ループ＋画面を、DC ネイティブの Repeater フィールドに置き換えます
作成したばかりのレコードに依存するルックアップ	Create → Get (by new ID) → Create again のサイクルです。DC ではすべての CUD を最後に行う必要があります	画面の前にすべてのルックアップを行い、変数に蓄積して、最後に一括作成します
CUD の後に表示される確認画面	DC では CUD の前に画面を配置する必要があります	CUD 前の概要画面に移動するか、DisplayText を使って保存内容をプレビューします
バックオフィス／デスクトップでの完了が必要	DC フォームは FSL Mobile でのみ完了できます（ロードマップに記載）	ロードマップの機能がリリースされるまで、Field Service Mobile Flow のままにします
完全な依存関係ピックリスト	DC が現在サポートしているのは条件付きフィルタリングのみです（ロードマップに記載）	回避策として条件付き表示を使用します

移行リスクの分類

リスク	基準	自動化可能か
GREEN	ループ内に画面がなく、create→lookup のサイクルがなく、プラットフォームイベントもありません	はい — 完全に自動化されます
YELLOW	プラットフォームイベント、画面後のルックアップの繰り上げ、定数、非表示フィールドの isRequired、または複雑な DisplayText 数式があります	はい — 警告付きで自動化されます。有効化の前に確認してください
RED — 再構成可能	グラフ再構成ツールが自動的に修正する CUD 違反があります	はい — 自動化され、トランスフォーマーが解決します
RED — 再設計が必要	ループ内の画面、create→lookup のサイクル、Range スライダーフィールドがあります	いいえ — Flow Builder での手動による再設計が必要です
SKIP	画面のない純粋な自動化フローです	いいえ — DataCaptureFlow の候補ではありません

DataCaptureFlow プラットフォームの正式なルール（必須ヘッダー、構造ルール、アクセサーのサフィックス、DisplayText の制限、Repeater の詳細、グローバル変数の許可リスト）については、デプロイエラーのデバッグや移行したフローの手動検証の際に references/dc-platform-rules.md を参照してください。実際のデプロイエラーとその修正方法の一覧については、references/known-deploy-errors.md を参照してください。上記の手順のうち、sf CLI と REST のどちらが引き続き必要か、その理由については、references/architecture-notes.md を参照してください。

有効化の前に確認すること

デプロイ後、Flow Builder で各 DC フローを開き、次の項目を確認してください。

1. トランスフォーマーの警告を確認する — 画面フィールドでフィルタリングしていた繰り上げ済みのルックアップがある場合は、手動で対応する必要があります
2. プラットフォームイベントが削除されている — 元のフローがリアルタイムのディスパッチャーイベントを発行していた場合は、代替トリガー（Apex または AutoLaunched フロー）を用意してください
3. 非表示フィールドの isRequired — トランスフォーマーが警告した項目については、isRequired をクリアして、代わりに validationRule を追加してください
4. DisplayText の数式 — IF／CASE／日付計算の結果を Assignment で事前計算し、代わりに単純な変数を参照してください
5. 計算のタイミング — 計算要素が表示画面と同じ画面ではなく、その前の画面に配置されていることを確認してください
6. 画面の順序とラベル — 並べ替えた画面が引き続き適切であることを確認してください
7. ルックアップの表示 — Lookup フィールドに正しいラベルが表示されていることを確認してください。必要に応じて Primary Compact Layout を調整してください
8. Range スライダーフィールド — dcNumeric または dcCounter に手動で置き換えてください
9. FSL Mobile でテストする — デバイスでフォームを最初から最後まで完了してください
10. オフラインでテストする — 機内モードでフォームを完了 → 再接続 → 同期を確認

---

このスキルのファイル

• scripts/transform_flow.py — 主な移行ツールです。XML から XML への直接変換を行います。各ソースフローに対して実行します（ステップ 4）。
• scripts/subflow_names.py — 移行後のサブフローの命名規則を定める唯一の情報源です。transform_flow.py と discover_subflow_tree.py からインポートされます。
• scripts/discover_subflow_tree.py — サブフローの推移的な依存関係を検出します。末端から順に並べた実行順序を作成し、各ノードを移行可能／ブロック済み／不足に分類します（ステップ 3b）。
• scripts/analyze_flow.py — リスク評価ツールです。ソースフローに対して実行し、変更を加えずに JSON を生成します（ステップ 7）。
• scripts/convert_to_dc_spec.py — 移行の概要に使用する仕様変換ツールです（ステップ 4b）。JSON 出力は scripts/vendor/build_flow.py の入力契約に準拠する必要があります（references/converter-builder-contract.md を参照）。
• scripts/generate_summary.py — 仕様 JSON から、人が読める migration-summary.md を生成します（ステップ 4b）。決定論的に動作し、オフラインで実行できます。
• scripts/validate_flow.sh — sf project deploy start --dry-run をラップするドライラン検証ツールです。終了コードは、0=すべて成功、1=1 件以上失敗、2=使用方法の誤り、3=スキップ（org なし）です（ステップ 5）。
• scripts/deploy_flow.sh — デプロイの開始とロールバック用スナップショットの作成を行います。終了コードは、0=デプロイ済み、1=失敗、2=使用方法の誤り、3=スキップ、4=SE が拒否です（ステップ 6）。
• scripts/fsm_dc_catalog.py — FSM と DC の機能同等性を定める正式なカタログです。ここの FIELD_TYPE_MAP は、references/transformer-rules.md のマッピングテーブルと常に同期させてください。
• scripts/cud_analysis.py、scripts/flow_input.py、scripts/flow_xml_utils.py、scripts/json_to_flow_xml.py、scripts/manual_review_flags.py — 上記のスクリプトからインポートされる共通の内部モジュールです。
• scripts/retrieve_flow_rest.sh — REST ベースのフロー取得を試験的に行うスクリプトです。ステップ 2 にはまだ組み込まれていません（references/architecture-notes.md を参照）。
• scripts/vendor/build_flow.py — convert_to_dc_spec.py の契約で使用される、ベンダー提供の Data Capture ビルダースクリプトです。
• references/fsm-dc-capability-catalog.md — fsm_dc_catalog.py の人が読める形式の対応ファイルです。サポート対象／対象外の判断に関する信頼できる情報源です。
• references/component-mapping.md — コンポーネントの同等性テーブルです（上記カタログの補足資料）。
• references/converter-builder-contract.md — convert_to_dc_spec.py と build_flow.py の間の正式な JSON 契約です。
• references/migration-checklist.md — デプロイ後のテストに使用する手動検証チェックリストです。
• assets/sample-legacy-flow.flow-meta.xml — 変換ツールを一通り試すための、代表的なレガシー FieldServiceMobile フローです。