---
sourceDocument: Xanadu IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-service-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# 状況モデルへのステータスの追加

# 状況モデルへのステータスの追加 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：6分

組織の要件に基づいて、さまざまな変更タイプに対して既存の状況モデルに新しいステータスを追加できます。

## 始める前に

必要なロール：script_include_admin、ui_policy_admin、ui_action_admin、または admin

## このタスクについて

「[状況モデル](https://servicenow-prod.fluidtopics.net/069H6utlKVOZGU~as9DmrQ "アドミンロールを持っている場合は、[変更管理 - 状況モデル] プラグイン (com.snc.change_management.state_model) をアクティブ化できます。このプラグインにはデモ データが含まれ、関連プラグインがまだアクティブ化されていない場合はアクティブ化します。")」プラグインはデフォルトで有効になっています。変更要求の基本システム状況の詳細については、次を参照してください。 [状況モデルと移行](https://servicenow-prod.fluidtopics.net/KDpDZuAOhkSNkMicAbZh4Q "変更管理は、いくつかのステータスを経て変更要求を移動および追跡するための状況モデルを提供します。")。

## 手順

1. \[すべて\]\[変更\]\[新規作成\]に移動し、後続のステップを完了して選択リストに選択肢を追加します。
   1. \[ステータス\] フィールドを右クリックして、\[ディクショナリを設定\] をクリックします。
   2. \[選択肢\] 関連リストで、 \[テーブル\] \[次の値に等しい (=)\] \[change_request\] のフィルターを実行します。
   3. \[新規\] をクリックし、新規ステータスに次の情報を追加します。  
      * テーブル：変更要求 \[change_request\]
      * ラベル：新規ステータスの名前
      * 値： 既存のステータス選択にまだ割り当てられていない数値
      * シーケンス：状況のリストに現れる場所に対応する番号。別の選択肢と同じシーケンス番号をアサインすると、他の選択肢の下に表示されます。
      {#t_AddANewState__ul_fwz_ncm_5y}
   4. \[送信\] をクリックします。
   {#t_AddANewState__substeps_sbc_1cm_5y}
2. \[システム定義\]\[スクリプトインクルード\] に移動します。  
   名前に SNC が含まれているスクリプトインクルードレコードは読み込み専用です。次の手順を完了したら、変更する正しいスクリプトインクルードを選択していることを確認します。たとえば、変更するのは ChangeRequestStateHandler で、ChangeRequestStateHandlerSNC ではありません。  
   注:  
   拡張スクリプトインクルード (SNC を含んでいないもの) には、同じもので SNC があるものの機能のすべてが含まれています。基本スクリプトインクルード (SNC が付加されているもの) を変更すると、システムアップグレード中にそれ以上は更新できなくなります。
3. ChangeRequestStateHandler スクリプトを開いて、次の編集を実行します。  
   * このスクリプトインクルードの最初にある \[ステータス ハンドラー定数\] セクションを更新して、新しく追加されたステータスの値を含めます。例：

         ChangeRequestStateHandler.MY_NEW_STATE = "mynewstate";

   * 初期化機能の最後にある \[STATE_NAMES\] マップを更新して、新しく追加されたステータスの数値を含めます。例：

         this.STATE_NAMES["-6"] = ChangeRequestStateHandler.MY_NEW_STATE;

     注:  
     \[STATE_NAMES\] マップは、変更要求について \[ステータス\] フィールドに保存されている数値の間のマッピングを覚えやすい名前で提供します。このマッピングにより、状況モデルスクリプトインクルードに覚えやすい名前を使用することができます。
   {#t_AddANewState__ul_t4k_yhq_nv}
4. 適切なスクリプトインクルードを編集して、関連する変更要求タイプのモデルに新しい状況を組み込みます。  
   変更の要求の各タイプには ChangeRequestStateModel_\<type\> という名前の関連するスクリプトインクルードがあります。ここで、\<type\> は変更の要求タイプの値です。たとえば、ChangeRequestStateModel_normal は、通常のタイプの変更要求に対して状況モデルを定義します。  
   それぞれの状況モデル スクリプトインクルードは、次の情報を指定するオブジェクトを定義します。
   * どの状況が利用可能か。
   * 利用可能な状況ごとの次の状況。
   * 状況移行ごとに、その移行が利用可能 `(canMove)` かどうかを、そのステータス `(moving)` への移動の一部として実行される関数とともに特定する機能。
   {#t_AddANewState__ul_lk4_vkq_nv}

   次の例は、ChangeRequestStateModel_normal スクリプトインクルードからのものです。
5. UI アクションを作成して、変更要求を新しいステータスに進めるためのボタンを用意します。
   1. \[挿入と維持\] を使用して、\[実装\] など、デフォルトの UI アクションの 1 つをコピーします。
   2. フォームにある次のフィールドを更新します。  
      {#t_AddANewState__table_rgn_wmq_nv__entry__2}

      | フィールド名 | 更新 |
      |-|-|
      | 名前 | 新しいステータスの名前と一致するように更新します。 |
      | アクション名 | 名前の最後にあるステータスを新しいステータスに置き換えます。 |
      | ヒント | テキストを更新して、新しいステータスを参照します。 |
      | クリック時 | 新しいステータスに一致するように関数の名前を変更します。 |
      | 条件 | `isNext` 関数の呼び出しを新しいステータスで更新します。 |
      | スクリプト | * 関数名を、\[クリック時\] フィールドに指定されているいずれかと一致するよう更新します。 * `ga.addParam("sysparm_state_name",...` で始まる行を更新して、`addParam` 関数の 2 つ目のパラメーターとして新しいステータスの名前を入力します。 * `gsftSubmit` で始まる行を更新し、\[アクション名\] フィールドに入力されている値と一致するようにこの関数呼び出しの 3 つ目のパラメーターを変更します。 {#t_AddANewState__ul_l4y_hnq_nv} |
      [ ]

      {#t_AddANewState__table_rgn_wmq_nv}

      次の例は、更新する値を表示する \[実装\] UI アクションを使用しています。  
      ChangeRequestStateHandler スクリプトインクルードには、変更要求の現在のステータスに基づいて UI アクションが表示されるかどうかを判定するために使用される 2 つの関数が含まれています。
      * `isNext(stateName)`：この関数は stateName がパラメーターとして変更要求の現在のステータスにとってその次のステータスとして利用可能であるかどうかのみをチェックします。
      * `canMoveTo(stateName)`：この関数は isNext 関数と同じチェックを実行します。ただし、現在のステータスからパラメーターとして渡される stateName への移行のための適切な canMoveTo 関数の呼び出しの結果もチェックします。この関数は、フィールドに特定の値が含まれていることのチェックなど、canMove 関数で追加的なチェックがある場合に使用されます。
      {#t_AddANewState__ul_bcm_r4q_nv}
   {#t_AddANewState__substeps_afc_lmq_nv}
6. 次の手順を実行して、新しい変更ステータスを組み込むようにプロセスフロー設定を更新します。  
   プロセスフローは、変更要求フォームの最上部に表示され、さまざまなプロセスフローレコードで設定されます。  
   1. \[システム UI\]\[プロセス フロー\] モジュールに移動し、\[テーブル\] \[次の値に等しい (=)\] \[change_request\] のフィルタリングを行います。
   2. レコードを開いて、\[挿入と維持\] を使用してコピーを作成します。
   3. フォームにある次のフィールドを更新します。  
      {#t_AddANewState__table_t33_tpq_nv__entry__2}

      | フィールド名 | 更新 |
      |-|-|
      | 名前 | 新しいステータスの名前と一致するように更新します。 |
      | ラベル | 新しいステータスの名前と一致するように更新します。この値は、変更要求フォームの最上部にあるプロセスフローに含まれています。 |
      | 順番 | 新しい状況が他のステータスの既存のプロセスフローレコードに対応する順序になるようにこの番号を更新します。 |
      | 条件 | 新しいステータスの名前と一致するように更新します。 |
      [ ]

      {#t_AddANewState__table_t33_tpq_nv}
   4. \[更新\] をクリックします。
   {#t_AddANewState__substeps_bcd_jgw_ht}
{#t_AddANewState__steps_wgg_xbn_5y}

## 次のタスク

新しいステータスが期待どおりに機能するようにするには、デフォルトのワークフローをレビューしてください。必要に応じて、新しいステータスをワークフローに追加します。

## デフォルト ワークフローのレビュー {#ariaid-title2}

状況モデルに変更があると、変更要求のデフォルト ワークフローに影響する場合があります。

### 始める前に

必要なロール：admin

### このタスクについて

各変更タイプには、デフォルトのワークフローがあります。状況モデルへの変更がワークフローに悪影響を及ぼさないようにするには、デフォルトの各ワークフローをレビューする必要があります。

### 手順

変更されたそれぞれの `ChangeRequestStateModel_<type>` スクリプトインクルードのワークフローをレビューしてください。  
{#t_ReviewDefaultWorkflows__table_kbw_rbr_nv__entry__3}

| 変更タイプ | スクリプトインクルード名 | Workflow |
|-|-|-|
| 標準 | ChangeRequestStateModel_normal | 変更要求 - 標準 |
| 標準 | ChangeRequestStateModel_standard | 変更要求 - 標準 |
| 緊急 | ChangeRequestStateModel_emergency | 変更要求 - 緊急 |
[表 : 1. 変更要求デフォルト ワークフロー]

{#t_ReviewDefaultWorkflows__table_kbw_rbr_nv}

各変更タイプのデフォルト ワークフローの変更は、状況のシーケンスで新しい状況が追加される場所によって異なります。