---
sourceDocument: Yokohama ビルドのワークフロー
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/build-workflows

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama ビルドのワークフロー

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# ValidateUpdateSetParentDependencies

# ValidateUpdateSetParentDependencies {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

ザ ValidateUpdateSetParentDependencies バリデーターは、現在のワークフローをサブフローとして呼び出すすべてのワークフローを識別し、進行中の別の更新セットでこれらの親ワークフローのいずれかが編集されているかどうかを判断します。
この警告は、このワークフローと、このワークフローに依存する1つ以上のワークフローが、追加の労力なしに別のインスタンスに同時に展開されないように積極的に変更されていることを通知します。

## 検証の要約

* リスク： 親ワークフローが1つの更新セットで編集され、その従属サブフローが別のワークフローで編集されている場合、2つのワークフローは異なるインスタンスに移動されたときに互換性がない場合があります。共通または期待値の編集などの独立した変更を行うと、2つのワークフローが互換性がなくなります。
* 重大度： 警告
* 有効な結果： 有効
* 有効なメッセージ： Update Setの依存関係の問題は見つかりませんでした。
* 無効な結果： 無効
* 無効なメッセージ： このワークフローには、異なる更新セットに属する依存ワークフローがあります。
* 推奨処置： 両方のワークフローを同じ更新セットに変更して展開します。個別の更新セットで依存関係を変更する必要がある場合は、次のいずれかの方法を使用します。
  * すべての更新セットが同時に移行されることを確認します。
  * メインフローアップデートセットを展開する前に、そのアップデートセットを完了するように設定する前に、依存関係を1つのアップデートセットにマージします。
* パブリッシュ可能： はい
* 実行可能ファイル： はい
* 関連情報: [更新セットを使用したワークフローの移動](https://servicenow-prod.fluidtopics.net/rnY6et3N3JRJpTGBpb1FmA#c_WorkflowMovementWithUpdateSets "ワークフロー情報は複数のテーブルに格納されるため、システムは他のレコードとは異なる方法で更新セットのワークフローを追跡します。")

## トラブルシューティング

ワークフローは、ワークフローが公開されたときにのみ更新セットに追加されます。このバリデータは、次のいずれかの条件が存在する場合に警告を発行します。

* 公開されたサブフローは、親ワークフローとは異なる更新セットにあり、その更新セットは進行中です。
* サブフローは、現在のユーザーとは異なる更新セットで作業している別のユーザーによってチェックアウトされます。

注:  
このバリデーターは、クローズされた更新セットを検索しません。進行中の更新セットまたは現在のワークフローを呼び出すすべての親ワークフローの更新セットのみを表示し、異なる更新セットで作業しているユーザーにチェックアウトされます。

## 例

以下は、2人のユーザーが異なる更新セットのワークフロー間で依存関係を作成する、アットリスクの開発シナリオの例です。

ユーザーA：

1. セットAを現在のアップデートセットに設定します。
2. ワークフローAをチェックアウトします。
3. 戻り値を変更します。 文字列ワークフローAをaに入力します。 リファレンス/ユーザータイプ。
4. ワークフローAを発行し、更新セットAにエントリを引き起こします。

ユーザーB：

1. アップデートセットBを現在のアップデートセットに設定します。
2. ワークフローBをチェックアウトします。
3. サブフローとしてワークフローAを含みます。
4. Workflow Aのユーザー参照戻り値を承認割り当てとして使用します。
5. ワークフローBを発行し、Update Set Bにエントリします。

## リスク

* ユーザーBは、ワークフローAの古いバージョンを持つ別のインスタンスに更新セットBを移動します。戻り値は、ワークフローBの結果が開発時にテストされた結果と異なる原因となるユーザー参照ではありません。
* ユーザーBは、ワークフローAのバージョンを持たない新しいインスタンスに更新セットBを移動します。ワークフローBは実行時に検証エラーが発生し、実行できません。ログエントリは、現在のレコードのワークフローログに追加されます。

## 可能な解決策

ソリューション

同じ更新セットを使用して、親ワークフローとすべての従属ワークフローを一緒に新しいインスタンスに移行します。

1. 更新セットを、新しいインスタンスに移行するセットに設定します。
2. 含まれる必要があるワークフローを確認して再公開します。  
   注:  
   このアクションは、現在の更新セットにエントリを強制します。
3. すべての依存関係の更新セットを完了します。
4. 更新セットをローカルインスタンスに移行するための標準的な手順に従います。Update Sets の詳細については、「[システムアップデートセット](https://www.servicenow.com/docs/access?context=system-update-sets&version=yokohama&pubname=yokohama-application-development&ft:locale=en-US)」を参照してください。

ソリューション 2

更新セット間で依存ワークフローを移動します。

1. 移行するメインワークフローを含む更新セットを特定します。
2. 移動先 システムアップデートセットローカル更新セット.
3. メインワークフローへの依存関係を含む更新セットを検索して選択します。
4. 顧客の更新の中に移動するサブフローのワークフローバージョンを選択します。
5. アップデートセットフィールドの中に親ワークフローを含む更新セットを選択します。このフィールドがCustomer Updateフォームにない場合は、フォームを構成してフィールドを追加します。
6. \[更新\] をクリックします。ベースシステムは、従属サブフローを選択された更新セットに移動します。
7. ステップ4-6を繰り返して、親フロー更新セットに従属サブフローを追加します。