メインコンテンツへスキップ
見出し画像

タスク管理モジュールのプロパティ

    ServiceNow観察日記


    「Incidentの担当グループ自動判定と、Problemの担当グループ自動判定は、別々の設定なのでしょうか」。答えは半分だけ正しく、半分は違います。task を継承する63テーブルのうち、Incident・Problem・Change を横断して1件のプロパティで同時に制御されている挙動があります。Australia の PDI をデフォルト設定のまま開き、プロパティ名に task を含む91件を実測し、そのうち何件が本当に複数プロセスへ同時に効くのかを確かめました。

    検証環境：Australia PDI / OOTB / 2026-09-01 確認

    この記事の範囲

    • taskに関わるプロパティが91件あり、どう分類できるか

    • 1件のプロパティが複数プロセスへ同時に効く仕組み

    • Change・Incident・Problemで扱いが異なる複製・連携設定

    • PPM・GRC・CMDBなど、ITSM以外がtaskを使う設定

    • プロパティを変更する前に確認すべき影響範囲の調べ方

    このプロパティで変えられること

    • チェックリスト項目をタスクへ変換するとき、選べるタスク種別

    • CIをリストで関連付けられるタスク種別

    • Change Requestをリストから追加できるタスク種別

    • Problemをクローズしたとき、開いているProblem Taskをキャンセルするか

    • プロジェクト削除時に、配下のproject taskを連鎖削除するか

    プロパティ全体像：91件をグループで見る

    sys_properties のプロパティ名に task という文字列を含むものを検索すると、91件が該当します。


    画像

    91件を役割ごとに分けると、次のようになります。


    画像


    画像

    この検索には1つ注意点があります。ヒットするのは「プロパティ名に task という文字列を含むもの」だけです。glide.ui.incident_activity.fields（Incidentのアクティビティ表示設定）のように、子テーブル名に task の文字が入っていない場合は、taskに関する設定であってもこの検索から漏れます。この記事で扱う91件は、名前に task を含む範囲に限られます（taskを継承する63テーブル全体を網羅した数字ではありません）。

    公式の説明文が付いている

    91件の大半には description（公式の説明文）が入っています。値の意味を推測で決める前に、まずここを読みます。

    全プロセスに同時に効く5件のプロパティ

    91件の中でもっとも影響が大きいのは、値そのものに複数のtask系テーブル名を並べて一括制御するプロパティです。この検索範囲では5件だけが該当します。


    画像

    com.snc.task.principal_class_filter を例に見ます。


    画像

    com.snc.task.principal_class_filterの公式説明を引用します。

    List (Comma separated values) of all the task types where the Principal class filter will be applied on the configuration item (cmdb_ci) field.

    （訳: Principal classフィルタをconfiguration item（cmdb_ci）項目に適用するタスク種別のリスト（カンマ区切り））

    引用元: /sys_properties_list.do?sysparm_query=name=com.snc.task.principal_class_filter

    既定値には incident,incident_task,problem,problem_task,change_request,change_task の6テーブルが並びます。CI選択欄の絞り込みロジックを6つの子テーブルへ個別実装する代わりに、この1件の値に列挙する形で束ねています。


    画像


    画像

    他の4件も同じ形です。それぞれ1件の値が、複数テーブルの挙動をまとめて決めます。

    • glide.ui.create_task_type_option_list：チェックリスト項目をタスクへ変換するUIの選択肢（8テーブル分）

    • com.snc.task.associate_ci：CIをリストで関連付けられるテーブル（3件）

    • com.snc.task.add_change_request：Change Requestを追加できるテーブル（2件）

    • com.snc.task.refresh_impacted_services：影響サービス更新アクションが使えるテーブル（2件）

    もう1件、glide.ui.task.insert は値がテーブル名の列挙ではなく真偽値（既定false）です。ただし公式説明は「task derived tables」と書かれており、対象範囲はtaskを継承する63テーブルすべてに及びます。テーブル名を並べる形と、テーブル名を列挙せず適用範囲を丸ごと指定する形の、2種類の「全体に効く」書き方があることになります。

    この6件を変更するときは、値に並ぶテーブル名の数だけ影響先が増えると考えます。1つのモジュールだけを直そうとして値を書き換えると、意図していない他プロセスの挙動まで変わります。

    Change Task・関連リストの複製に関連するプロパティ

    Change Requestを複製・分岐するとき、関連リストをどこまで引き継ぐかは8件のプロパティで決まります。


    画像

    com.snc.change_request.copy.rl.task_ci.attributes の公式説明を引用します。

    List of attributes (comma-separated) from Affected CIs (task_ci) related list that will be copied from the originating change

    （訳: 元のChangeから複製される、Affected CIs（task_ci）関連リストの項目のリスト（カンマ区切り））

    引用元: /sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.change_request.copy.rl

    同じ構造の設定が、影響サービス（task_cmdb_ci_service）・業務アプリケーション（task_cmdb_ci_business_app）・サービスオファリング（task_service_offering）・Change Task自身の5件で並んでいます。加えて com.snc.change_request.rl.change_task.attach.enable_copy は添付ファイルの複製、com.snc.change_request.standard_change.link_task.valid_fields は標準変更の提案からChange Requestへ戻る参照項目を決めます。

    com.snc.change_management.change_task.enforce_user_on_group_change は一覧表示での担当グループ変更に関わる設定です。

    When true the "Abort changes on group" Business Rules for Change Task will be enforced when changing the Assignment Group in the list view when the assignee in the Assigned To field is not a part of the new Assignment Group.

    （訳: trueのとき、一覧表示で担当グループを変更し、担当者が新しいグループに属さない場合、Change Task向けの「グループ変更を中止する」ビジネスルールが強制される）

    既定はtrueで、担当グループと担当者の不整合を一覧編集の段階で防ぐ設計です。

    Incidentの複製・連携に関連するプロパティ

    Incident側は同じパターンの複製設定が4件あります。


    画像

    com.snc.incident.incident_task.closure は既定trueで、Incidentがクローズまたは取り消しになったとき、開いているIncident Taskを自動で閉じます。作業タスクの閉じ忘れを防ぐ設定です。

    com.snc.incident.link_to_task.problem の値は problem_id で、公式説明はこうです。

    This is for getting 'Add' ui action functionality of incidents related list on problem.

    （訳: Problem上のIncident関連リストで「追加」UIアクションの機能を得るためのもの）

    Problemの画面からIncidentを関連付ける操作は、この項目名の指定によって成立しています。

    Change向けは8件、Incident向けは6件でした。Problem向けの同種プロパティ（名前が com.snc.problem.copy.rl から始まるもの）は、この検索範囲に1件もありません。関連リストの複製という機能パターンは、Change・Incidentには用意されていて、Problemには用意されていないことになります。Problemで同じ複製を実現したい場合、OOTBのプロパティに頼らず、個別のビジネスルールを書く判断が必要です。

    Problem・Problem Taskのクローズ制御に関連するプロパティ

    Problem側が持つのは、クローズ時の制御に関わる4件のプロパティです（Change側のような複製の仕組みではありません）。


    画像

    problem.closed.cancel_open_tasks は既定trueで、Problemをクローズするとき開いているProblem Taskをキャンセルします。problem.closed.can_create_tasks は既定falseで、クローズ済みのProblem上でProblem Taskを新規作成できません。

    problem_task.closed.role.reaassess_from_closed の値は problem_coordinator です。

    Who can Re-assess a Completed or Canceled Problem Task?

    （訳: 完了またはキャンセルされたProblem Taskを誰が再評価できるか）

    完了・キャンセル済みのタスクを差し戻せる担当者を、特定のロールに絞る設計です。誰でも過去のタスクを蒸し返せる状態を避けています。

    SLAエンジンの内部制御に関連するプロパティ

    SLA関連は5件あります。


    画像


    画像

    com.snc.sla.get_task_from_db の公式説明を引用します。

    When processing SLAs any of the Task tables specified in this property, the "current" GlideRecord object will not be used. Instead, the record will be fetched from the database.

    （訳: このプロパティで指定されたTaskテーブルのSLA処理時は、"current" GlideRecordオブジェクトを使わず、レコードをデータベースから取得し直す）

    既定値は sc_req_item 1件だけです。残る4件はログレベルとタイマー計測の有効・無効という技術的な値で、SLAの目標時間そのものを表す値は5件のうち1件もありません。目標時間や優先度マトリクスといった具体的な設定は contract_sla 側が持ちます。

    アクティビティ表示フォーマッタに関連するプロパティ

    フォーム下部の履歴欄（アクティビティ）に何を表示するかも、プロパティで決まります。ただしこの検索範囲でヒットするのは5件だけです。


    画像

    対象は cert_follow_on_task・kb_feedback_task・samp_asset_reclaim_task・sn_creatorstudio_new_application_task・sn_vsc_security_task の5テーブルです。いずれもテーブル名に task の文字を含んでいます。

    task自身のアクティビティ設定（glide.ui.task_activity.fields）は0件です。Incident・Problem・Change Requestにも同種のプロパティ（glide.ui.incident_activity.fields 等）が存在しますが、テーブル名に task を含まないためこの検索には出てきません。アクティビティ表示は子テーブルの数だけ個別に定義される仕組みで、taskレベルでの一括設定は用意されていません。

    PPM（プロジェクト管理）に関連するプロパティ

    91件の中で最も件数が多いのはPPM（Project Portfolio Management）関連の10件です。ITSMコアの3プロセスに共通で効く5件よりも、単独のモジュールが持つプロパティ数の方が多いことになります。


    画像


    画像

    com.snc.project_task_cascade_delete の公式説明を引用します。

    When set to true, while deleting a project, project tasks will be deleted with set cascade delete as true

    （訳: trueに設定すると、プロジェクトを削除するとき、project taskも連鎖削除として削除される）

    既定はtrueです。プロジェクトを消しても配下のタスクだけ残る、という孤立レコードを防ぐ設計になっています。

    com.snc.status_process_planned_task_entities は値に pm_project_task,tsp1_project_task,tsp2_project_task,tsp3_project_task,tsp4_project_task,tsp5_project_task,sn_wp_work_plan_task,customer_project_task の8テーブルが並びます。終了日が変わったときにステータスを再計算する対象です。この5件の全プロセス共通スイッチと同じ「1件の値が複数テーブルへ効く」構造を持ちますが、対象はいずれもPPM内部のplanned_task系に閉じています。ITSMコア3プロセスを横断する5件とは、影響範囲の広さが別物です。

    GRCに関連するプロパティ

    GRC（ガバナンス・リスク・コンプライアンス）関連は8件です。監査のFollow On TaskとIndicator Taskの督促に関わる設定が中心です。


    画像


    画像

    督促に関わる4件を並べると、周期が見えてきます。

    • sn_grc.indicator_task_reminder_timer（値5）：期日の5日前にリマインド

    • sn_grc.indicator_task_daily_reminder（値false）：リマインドは1回のみで、毎日は繰り返さない

    • sn_grc.indicator_task_overdue_reminder_timer（値1）：期日超過の1日後に督促

    • sn_grc.indicator_task_overdue_daily_reminder（値false）：督促も1回のみ

    「期日前に1回・期日超過後に1回」という控えめな通知設計です。督促メールを毎日送る運用にしたい場合は、この2つの daily_reminder を有効にします。

    sn_grc.automatically_close_issue_when_all_tasks_closed は既定trueで、関連する是正タスクが全て閉じるとIssueも自動で閉じます。

    CMDB Data Managementに関連するプロパティ

    CMDBのデータ品質管理（Data Management）に関わるプロパティが5件あります。


    画像

    glide.cmdb.health.autoCloseAuditTasks の公式説明を引用します。

    When true, closes all audit tasks associated with cmdb_health_result record when the record is no more valid gets deleted.

    （訳: trueのとき、cmdb_health_resultレコードが無効になって削除された際、関連する監査タスクを全て閉じる）

    既定はfalseで、この自動クローズは無効です。CI健全性チェックの結果が消えても、紐づく監査タスクは残ったままになります。

    cmdb.data.manager.stale.task.life.in.days（既定90）と sn_cmdb_ws.glide.cmdb.data.manager.aging.policy.task.timeframe（既定30）はどちらもタスクを「古い」とみなす日数を扱いますが、名前が異なる別々のプロパティです。似た役割の設定が2件に分かれている点は、値を変更するときに両方を確認しないと片方だけ古い基準のまま残る原因になります。

    個別アプリ連携に関連するプロパティ

    残る34件は、15の機能に分かれて存在します。


    画像

    代表的なものを挙げます。

    • Predictive Intelligence（機械学習）: 学習に使う添付ファイルの最大サイズ・件数・対応形式を6件で制御

    • ナレッジ管理連携: 記事に紐づく最近のタスクを何件・どう表示するかを3件で制御

    • Visual Task Board: ボードのメンバー・オーナーの既定値を2件で制御

    • サービスカタログ: 注文確認画面でのタスク表示と、カタログタスクの承認エンジンを2件で制御

    • Security Center: 自動セキュリティタスクの有効化としきい値を2件で制御

    glide.platform_ml_task.supported_attachment_types の値は PDF,XLS,XLSX,DOCX,CSV,EML,TXT でした。機械学習の学習データとして読み込める添付ファイルの形式を絞り込む設定です。

    プロパティを変更する前に確認すること

    91件のうち、実際に触る可能性が高いものほど、影響範囲の見誤りが起きやすい構造になっています。


    画像

    確認する手順を図にします。


    画像

    1. 値に並ぶテーブル名を全部読む：カンマ区切りの1つ1つが影響先です

    2. 各テーブルでの現在の挙動を確認する：値を変える前に、今どう動いているかを押さえます

    3. 複数テーブルにまたがる場合は関係者に共有する：自分のモジュールだけの変更のつもりが、他プロセスにも及びます

    4. 公式説明を読む：推測で値を変えません

    5. 更新セットに変更を残す：誰が・いつ・なぜ変えたかを記録します

    実機で気づいたこと

    nameLIKEtaskで拾えるのは、テーブル名にtaskを含む設定だけ

    glide.ui.cert_follow_on_task_activity.fields はヒットしましたが、glide.ui.incident_activity.fields や glide.ui.problem_activity.fields はヒットしませんでした。テーブル名に task という文字列を含むかどうかで、検索結果が分かれます。

    nameLIKEtask はプロパティ名の文字列一致にとどまり、taskを継承しているかどうかの判定には使えません。子テーブル名がincidentやproblemのように task の文字を含まない場合、taskに関する設定でも検索から漏れます。

    taskを継承する63テーブル全体の設定を網羅したいときは、この検索だけに頼らず、子テーブル名ごとに個別で検索する必要があります。この記事の91件は「プロパティ名にtaskの文字列を含む範囲」に限られます（taskを継承する全テーブルの設定を網羅したものではありません）。

    1つの値が、複数プロセスの挙動を同時に決めている

    com.snc.task.principal_class_filter はたった1つのプロパティ値で、incident・problem・change_requestを含む6テーブルのCIフィルタ挙動を同時に決めていました。

    同じ処理を6つのテーブルに個別実装せず、1件の値へ集約する設計です。修正の手間は小さくなりますが、値を書き換えたときの影響先も同時に6箇所へ広がります。

    複数プロセスに影響するプロパティを触るときは、変更後に1テーブルだけ確認して終わらせず、値に並ぶテーブルの数だけ動作を確かめます。

    Change向けの複製設定はIncidentより多く、Problemには無い

    関連リストの複製設定はChangeが8件、Incidentが6件でした。Problem向けの同種プロパティは、この検索範囲に1件も見つかりませんでした。

    同じ「複製」という機能でも、モジュールごとに用意されている範囲が違います。ChangeとIncidentには複製の挙動をプロパティで調整する余地がありますが、Problemには最初からその余地自体がありません。

    Problemで関連リストの複製を実現したい場合、既存プロパティの値を探しても見つかりません。個別のビジネスルールを新規に用意する前提で設計します。

    SLA関連の5件は、目標時間を1つも持たない

    SLAエンジンの内部制御5件は、ログレベルとタイマーの有効・無効という技術的な値だけでした。応答時間や解決時間を表す値は、この5件のどこにもありません。

    taskレベルのSLAプロパティは、SLA計算の仕組みを動かすための技術スイッチに徹していて、目標時間という業務上の値は持っていません。目標時間は contract_sla（SLA Definition）側の役割です。

    SLAの応答目標を調べるときにtask関連のプロパティを探しても見つかりません。最初から contract_sla を開きます。

    実務で順番に検討する箇所

    taskレベルのプロパティを扱うとき、確認する順序を決めておくと迷いません。

    1. 影響範囲の広さを見極める：値に複数テーブル名が並ぶ5件は、変更前に全対象を洗い出す

    2. 複製・連携の設定差を把握する：Change・Incidentにはあり、Problemには無い設定がある

    3. クローズ制御の既定値を確認する：Problem/Problem Taskは4件で親子の連動を決めている

    4. SLAは目標時間を探さない：taskレベルは技術スイッチのみで、目標時間は別テーブル

    5. アクティビティ表示は子テーブルごとに探す：taskレベルの一括設定は存在しない

    6. PPM・GRC・CMDBは別モジュールとして扱う：taskの共通基盤とは独立した設定群

    7. 変更前に公式説明を読む：91件の多くに説明文が付いている

    8. 更新セットで変更履歴を残す：後任者が原因を追える状態にする

    用語

    • OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

    • PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス

    • システムプロパティ：sys_properties。インスタンス全体の設定値を保持するテーブル

    • PPM：Project Portfolio Management。プロジェクト・需要・資源を管理する機能群

    • GRC：Governance, Risk and Compliance。統制・リスク・コンプライアンスを管理する機能群

    検証範囲とおことわり

    • 検証環境：Australia PDI / OOTB / 2026-09-01 確認

    • 件数と既定値はすべて OOTB の状態です。本番環境やカスタマイズ済み環境では異なります

    • 91件は sys_properties の名前に task を含むものに限られ、taskを継承する63テーブル全体の設定を網羅したものではありません

    • 各プロパティを実際に変更して挙動が変わることは確認していません

    • SLAの目標時間・割り当てルールなど具体的な設定値は、taskレベルではいずれも0件です（本シリーズ第1巻「タスク管理モジュールの概要」で確認済み）。各業務プロセスの個別設定はIncident・Problem・Change等の各シリーズで扱います

    • 各プロパティを読んでいるスクリプトの実装は、本シリーズ第5巻「タスク管理モジュールの自動設定構成」で扱います

    付録：自分の環境で確認するときのURL

    • task関連のプロパティ全体：/sys_properties_list.do?sysparm_query=nameLIKEtask

    • 全プロセス共通スイッチ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.task.

    • Change向けの複製設定：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.change_

    • Incident向けの複製設定：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.incident.

    • Problem/Problem Taskのクローズ制御：/sys_properties_list.do?sysparm_query=nameSTARTSWITHproblem

    • SLAエンジンの内部制御：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.sla.task

    • PPM関連：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.project

    • GRC関連：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_grc

    引用した公式説明を実機で確認する方法

    この記事で引用した説明文は、ServiceNowが製品に同梱しているプロパティの説明です。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

    • プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEtask^descriptionISNOTEMPTY

    関連記事

     
     

    ServiceNow観察日記

     
     
    ServiceNowのPDI（Personal Developer Instance）を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ