変更管理モジュールの自動設定構成

Change Requestを1件保存すると、必須項目のチェック・状態遷移・承認依頼まで、裏では多数の処理が一斉に動きます。しかもその大半はデータポリシーではなくビジネスルールが担っており、データポリシーはわずか1件だけでした。Australia の PDI をデフォルト設定のまま開き、change_request に紐づく81件のビジネスルールを確かめました。必須化・承認・リスク計算・コンフリクト検知の自動化がどう組まれているか、自社で処理を足すならどこに置くべきかも合わせて整理します。

調べる順序

• ビジネスルール81件が、いつ・どんな処理を担い、自社で追加するならどこに置くべきか

• データポリシーがなぜ1件しかないか、代わりに何が必須化を担うか

• クライアントスクリプト・UIポリシー・UIアクションの役割分担

• 承認とCABがどう自動生成されるか

• リスクとコンフリクトがどう計算・検知されるか

要点

• ビジネスルールは81件が有効で、beforeが47件と半数を超える。task共通のビジネスルール（別枠で33件）も保存のたびに重なる

• データポリシーは1件のみ。必須化と読み取り専用化はorder900台のビジネスルール8件が担う

• UIアクションの状態遷移ボタンは、Change Modelが決める「次の遷移先」を条件にstateの1項目だけを設定する

• 承認はtype別に用意されたFlow Designerの14件のフローが担い、sysapproval_approverを732件生成する

• リスクの自動計算は既定では保存時に動かない。risk_conditions4件はCalculate Riskボタンを押した時だけ評価される

変更管理の自動化を支える仕組みの全体像

change_requestに紐づく自動化の全体を、まず件数で見ます。change_requestにはビジネスルール81件（非アクティブ2件）・クライアントスクリプト39件・UIポリシー9件・UIアクション28件・通知16件が有効です。対してデータポリシーはわずか1件でした。差は歴然です。Problem管理（25件・8件）と比べると、ビジネスルールの数は3倍を超える一方、データポリシーは8分の1です。

ブラウザ側のクライアントスクリプトとUIポリシーで入力を整え、ACLで権限を確認します。そのあとビジネスルール（before）が、Change Modelの適用や900番台の必須化ゲートを担当する仕組みです。保存が終わると、ビジネスルール（after）がChange Taskの生成とCAB同期、通知イベントの発行を行います。続けてFlow Designerが承認を進め、最後に通知が送られる流れです。

この棚卸しは、自社で必須化やチェックを追加する前に既存のBRやUIポリシーとの重複を把握するために行います。あわせて、メジャーアップグレードのたびの増減を確認する基準値にもなります。集計対象はactive=trueのみです。change_requestには非アクティブなBRが2件あり、1件は2009年更新の旧承認エンジンの残骸、もう1件は2018年更新の「Insert Change Phases」でした。無効化されたBRは削除されずに残るため、アップグレード監査ではこの切り替わりも確認します。

この81件はcollection=change_requestに限った数です。change_requestはtaskを継承するため、collection=taskの共通ビジネスルール（有効33件）も保存のたびに重なります。クローズ判定を担うTaskStateUtil.runMarkClosed()は、コードの中でincidentとproblemだけを名指しして除外しています。change_requestは対象のままです。詳細は姉妹シリーズ「タスク管理モジュールの自動設定構成」の内容です。アップグレード後に棚卸しをやり直す場合は、末尾のURLと同じクエリを再実行します。差分がServiceNow提供の変更か自社カスタマイズかは、sys_package（アプリケーションスコープ）で見分けます。

以下では、81件のビジネスルールのうち代表的なものをorder順に確かめたうえで、データポリシーが1件しかない理由と、承認・リスク・コンフリクトの自動化を順番に確かめます。

ビジネスルールが動くタイミング

ビジネスルールは、実行されるタイミングでwhenごとに分かれます。change_requestの81件を集計すると、beforeが47件・afterが22件・display（before_display）が11件・asyncが1件でした。

before（47件）は、データベースへ書き込む前に値を補正したり保存を中断したりする役割で、Change Modelの適用や900番台の必須化ゲートもここに集まります。after（22件）は書き込みが終わってから動き、Change Taskの生成やCAB同期、通知イベントの発行を担当します。display（11件）はフォームを画面に出す前に実行され、g_scratchpadを通じてクライアント側のスクリプトへ値を渡す役目です。asyncは1件のみです。承認結果を外部のCI関連ワークフローへ知らせる処理でした。

• 参考：ServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認 … 同じ切り口をincidentで行った回です

主要なビジネスルールの処理内容

81件のうち、動きが分かりやすい代表をorder順に見ます。分類は状態遷移制御／入力強制／自動計算／コンフリクト検知／CAB同期／Change Task連携／通知イベント生成の7種に分かれます。

採番とテンプレートの保護

insert_change（before, order100）は採番だけを行うルールで、number.nil()のときに次の番号を発行し、addInfoMessageで通知します。Abort insert for inactive Std Change（before, order9）は、非アクティブな標準変更テンプレートから新規作成しようとした保存を中断する処理でした。

Change Modelが状態を管理する

Change Requestのtypeを決めると、複数のビジネスルールが連動してChange Modelを適用する仕組みです。まず、Set Normal Model in WorkspaceとSet Emergency Model in Workspace（ともにbefore_display, order40）が動きます。新規作成時、typeへ応じたChange Modelを画面表示前に自動セットする処理です。続くChange Model: Populate scratchpad（before_display, order50）は、状態フィールド名や初期状態などを詰め込みます。この値はg_scratchpad.change_modelに置かれ、クライアント側のスクリプト群が参照する土台になります。

Change Model: Apply Initial State（before, order50）は、Change Modelを変更したのにstateが追随していない場合、初期状態へ強制的に戻します。次のChange Model: Check State Transition（before, order100）は、Change Modelが許可しない状態遷移を拒否します。stateフィールドを直接書き換えても、この2件が許可しない遷移は保存できません。

• 参考：State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … 状態遷移の基盤はここで扱っています

Change Taskを自動生成し進行させる

Create Standard Change Tasks（after, order100）は、標準変更のChange Taskを一括生成します。Start Change Tasks（after, order100）は、承認が承認済みに変わり、delivery_plan（実装計画）が設定されている場合に、そのタスク群を起動します。

current.approval.changesTo('approved') && !current.delivery_plan.nil()

承認が下りた瞬間、実装計画に沿ったタスクが自動で起動します。この自動生成によって、担当者は実装タスクを1件ずつ手作業で作る手間から解放されます。Cancel change_tasks（after, order100）は、Changeがキャンセルへ変わったとき、紐づくChange Taskもまとめてキャンセルします。

CABの決定を承認へ反映する

Sync approval with agenda item（after, order100）は、CABの承認・却下の決定をsysapproval_approverへ書き戻す処理です。sn_change_cab.CABChangeRequestが持つ2つのメソッドを呼ぶだけの、薄いラッパーでした。Update CAB attendees（after, order100）は、CAB議題の出席者リストを更新します。Sync "cab_date" and "cab_date_time"（before, order950）は、日付だけのcab_dateと日時付きのcab_date_timeを同期する処理です。どちらかが変わると、もう一方へ値をコピーします。

状態変化を通知イベントへ変換する

change events（after, order100）は、change_requestの作成・更新やassigned_to・priority・riskの変化を検知するBRです。change.assigned等のイベントを発行します。DBへの書き込みは行わず、gs.eventQueue()でイベントキューへ積むだけの処理でした。通知（sysevent_email_action）16件の多くは、このイベントを受けて動きます。state変更用のイベントも同じBRから発行されます。ただしプロパティcom.snc.change_request.event.state_updated.enabledが既定falseのため、実際には発行されません。自社通知を追加するなら、このプロパティをtrueにするか、別の新規BRでgs.eventQueue()を呼びます。

対象条件・更新項目・中断の有無・呼び出すScript Include・変更可否は代表11件を下表にまとめました。

薄いラッパー系のBR（Sync approval with agenda item等）はScript Includeを1〜2行で呼ぶだけです。自社で処理を足す場合もBR本体は書き換えず、同じorder帯に新しいBRを並べます。Change Model中核のBR（Apply Initial State等）は状態機械の心臓部にあたります。調整はChange Model側の設定（sttrm_state）で行い、BR自体には手を入れないほうが安全です。

データポリシーが1件しかない理由

change_requestのData Policy（sys_data_policy2）は1件だけです。

中身は、Change Modelを適用した後にchg_modelとchg_model_templateを読み取り専用にする設定で、enforce_uiに加えインポートセットとSOAPにも適用されます。Problem管理はData Policyが8件あり必須化の主役でしたが、Changeでは逆にその役割をorder900台のビジネスルール8件が担っています。

この8件は画面操作に加え、複数の経路に及びます。プロパティcom.snc.change_management.enforce_data_requirementsの公式説明には、UIポリシーによる画面制御を他の経路にも及ぼす、と書かれています。具体的には「Flow・Workflow・REST/SOAP API・JavaScript経由の更新にも同一の制約として強制する」というものでした。Business Ruleは経路を問わず必ず動くため、画面限定になりがちなData Policyより広い範囲を一括で守れます。8件にロール判定はありません。管理者やitil_adminでも、プロパティがtrueの間はゲートを通過できません。無効化はBR単位ではなく、プロパティ側の一括スイッチで行います。

中断の有無は項目ごとに違います。Mandatory Assignment Group等5件はsetAbortAction(true)で保存全体を止めます。Mandatory Closure Informationだけは挙動が割れていました。close_notesが空、またはclose_codeが選択肢定義外の値のときだけ中断します。close_code自体が空でも、エラーメッセージが出るだけで保存は完了する仕様です。クローズ操作の相談では、close_codeが空でも保存できる前提でclose_notesの入力有無を先に確認します。利用者がエラーに遭ったときは、フォーム上部の英語メッセージの主語（Assignment group・Stateなど）がそのまま直す箇所の手がかりになります。

Data Policyが少ない理由は、画面外からの一括更新にも同じ判定を効かせたいためだと考えられます。Business Ruleならスクリプトで複雑な条件（stateの遷移前後や直前の状態）を書けますが、Data Policyは条件式1本と対象フィールドの指定だけです。900番台に集まる8件のような、直前の状態を見て判定する処理は、Data Policyの表現力を超えていた可能性があります。

• 参考：APIやインポートにも効く必須制御（Data Policy） … 画面外からの投入はここで止まる

クライアントスクリプトとUIポリシーの役割

change_requestのクライアントスクリプトは39件有効で、onChangeが23件、onLoadが13件、onSubmitが3件でした。

名前を見ると、Change Model関連が最多のテーマです。「Change Model: read only state Approval」「Change model: Mandatory Fields」などが該当します。いずれもChange Modelが画面の表示条件を切り替える処理です。他にも「Change Model: Refresh Model on RW Update」のように、モデル変更時に表示を更新するものがあります。

UIポリシーは9件、UIポリシーアクションは17件でした。代表は「Change Model: Cloud Infrastructure mandatory fields」です。end_date・cmdb_ci・short_description・start_dateの4項目を一括でmandatory化します。もう1件は「Show - CAB fields for Normal/Emergency change」です。cab_required・cab_date_time・cab_delegate・cab_recommendationを表示状態にします。

UIアクションの処理内容

フォーム上のボタンは28件が有効です。

状態遷移ボタン（Request Approval系・Implement・Review・Schedule・Close・Cancel Change）は7種です。いずれもScript Include ChangeFormUISNCのisXxxAvailable()という統一パターンで表示条件を判定します。中心は「Change Modelが定義する次の手動遷移先と一致するか」であり、固定のstate値ではありません。同じChangeでもChange Modelが変われば、表示されるボタンの組み合わせも変わります。

Close・Cancel Change・Implementの3つを見ると、共通の型があります。

g_form.setValue("state", "3");
gsftSubmit(null, g_form.getFormElement(), "state_model_move_to_closed");

stateへ値をセットしてgsftSubmitでサーバへ送るだけです。Incidentの Resolve ボタンは、incident_stateとstateの2項目を明示的に設定していました。Changeにはincident_stateに相当する二重の状態項目がありません。state1項目だけで足りるため、同期の手間そのものが発生しない設計です。

Request Approval(CAB)だけは、on_hold以外にもう1つ条件を持ちます。承認状態がnot requestedかrejectedのときしか表示されません。却下（rejected）後は再表示されます。同じボタンから再度承認を申請できます。承認済み・申請中のChangeでボタンが消えるのは、二重申請を防ぐ設計です。

Calculate Riskボタンはサーバ側で実行される処理です。条件はitil,sn_change_writeロールと、RiskCalculator().showCalculateRisk(current)の2つです。押すとRiskCalculatorを呼び直し、リスクを再評価します。Edit Risk Conditionsはitil_admin限定で、risk_conditionsの編集画面を開く仕組みです。リスクの再計算は誰でもできます。判定基準を変える操作は管理者に絞られています。

• 参考：ServiceNowのResolveボタンはどこで動く？ UI Actionの表示条件とClient/Server処理 … Incidentの同じ場面と見比べられます

承認はどう自動生成されるか

change_requestの承認は、typeによって使うFlowが変わります。

nameLIKEChangeで有効なFlowを確認すると、type=flowが14件でした。normal・standard・emergencyはそれぞれ3本のAuthorize系フローを持ちます。unauthorized（emergency型にunauthorized=trueを重ねた種別）は2本、Cloud Infrastructureは1本です。トリガーは共通でした。change_requestの作成・更新（record_create_or_update）です。

承認の実処理はsysapproval_approverに記録されます。sysapproval.sys_class_name=change_requestで集計すると、732件でした。内訳はrequested376・not_required290・approved66・rejected0です。承認が完了しapproval項目がapprovedへ変化するタイミングは、Business Rule「Start Change Tasks」がタスクを起動する条件と同じです。Flow側がこの項目を更新していると分かります。Flow自体の内部ステップ（アクション・条件分岐）までは未確認のため、承認生成の詳細な発火条件は推測にとどめます。

承認エンジンのプロパティglide.approval_engine.change_requestはoffです。公式の説明は次のとおりでした。

（訳：承認をWorkflowで管理する場合はoffに設定する）

このPDIの承認は、旧来のApproval RulesエンジンではなくFlow Designerで管理されている状態です。CABが関わるnormal・emergencyでは、Sync approval with agenda itemがCABの決定をsysapproval_approverへ反映します。この処理でcab_agenda_item 60件との同期が保たれる仕組みです。Flowが途中で止まって承認が進まない場合、sys_flow_context（実行記録）で該当のChangeを検索すると、どのアクションで待機・失敗しているかを確認できます。

CAB自体の実体も確認すると、cab_meetingは6件で全件がPendingでした。出席者を管理するcab_attendeeは18件です。

Pendingのまま6件が並ぶのは、デモデータの会議がどれも実施済みになっていないためです。本番導入では、少なくとも1回Meetingを完了させて出席者の記録が残ることを確認してから運用に載せます。

• 参考：Flow Designerの中身は3テーブル（sys_hub_flow） … Flowを構成するテーブルの基本

• 参考：Flow Designerのフローが動かないときどこを見る？ 実行記録sys_flow_contextで切り分ける … エラー時の確認場所の実測手順

• 参考：承認は1人1レコード（sysapproval_approver） … 承認レコードの構造

• 参考：CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CABの画面構成

リスクを自動計算する仕組み

リスクの自動計算は、Business Rule「Calculate Risk」（before, order100）が入口です。ただし既定では保存のたびには動きません。

Calculate Riskが動く条件は次の3つです。

• gs.hasRole('itil,sn_change_write')であること

• プロパティglide.ui.risk_calculate_ruleが"business_rule"であること

• RiskCalculator(current).showRiskAssessment()がfalseであること

既定値を確認します。このPDIのglide.ui.risk_calculate_ruleは既定値の"ui_action"でした。公式の説明は次のとおりです。

（訳：オンデマンドでリスクを計算するにはUI Actionを使うのが推奨される標準の挙動）

つまり保存するだけではrisk_conditionsは評価されません。実際に動くのは、フォームのCalculate Riskボタンを押した瞬間か、プロパティをbusiness_ruleへ切り替えて以降の保存です。第7巻「変更管理モジュールのトラブル事例と解決」の「保存してもriskが変わらない」症状も、この既定値が原因でした。

スクリプト冒頭のコメントには次のようにありました。

（訳：このBusiness RuleはRisk Conditionsのみに対応する。Risk Assessmentプラグインが有効な場合は無効化される）

risk_conditionsは4件です。全件がactiveでした。

先頭2件（Insufficient lead time・Critical service changed）は、開始日や対象サービスの重要度からrisk=Highと判定します。3件目のCritical service affectedも同様にrisk=Highです。4件目のNo expected risk issues foundは既定値です。どの条件にも一致しない場合、risk=Low・impact=3-Lowになります。判定結果はHighかLowのみで、Moderateを生成する行は1件もありません。プロパティcom.snc.change_management.risk_conditions.match_allがtrueのため、複数条件に一致した場合は最もリスクの高い方が採用されます。match_allをfalseにすると、order順で最初に一致した条件が採用される方式となる仕組みです。この場合、orderの並び順そのものが優先順位になります。

risk項目は、UIポリシー等で読み取り専用にされていない限り、change_requestの標準write権限を持つ担当者ならフォームから直接上書きできます。判定基準（risk_conditionsの内容）を変える操作だけがitil_admin限定のEdit Risk Conditionsに絞られています。

実機のデモデータではrisk=Moderateが106件中59件と過半数でしたが、risk_conditionsからは生成されない値でした。riskフィールドの辞書にも既定値はなく、Moderateは自動計算ではなく個別に入力された値だと分かります。自動判定でModerateを出す場合は、risk_conditionsへ「risk=Moderate」を返す行を新設します。

名前が似たdl_risk_valueというテーブルもあります。これはPPM（プロジェクト管理）用のリスクLookupで、Change管理とは無関係でした。Changeのリスク計算はrisk_conditionsとRiskCalculatorだけで完結します。質問票方式のRisk AssessmentプラグインはInactiveのため、本PDIでは条件ベースの計算だけが有効です。自社でリスク基準を追加するなら、risk_conditionsへ行を足す方法と、プラグインを有効化して質問票方式へ切り替える方法の2通りがあります。

コンフリクトを検知する仕組み

コンフリクト検知は、保存のたびに動く3つのビジネスルールと、Flow「Change - Conflict Detection」で構成されます。

Cancel Conflict Detection（before, order99）は、実行中のコンフリクトチェックがあれば中断する処理です。Clear Conflicts（before, order100）は、コンフリクト検知の対象外になった場合、過去に作られたconflictレコードを削除します。Update Conflicts（after, order100）は、ChangeConflictExecution(current, gs).scheduleConflictDetection()を呼ぶだけの1行でした。実処理は、Flow側に委ねられています。

conflictテーブルは構造が実在します。change・conflicting_change・configuration_item・impacted_service・scheduleなどのフィールドを持ちますが、デモデータは0件でした。

プロパティを見ると、同一CI・ブラックアウトウィンドウ・メンテナンス窓・関連サービスの4種は既定でtrueです。change.conflict.assigned_to（同一担当者への重複割当チェック）は既定falseでした。コンフリクト検知は「モノ（CI）」基準が中心です。「ヒト（担当者）」基準は自分で有効化しない限り動きません。

1回の保存で処理が動く順序

ここまでの仕組みが、保存ボタンを1回押したときにどう重なるかを整理します。

1. クライアントスクリプトとUIポリシー：ブラウザ側で入力を制御する

2. ACL：書き込む権限があるかを判定する

3. ビジネスルール（before）：Change Modelを適用し、900番台のゲートで必須項目を確認する（リスク計算は既定では含まれません）

4. データベースへ書き込み

5. ビジネスルール（after）：Change Taskを生成し、CABと同期し、コンフリクト検知を予約し、通知イベントを発行する

6. Flow Designer：typeに応じた承認フローを進める

7. 通知：状態の変化やコメントをメールで知らせる

データポリシーが1件しかない理由は、この順序を見ると分かります。3の900番台が担う必須化は、本来Data Policyがやる仕事です。Changeではその役割を丸ごとビジネスルールへ寄せています。リスク計算だけは別枠で、Calculate Riskボタンを押した時点で改めて3と同じbeforeのタイミングを踏み、risk・impactだけを更新する独立したトランザクションになります。

実機で気づいたこと

Change Modelを外れた状態は初期状態へ戻される

Change Model: Apply Initial Stateのスクリプトを読むと、Change Modelを変更したのにstateが追随していない場合、初期状態へ強制的に戻す実装でした。

最初は、Change Modelを切り替えたら現在のstateを維持したまま新しいモデルの遷移ルールへ乗り換えるものだと考えていました。実際には、遷移可能な状態でなければ問答無用で初期状態（多くはNew）へ戻されます。Change Modelを後から切り替える運用を設計するときは、進行中の変更が初期状態へ巻き戻る前提で手順を組む必要があります。

薄いラッパーのビジネスルールが多い

Update Conflicts・Sync approval with agenda itemを実測すると、どちらも1〜2行でScript Includeを呼ぶだけの短いスクリプトでした。

名前だけを見ると重い処理を想像しますが、実処理はChangeConflictExecutionやCABChangeRequestといったScript Include側に置かれている構成でした。Changeの自動化は、Business Ruleを呼び出しの入口として使い、実際のロジックをScript Includeへ集約する設計が目立ちます。自社で処理を追加するときも、Business Ruleへ直接書き込むより、Script Includeへ切り出す方が既存の設計と揃う形です。

状態遷移ボタンはstate1項目だけを更新する

Close・Implement・Cancel Changeのスクリプトを実測すると、いずれもstateへ値をセットしてgsftSubmitするだけでした。

Incidentの Resolve ボタンはincident_stateとstateの2項目を明示的に設定していましたが、Changeにはincident_stateに相当する項目がありません。テーブル構造の違いが、ボタンの実装のシンプルさに直結しています。自社でChangeの状態を操作するスクリプトを書くときは、state1項目だけを気にすればよく、Incident側で必要だった同期の考慮は不要です。

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

自動処理を調整するとき、次の順序で確認します。判断軸は「画面だけの制御でよいか／APIやFlow経由も含めて強制したいか／保存自体を中断させる必要があるか」の3つです。

1. Change Modelの適用順序：order40〜100のビジネスルール群を先に把握する。ここは維持し、調整はChange Model側の設定（sttrm_state）で行う

2. 必須化・読み取り専用化：画面だけの制御ならUI Policy／Data Policyで足り、APIやFlow経由も含めて強制したいならorder900と同じBusiness Ruleパターンで追加する

3. リスク自動計算：独自基準はrisk_conditionsへ行を追加する。Moderateを自動判定させたいなら専用の行が要る

4. コンフリクト検知：担当者の重複を検知したいならchange.conflict.assigned_toを有効化する

5. 承認の自動生成：typeごとに承認経路が変わる前提で設計する。エラー時はsys_flow_contextで実行記録を確認する

6. CABとの同期：CABの決定がsysapproval_approverへどう反映されるかを把握する

7. 通知の取捨：16件のうち送るべきものだけを残す

用語

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

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

• Change Model：typeごとの状態遷移とテンプレートを束ねる仕組み

• risk_conditions：リスクの自動判定に使う条件テーブル

• sysapproval_approver：承認者と承認状態を1件ずつ記録するテーブル

• delivery_plan：実装計画。承認後にChange Taskを起動する起点になる

• g_scratchpad：displayのビジネスルールからクライアントスクリプトへ値を渡す入れ物

検証範囲とおことわり

• 検証環境：Australia PDI / OOTB / 2026-09-01 確認（一部追実測は2026-09-03）

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

• Change Model: Check State TransitionのcanTransition()内部の分岐条件は、中断に至る主要な行までの確認にとどめています

• Flow Designerの各フロー内部（アクション・条件分岐）とトリガーの絞り込み条件は確認していません。トリガー種別（record_create_or_update）のみ実測しました

• 実際に1件のChange Requestを保存し、発火するビジネスルールの順序をトレースログで確認する検証は行っていません

• change_taskの19件のビジネスルールは、代表例のみを確認しています

• デモデータのrisk=Moderateがどの経路で入力されたか（初期データ投入時の個別設定か）は本調査の範囲外です

• on_holdの保存中断・close_codeの必須化・typeの新規時限定変更は、第3巻「変更管理モジュールのロール」で詳しく扱っています

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

• ビジネスルールのタイミング別：/sys_script_list.do?sysparm_query=collection=change_request^active=true^GROUPBYwhen

• ビジネスルールをorder順に：/sys_script_list.do?sysparm_query=collection=change_request^active=true^ORDERBYorder

• order900台の必須化ルール：/sys_script_list.do?sysparm_query=collection=change_request^order=900^active=true

• task共通のビジネスルール：/sys_script_list.do?sysparm_query=collection=task^active=true

• クライアントスクリプト：/sys_script_client_list.do?sysparm_query=table=change_request^GROUPBYtype

• データポリシー：/sys_data_policy2_list.do?sysparm_query=model_table=change_request

• UIアクション：/sys_ui_action_list.do?sysparm_query=table=change_request^active=true

• Flow Designer：/sys_hub_flow_list.do?sysparm_query=nameLIKEChange^active=true^type=flow

• 承認の状態別集計：/sysapproval_approver_list.do?sysparm_query=sysapproval.sys_class_name=change_request^GROUPBYstate

• リスク判定条件：/risk_conditions_list.do?sysparm_query=table=change_request^ORDERBYorder

• リスク計算方式のプロパティ：/sys_properties_list.do?sysparm_query=name=glide.ui.risk_calculate_rule

• コンフリクト関連プロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHchange.conflict

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

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

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameINglide.approval_engine.change_request,glide.ui.risk_calculate_rule

関連記事

• 変更の流れを決める Change Model（chg_model） … Change Modelの構造はここから

• インシデント管理モジュールの自動設定構成 … 同じ切り口でIncidentを扱った回です

• 変更管理モジュールの概要 … typeの使い分け全体はここで整理しています