ServiceNowのデフォルトのアプリケーションでは基本的にあまり必須項目は設定されていない。またテーブルの通常の定義ではカラム毎に必須項目を設定する事になる。
つまり最初の保存時に必須項目を設定できる。
ただ実際の使用シチュエーションではステータスに応じて必須項目を設定したいケースがある。
ケースのクローズの承認をエライ人がやる場合に、メンバーが空欄ばかりで承認依頼を出してくる様なケースがあると、起票時は必須でもよいが、クローズ前には最低限すべて埋めて出させるくらいの事はツール側で設定できないのか？という様なわがままな要望が出てくるケースは多い。
偉い人＝発言力もあり要望に応じざるを得ないケースも多い。これを実現するためにはステータスに応じて動的に必須項目を設定することが必要になる。
↓はインシデントのステータスがIn Progressの状態の時の画面。
↓次はResolveボタンを押した状態。
デフォルト設定ではState＝Resolvedになると、もともとの必須項目に加えて、
Description, Resolution code, Resolved, Resolution notesが動的に必須項目となる設定になっている。
これに今回はServiceも追加で必須項目となる様に設定してみる。
設定はUi Policiesを使用する。
フィルタナビゲータからUi Policiesへ。
Newから画面を作成し、
Table＝incident
Short description＝解決時の必須項目設定
When to Apply＝State is Resolved
としてSaveし、UI Policy ActionsのタブでNew
Field name＝Service
Mandatory＝True
とし、Submit
もう一度インシデントのフォームに戻り、
Resolveを押してみる。
意図した通りに、Serviceも必須項目として追加される事が確認できた。
今回、UI Policy Actionsを新規作成したが、カスタマイズとしては、Description, Resolution code, Resolved, Resolution notesを必須項目化しているデフォルトの設定を探し、そちらを編集する事も考えられた。
ただし、デフォルトの設定はServicenowのアップデートにより上書きされる可能性があるため独自の設定として新規作成することとした。設定方法と内容的に競合等も起りにくいと思われるため、この実装で行くことにする。
留意点としてはこれができると成ると、細かなステータス遷移毎に必須項目を細かく制御したくなる誘惑が出てくるが、個人的にはお勧めしかねる。
今回は解決時＝クローズ前という事で、クローズ担当者のチェック負荷を減らす目的でステータスを絞って実装したが、これに対して存在しうるすべてのステータスで厳密に必須・必須ではないといった管理を始めると、途中のプロセスで必須項目を入力しないとチケットのステータスが進められなくなることになる。
余程、よい設計ができれば良いが、そうでないとツールとしての柔軟性を損なう（とりあえずインシデント対応だけやっといてステータス進めて詳細は後で埋める、的な事が出来なくなる可能性あり）ばかりではなく、整合性の維持、項目追加時の検討事項の増大といった事を招くことになるためだ。
それでも問題なく対応できるくらいの潤沢なリソースをServicenowの管理チームにアサインしてもらえれば、やっても良いが、少人数でそこまで踏み込むのは沼にはまる未来しか見えない。
ステータス毎の必須項目制御は可能だが、最小限に抑えることとしたい。
0 件のコメント:
コメントを投稿