更新セット内に異なるスコープの変更が含まれる場合の挙動について

[多和田汐]

現在、ServiceNowの更新セット移送時に発生するエラーについて学習しており、異なるスコープの変更を1つの更新セットに含めた場合、移送先でどのような挙動になるのかを確認したいと考えています。

実際の挙動を確認するため、自身で2つのServiceNowインスタンスを用意し、更新セットの移送を試みましたが、インスタンス間の接続テストが正常に完了しなかったため、こちらに投稿いたしました。

【確認したいケース】

以下のような状態を想定しています。

・更新セットのスコープ：Global

・更新セット内に含まれる変更

      -Globalスコープの変更

      -Scoped Application側の変更

この更新セットを別インスタンスへ移送し、

Retrieve

Preview

Commit

を実施した場合、どのような結果になるのでしょうか。

私の認識では、Preview時にスコープの不一致によるPreview Problemが発生し、

「Update scope id 'xxxx' is different than update set scope id 'global'.」

のようなScope mismatchのエラーとなり、問題を解消するまでは更新セットをCommitできないのではないかと考えています。

また、この場合は、GlobalスコープとScoped Applicationの変更をそれぞれ別の更新セットに分けて作成し、個別に移送する必要があるという理解で合っていますでしょうか。

実際の挙動や、上記認識に誤りがありましたらご教示いただけますと幸いです。

よろしくお願いいたします。

[pr8172510]

Hi @多和田汐 ,

Your understanding is generally correct. The important point is that the scope of the Customer Update records should be checked, not only the scope/application of the Update Set itself.

If a Global Update Set contains a Customer Update from a scoped application, the scoped Customer Update can cause a scope mismatch during Preview, for example

Update scope id 'xxxx' is different than update set scope id 'global'

In that case, the affected update cannot simply be treated as a normal Global change, and the Preview Problem needs to be resolved before the Update Set can be committed successfully.

Therefore, as a best practice, keep the changes separated

• Global changes → Global Update Set
• Scoped application changes → Update Set belonging to that scoped application

You can verify the situation by opening the Update Set's Customer Updates related list and checking the Application/Scope of the individual records.

Also, I would not assume that every mixed-scope Update Set will always produce exactly the same Preview Problem. The actual result depends on the specific Customer Updates and the target instance.

So for your test case,  creating the mixed-scope Update Set, transferring it, and checking Preview Problems before committing. This will show exactly how the target instance handles the scoped Customer Update.

Separating Global and scoped changes into their respective Update Sets is the safer and recommended approach.