Referenceフィールドが混乱ポイントになりやすい理由
Referenceフィールドは、単なる入力欄ではなく「別テーブルのレコードを指すリンク」です。たとえばインシデントのCallerは、文字列を自由入力しているように見えて、実際はユーザテーブルの1レコードを参照しています。
ここが理解できていないと、次のような違和感が起きます。
- 途中まで入力したのに候補が出ない
- 同じ文字を入れても環境やユーザで候補が変わる
- ルックアップで見えるリストと、入力中に出る候補が一致しない
- 「検索しているつもり」なのに、実は条件が絞られている
- 参照先に読めない権限があると、そもそも候補が出ない
Zurichに上げた後に「Referenceの動きが変わった気がする」と感じる場面は、この仕組みのどこかが表に出てきたケースが多いです。機能が増えたというより、見え方や既定のふるまいが整理され、結果として差分に気づきやすくなった、という捉え方が実務ではしっくり来ます。
CSA学習でも、Referenceは暗記というより「UIで起きていることをデータ構造で説明できる」状態を目指すほうが、応用問題で迷いにくくなります。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Zurich基準で押さえるオートコンプリートの仕組み
Referenceフィールドは、入力中に候補が出ます。これはオートコンプリートで、既定では「入力した文字をもとに参照先テーブルを検索して候補を返す」動きです。
候補が出る前提条件
まず大前提として、参照先テーブルに対して少なくとも読み取り権限がないと候補は出ません。見た目の問題ではなく、セキュリティの仕様です。
「自分だけ候補が出ない」は、まずACLやテーブル権限を疑うのが近道です。
検索がstarts withかcontainsかで体感が変わる
Referenceの入力検索は、体感に直結します。先頭一致で探すのか、部分一致で探すのかで「出る出ない」が変わります。これにはシステムプロパティやユーザ設定が絡むことがあり、環境ごとの差が出やすいポイントです。
実務では、次のように整理すると混乱が減ります。
- 候補が少なすぎる → 先頭一致になっていないか、表示名の設計が適切か
- 候補が多すぎて探せない → 逆に部分一致になっていないか、絞り込みが必要か
- 人によって違う → ユーザ設定やロール差、参照先の読取権限差を確認
参照候補に追加列を出せる
「同姓同名が多い」「グループ名が似ている」などで選べない場合、候補表示に追加列を出す設計が効きます。参照候補の出し方は設定でき、たとえば部門などの補助情報を並べられます。
ここはUX改善にも直結し、運用問い合わせを減らせる鉄板の工夫です。
ルックアップと表示の挙動 ドロップダウン化の罠も含めて整理
Referenceフィールドは、虫眼鏡アイコンなどのルックアップで一覧から探せます。このとき、List v3が有効だとポップオーバー表示になり、無効だと別ウィンドウ表示になる、といったUI差が出ます。
Zurichに上げた後に「別窓じゃなくなった」「戻る操作が変わった」と感じるのは、ここが原因のことがあります。
ドロップダウン表示に見える条件がある
Referenceフィールドは、候補が少ないとドロップダウンのように見える場合があります。これはインスタンス全体の設定値で閾値があり、一定数を超えると通常のReference入力に切り替わります。
つまり「最初は選べたのに、データが増えたら入力型に戻った」は仕様として起こり得ます。
ここは事故の温床になりやすいので、設計では次を意識します。
- データ件数が増える見込みがあるなら、最初から検索前提のUIとして設計する
- どうしても選択式にしたいなら、候補数が安定して少ないテーブルに限定する
- 運用で増えるマスタは、閾値超えを前提に画面説明を用意しておく
表示名の設計で使いやすさが決まる
Referenceは「何を表示値にするか」で選びやすさが変わります。ルックアップのリストレイアウトを調整して、識別に必要な列を出すのは基本の改善策です。
CSA学習でも、表示値と実体が別である点を理解していると、UIの挙動を冷静に説明できます。
フィルタリングの設計 Reference qualifierと既定フィルタの使い分け
Referenceで「候補が出る範囲」を制御する代表がReference qualifierです。モバイルでも、Reference qualifierで返すデータを絞る設計が前提として説明されています。
ここでのコツは、絞り込みの目的を分けることです。
既定フィルタで固定的に絞る
「この関連レコードは常にこの条件で選ばせたい」という固定条件なら、既定フィルタが合います。シンプルで設定も軽い一方、動的要素がないためユーザが条件を変えられない、という性質があります。
たとえば「関連レコードはactiveだけ」など、業務ルールが不変ならこれで十分です。
Reference qualifierで文脈に合わせて絞る
一方で「部門が同じユーザだけ出す」「拠点が一致するグループだけ出す」のように、レコードの文脈で変えたいならReference qualifierが自然です。
ただし、絞り込み条件が重いと体感速度が落ちたり、権限やクエリ制限の影響を受けたりします。運用で「急に候補が出ない」「遅い」が起きたとき、Reference qualifierが絡んでいるケースは多いです。
実務上は、次の順で設計すると安定します。
- 固定で絞れる部分は既定フィルタで先に削る
- 文脈依存だけをReference qualifierで扱う
- 表示列の工夫で、絞りすぎなくても選べる状態を作る
- 参照先の読取権限と組み合わせたときの挙動を確認する
入力ミスと運用事故を防ぐ Dynamic creationと権限の考え方
ZurichのReference挙動で見落としがちなのが「存在しない値を入れたらどうなるか」です。
Dynamic creationは便利だが、設計判断が必要
Referenceフィールドは通常、参照先に存在するレコードしか受け付けません。ですがDynamic creationを有効にすると、存在しない値を入力したときに参照先テーブルへ新規レコードを作成できるようになります。
便利に見えますが、運用事故も増えやすいです。たとえばユーザ名の誤字でユーザが作られてしまう、グループが乱立する、といった類いです。
おすすめの考え方は次です。
- 人が自由入力してよいマスタかどうかを先に決める
- 誤字が致命傷になるマスタでは使わない
- 使うなら、入力者の権限と監査の設計をセットにする
参照先が見えないと候補も出ない
繰り返しになりますが、参照先の読取権限がないと候補が出ないのは仕様です。
そのため「UIの不具合」に見える問題の多くが、実は権限とデータ設計の問題です。
- このロールで参照先テーブルを読めるか
- 参照先のレコードが条件で落ちていないか
- 参照候補の表示列が不足していないか
この三点に分解すると、原因を説明しやすくなります。
CSA学習としての着地
CSA対策としては、Referenceフィールドを「候補が出る入力欄」として暗記するのではなく、
- 参照とは何か
- 候補は何を検索しているか
- 権限がどう影響するか
- フィルタはどこで効くか
を言葉で説明できる状態を目指すのが効率的です。問題の文章が長くても、内部的に起きていることを一段抽象化して捉えられます。
学習を体系化するなら、UdemyのServiceNow入門から管理・開発の基礎まで一気に流れを掴める講座を一本持っておくと、Referenceのような横断テーマを「点」ではなく「線」で理解しやすくなります。演習つきの教材を一例として検討すると、設定と挙動の結びつきが早く腹落ちします。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
ZurichでReferenceフィールドの挙動が「違う」と感じる場面は、突き詰めると次のどれかに分解できます。
- オートコンプリートが参照先テーブルを検索して候補を返している
- 参照先を読めない権限だと候補が出ない
- ルックアップはUI設定によって表示方式が変わる
- 候補数が少ないとドロップダウン風に見えるが、閾値で切り替わる
- 絞り込みは既定フィルタとReference qualifierで性質が違う
- Dynamic creationは便利だが、入力ミスによる運用事故と表裏一体
実務でも試験でも、Referenceは「設定の名前を覚える」より「なぜそう見えるか」を説明できるほうが強いです。
候補が出ない、探せない、選べないといった現象も、参照・検索・権限・フィルタ・表示のどれが原因かを切り分けられるようになると、一気に怖くなくなります。
