servicenow

分野2: Instance Configuration(配点 11%)

1. システムプロパティ(System Properties)

2. ブランディング / テーマ

3. フォーム設定

手段 用途
Form Layout フィールドの追加・削除・並び替え(シンプルなスレート型UI)
Form Design ドラッグ&ドロップのWYSIWYG。セクション・列構成も編集可
ビュー(View) 同じテーブルに複数のフォーム/リストレイアウトを持たせる仕組み。例: 標準ビュー・モバイルビュー・ロール別ビュー

4. リスト設定

5. プラグイン(Plugins)

6. Update Set(更新セット)

構成変更(カスタマイズ)をインスタンス間で移送するための仕組み。CSA頻出。

7. 開発プロセス(インスタンス構成)

8. 多言語・ローカライゼーション

頻出ポイント

全体構造マップ

【インスタンス全体の制御】
  sys_properties (System Properties テーブル)
      │
      ├── セッション・メール・UI動作などを制御
      └── Next Experience テーマ設定 ──→ ロゴ・配色・バナー
              │
              └── Service Portal ブランディング(別管理)

【フォーム・リスト表示の制御】
  テーブル定義 (sys_dictionary)
      │
      ├── Form Layout / Form Design
      │       └── ビュー(View) ──→ ビュールール(View Rules)で自動切替
      │               ├── 標準ビュー
      │               ├── モバイルビュー
      │               └── ロール別ビュー
      │
      └── List Layout
              ├── 管理者設定(全員のデフォルト)
              └── 個人設定(Personal List) ← デフォルトより優先

【機能拡張】
  Plugins (sys_store_app / sys_plugins)
      └── 有効化のみ可(無効化は原則不可)
              └── デモデータ含める/含めない を選択

【環境間の変更管理】
  開発(Dev) ──Update Set作成──→ Complete
                                    │
                          テスト(Test)でRetrieve(取得)
                                    │
                               Preview(プレビュー)
                                    │
                          衝突(Collision)? ──→ Accept / Skip 判断
                                    │
                               Commit(コミット)
                                    │
                          本番(Prod)でも同様に適用

  ※ Update Set テーブル: sys_update_set / sys_update_xml
  ※ 記録対象: 構成レコード(カスタマイズ)のみ
  ※ 非記録: データレコード(incident等)・ダッシュボード・実行結果

【環境コピー】
  本番(Prod) ──Clone──→ テスト(Test) / 開発(Dev)
  ※ 逆方向(下位→本番)のクローンは行わない

【ユーザー個別設定】
  sys_user (ユーザーテーブル)
      └── 言語 / タイムゾーン / 日付書式(I18N プラグイン必要)

PDI 操作ガイド

PDI(Personal Developer Instance)で以下の操作を順番に体験することで、試験で問われる概念を手を動かして確認できる。

タスク1: System Properties を閲覧・変更する

目的: sys_properties テーブルの実態と影響範囲を理解する。

  1. ナビゲーションバーの検索欄に sys_properties.list と入力してEnter。
    • sys_properties テーブルのリストビューが開く。
  2. 検索フィルターで Name に glide.ui.session_timeout と入力して絞り込む。
  3. レコードを開き、Value の値を確認する(デフォルト: 30分相当)。
  4. 変更は保存しない。値の型(文字列/整数)と説明(Description)フィールドがあることを確認する。
  5. 検証ポイント: システムプロパティは「1レコード = 1設定値」であり、テーブル名が sys_properties であることを覚える。

タスク2: Update Set を作成してフォームレイアウトを変更し、移送フローを体験する

目的: Update Set が「構成変更を記録する」仕組みを実感する。

  1. All → System Update Sets → Local Update Sets を開く。
  2. 右上の「New」をクリックし、Name に 練習用UpdateSet_01 と入力して保存。
  3. 保存したレコードを開き、右上の「Make Current」をクリック。
    • 以降の構成変更がこの Update Set に記録される。
  4. All → Incident → Open でインシデントリストを開き、任意のレコードを開く。
  5. フォーム右上の歯車アイコン → 「Form Layout」を選択。
  6. 利用可能フィールドから「Impact(影響度)」を右側(Selected)に追加して保存。
  7. All → System Update Sets → Local Update Sets に戻り、練習用UpdateSet_01 を開く。
  8. 下部の「Customer Updates」関連リストに、先ほどのレイアウト変更レコードが記録されていることを確認する。
  9. State を「Complete」に変更して保存。
    • 検証ポイント: Complete にすると以降この Update Set に変更を追加できなくなる。

タスク3: Form Layout と Form Design の違いを確認する

目的: 二つのフォーム編集手段の違いを視覚的に理解する。

  1. All → Incident → Open からインシデントを開く。
  2. 歯車アイコン → 「Form Layout」を選択。
    • 画面構成: 左右2列のシンプルな選択UI。フィールドの追加・削除・並び替えのみ可能なことを確認。
  3. 同じフォームに戻り、歯車アイコン → 「Form Design」を選択。
    • 画面構成: ドラッグ&ドロップ可能なキャンバスUI。セクションの追加・列数変更が可能なことを確認。
  4. Form Design 上で「Add a section」ボタンを押してセクションを追加し、2列レイアウトに変更してみる。
    • 検証ポイント: Form Layout はシンプルな変更向け、Form Design はレイアウト構造ごと変える場合に使う。

タスク4: ビュー(View)を作成してリストと フォームに適用する

目的: 「ビュー」が同一テーブルに複数のレイアウトを持たせる仕組みであることを体感する。

  1. All → Incident → Open のリストを開く。
  2. リストヘッダー右クリック → 「Configure → List Layout」を選択。
  3. View ドロップダウンに「Default」と表示されている部分を確認する。
  4. 「New」をクリックして新しいビュー名(例: mobile_test)を作成し、表示列を絞り込んで保存。
  5. リストに戻り、URLの末尾に &sysparm_view=mobile_test を追記してEnter。
    • 先ほど設定した列だけが表示されることを確認。
    • 検証ポイント: ビューはURLパラメータや View Rules で切り替え可能。ロール・デバイス・条件ごとに異なるレイアウトを見せる仕組みであることを理解する。

タスク5: プラグインの有効化画面を確認する

目的: プラグインが「有効化のみ・無効化不可」であることと、デモデータオプションの存在を確認する。

  1. All → System Definition → Plugins を開く。
  2. 検索欄に Survey と入力して絞り込む。
  3. 「Surveys and Assessments」プラグインのレコードを開く。
  4. State フィールドが「Active」か「Inactive」かを確認する。Inactive の場合、「Activate/Upgrade」ボタンが表示される。
  5. ボタンをクリックすると「Load demo data?」のダイアログが表示されることを確認する(実際には保存しない)。
    • 検証ポイント: 本番環境ではデモデータを含めないのが原則。また、一度有効化したプラグインに「Deactivate」ボタンが存在しないことを確認する。

試験との接続

以下のパターンは CSA 試験で繰り返し出題される形式である。各パターンに対して、PDI の操作がなぜ理解の助けになるかを示す。

「Update Set に含まれないものはどれか」 → PDI でタスク2を実施し、Customer Updates 関連リストを見ると、インシデントレコード(データ)は一切記録されず、フォームレイアウト変更のみが記録される。この「リストに何が載り何が載らないか」を自分の目で確認することで、「データは含まれない」という原則が丸暗記でなく体験として定着する。

「Update Set をテスト環境に移送する正しい順序はどれか」 → PDI でタスク2の Complete 操作を行い、その後 All → System Update Sets → Retrieved Update Sets から「Retrieve」「Preview」「Commit」の各ボタンが順番にしか押せない UI を確認する。ボタンが段階的にしか有効にならない設計を見ることで、Complete → Retrieve → Preview → Commit の順序が自然に記憶される。

「Form Layout と Form Design の主な違いはどれか」 → PDI でタスク3を実施し、両方の画面を並べて開くと、Form Layout がシンプルなリスト選択型なのに対し、Form Design がキャンバス型でセクション追加・列変更ができることが一目で分かる。「セクションや列構成を変えたい → Form Design」という判断基準が視覚的に刷り込まれる。

「ビュー(View)の目的として正しいものはどれか」 → PDI でタスク4を実施し、同じ Incident テーブルのリストが URL パラメータ1つで全く異なる列構成で表示されることを確認する。「テーブルは1つだが見せ方を複数持てる」という概念が、実際の画面切り替えを通じて直感的に理解できる。

「プラグインの有効化に関して正しい記述はどれか」 → PDI でタスク5を実施し、有効化済みプラグインに無効化ボタンが存在しないことと、有効化時に「デモデータを含めるか」を選択できることを確認する。「有効化は一方通行」「本番ではデモデータを含めない」という2つの原則が、ボタンの有無という具体的な UI の証拠とともに記憶される。