個人ではなくグループに作業タスクを割り当てることで、柔軟性が向上し、作業負荷の管理が改善され、タスクが効率的に処理されることが保証されます。
グループにタスクを割り当てるメリット：
グループメンバーは「マイグループの作業」から自分のタスクを選択できます✅
ServiceNowの「マイグループの作業」モジュールを使用すると、グループメンバーは自分のグループに割り当てられていないすべてのタスクを確認し、利用可能なタスクの所有権を取得できます。
これは、複数のチームメンバーがタスクの完了責任を共有する場合に特に役立ちます。
グループは、オンコールスケジュールに基づいてユーザーにタスクを割り当てることができます✅
ServiceNowのオンコールスケジューリング機能を使用すると、事前に定義されたスケジュールに基づいて、利用可能なメンバーにタスクを自動的に割り当てることができます。
これにより、勤務中のチームメンバー間で作業が公平に分配されることが保証されます。
サイトサポートメンバーは、場所に基づいてタスクを選択できます✅
タスクは、依頼の場所に基づいて動的に割り当てることができます。
これは、ITサポートチーム、フィールドサービスチーム、施設管理チームなど、業務遂行のために物理的な現場への立ち入りが必要なチームにとって特に有用です。
グループは、スキルに基づいてユーザーにタスクを割り当てることができます✅
スキルベースルーティングを使用することで、ServiceNowはタスクを、その仕事に適したスキルを持つユーザーに割り当てることができます。
例えば、依頼内容に「Windows Server管理」に関する専門知識が必要な場合、システムはそのスキルを持つグループメンバーに依頼を割り当てます。
不正解
E. グループメンバーは、SLA違反に近づいているタスクを回避できます❌
これは誤りです。ServiceNowはSLA違反を優先的に処理し、ユーザーが回避できるようにするのではなく、通常はそうしたタスクをエスカレーションします。
F. グループは、ユーザーの空き状況に基づいてタスクを割り当てることができます❌
オンコールスケジューリングでは、空き状況に基づいてタスクを割り当てることができますが、ServiceNowはリアルタイムの空き状況に基づいてタスクを動的に自動的に割り当てる機能はありません。ServiceNowでは、カスタマイズしない限り、空き状況の追跡は標準的な割り当てメカニズムではありません。
認定システム管理者（CSA）ドキュメントからの参照：
ServiceNow製品ドキュメント → 「グループへのタスクの割り当て」
ServiceNow製品ドキュメント → 「オンコールスケジューリング」
ServiceNow製品ドキュメント → 「スキルベースルーティング」

ServiceNowにおけるアップデートセットとは、あるインスタンスから構成変更（UIポリシー、ビジネスルール、クライアントスクリプトなど）を取得し、別のインスタンスに移行するための仕組みです。これにより、カスタマイズや変更内容を異なるServiceNowインスタンス間で効率的に転送することが可能になります。
別のインスタンスから更新セットを取得するプロセスは、以下の主要な手順に従います。
更新セットが完了していることを確認してください。
更新セットを移動する前に、関連するすべての変更が含まれるように、更新セットを完了済みとしてマークする必要があります。
システム更新セット > ローカル更新セットに移動し、ステータスが「完了」になっていることを確認してください。
ステータスが「処理中」の場合、更新セットを取得できません。
更新セットを取得する
対象インスタンスで、[システム更新セット] > [取得済み更新セット] に移動します。
「更新セットの取得」をクリックし、更新セットが存在するリモートインスタンスのURLを入力してください。
システムはソースインスタンスから更新セットを取得します。
プレビューアップデートセット
変更を適用する前に、ServiceNowはプレビューオプションを提供し、潜在的なエラーや既存のカスタマイズとの競合がないかを確認します。
検証を開始するには、「更新セットのプレビュー」をクリックしてください。
プレビューでは、スキップされたレコード、競合、または不足している依存関係が強調表示されます。
コミット更新セット
プレビューが成功した場合（つまり、重大なエラーがない場合）は、「更新セットをコミット」をクリックして、変更内容をインスタンスに適用します。
一度コミットされると、アップデートセットの変更内容はシステム構成にマージされます。
正解が「D. 更新セットが完全であることを確認し、取得、プレビュー、コミットする」である理由
「コミット」は正しい最終ステップです。プレビュー後、更新セットを有効にするにはコミットする必要があります。
「適用」は誤りです。ServiceNow では更新セット処理で「適用」は使用せず、代わりに「コミット」を使用します。
「接続テスト」は更新セットの取得プロセスの一部ではありません。MIDサーバーへの接続には関係しますが、更新セットには関係ありません。
したがって、正しい順序は次のとおりです。
✔ 更新セットが完了していることを確認 → 取得 → プレビュー → コミット
認定システム管理者（CSA）ドキュメントからの参照：
ServiceNow CSA 公式ドキュメント - アップデートセット管理
ServiceNowドキュメント - 更新セット（「更新セットのライフサイクル」で検索）
ServiceNowコミュニティにおけるアップデートセットに関するベストプラクティス
ServiceNowコミュニティ（「アップデートセットのベストプラクティス」で検索）
ServiceNowラーニングポータル - 管理者向け基礎知識
ServiceNow Nowラーニングプラットフォームから入手可能です（「インスタンス構成」および「更新セット」を参照してください）。

ServiceNowでは、フォーム（インシデントフォーム、変更フォーム、タスクフォームなど）を操作する際に、ユーザーはさまざまな操作を実行してレコードを保存できます。このコンテキストにおける主要な操作は、挿入と更新の2つです。
データベースに新しいレコードを作成します。
レコードを保存し、フォームを終了します（リストビューまたは前の画面に戻ります）。
レコードを挿入すると、フォームはクリアされます。
既存のレコードを変更するのではなく、新しい一意のsys_idを持つ新しいレコードを生成します。
例：
ユーザーは新しいインシデントを作成し、詳細を入力して「挿入」をクリックします。
システムは新しいインシデントを保存し、リストビューに戻ります。
既存のレコードへの変更を保存します。
保存後もフォーム上に残ります。
これは新しいレコードを作成するのではなく、既存のレコードをその場で変更します。
例：
ユーザーが既存のインシデントを開き、優先度を変更して、[更新]をクリックします。
システムは変更内容を保存しますが、ユーザーはフォーム画面に留まります。
1. 挿入操作 (オプション C の説明が正しい) 2. 更新操作 (オプション C の説明が正しい) 他のオプションが間違っている理由: A. 挿入は新しいレコードを作成し、更新は変更を保存します。どちらもフォーム上に残ります (間違い) 挿入はフォーム上に残りません。新しいレコードを作成した後、終了します。
B: Insert は新しいレコードを作成し、Update は変更を保存します。どちらもフォームを終了します (誤り)。Update はフォームを終了しません。保存後もフォーム上に残ります。
D: Insert は変更を保存してフォーム上に残りますが、Update は変更を保存してフォームを終了します (誤り) Insert は新しいレコードを作成した後に終了します。
更新内容はフォーム上に残り、終了しません。
挿入して保持：これは挿入のバリエーションで、新しいレコードを作成しますが、追加の編集のためにフォームを開いたままにします。
送信 vs. 挿入:
Submitは通常、ワークフロー処理のためにフォームを送信する場合（例：サービスカタログリクエスト）に使用されます。
Insert関数は、レコードを新規エントリとして明示的に保存します。
補足事項：
インシデント管理におけるシナリオ例：アクション
結果
「挿入」をクリックしてください。
新しいインシデントを作成し、フォームを終了します。
「更新」をクリックしてください。
既存のレコードへの変更を保存し、フォーム上に保持します。
参考資料：ServiceNowドキュメント：フォームとUIアクション
ServiceNowラーニング：フォームの操作
ServiceNowドキュメント：レコードの作成と更新