---
sourceDocument: Yokohama 従業員サービス管理 (ESM)
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/employee-service-management

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama 従業員サービス管理 (ESM)

ft:clusterId :

    - emplsm

bundleId :

    - emplsm

workflow :

    - Employee


---

# ユニバーサル要求 データモデル

# ユニバーサル要求 データモデル {#ariaid-title1}

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

ユニバーサル要求 は、部門間のコラボレーションと統一された従業員エクスペリエンスをサポートするタスクタイプです。ユニバーサル要求 は、IT インシデントや HR ケースなどの部門プライマリチケットの親レコードになり、組織が部門間の SLA および OLA を測定できるようにします。  
ユニバーサル要求 (UR) は、次のいずれかのソースから作成できるタスクです。

* 要求者が作成した場合：従業員は次のいずれかのオプションを使用して要求を送信します。
  * サービスポータル または 従業員センター で \[ヘルプの要求\] をクリックします。
  * モバイルデバイスで \[ヘルプが必要 (Needs Help)\] をタップします。
  * ポータルで仮想エージェントチャットを使用します。
  {#UR-datamodel__ul_o2h_zyd_14b}
* エージェントが作成した場合：IT サービスデスクエージェントは、従業員から電話またはライブチャットを受け取り、新規コールレコードまたはインタラクションレコードを開始し、場合によっては部門チケットの代わりにユニバーサル要求を作成できます。エージェントは、その UR を適切な階層 1 アサイン先グループにアサインできます。
* システムで生成された場合：構成に基づいて従業員がレコードプロデューサーを送信するとユニバーサル要求が作成されます。レコードプロデューサーは、ユニバーサル要求を自動的に作成して部門間の要求転送と要求者に対する一貫したチケットビューを有効にするように構成されています。
{#UR-datamodel__ul_y1d_n5g_gmb}

次の図は、ユニバーサル要求データモデルの概要を示しています。

ユニバーサル要求 データモデルは、次のテーブルの組み合わせを使用してデータを保存します。

* Now Platform テーブル
* ユニバーサル要求 に含まれるテーブル

{#UR-datamodel__ul_pky_k3m_3nb}詳細については、「[ユニバーサル要求 プラグイン](https://servicenow-prod.fluidtopics.net/uRq3RLm1TaA6U1nmURZkfg "アプリケーションでユニバーサル要求を使用するには、次のプラグインを要求してアクティブ化します。")」のリストを参照してください。  
タスク \[task\] テーブルは、次のフィールドを含むように変更されます。

* ユニバーサル要求 (UR) フィールドは、親 UR レコードを指します。このモデルでは、タスクテーブルを拡張する任意のテーブルを UR の子にすることができます。
* 要求に UR が関連付けられている場合、\[有効な番号 (Effective Number)\] フィールド (識別番号) に UR 番号が保存されます。UR に関連付けられていない場合、\[有効な番号 (Effective Number)\] には現在の部門固有の要求番号が保存されます。
* \[転送理由 (Transfer Reason)\] フィールドには、要求の転送理由が保存されます。可能なオプションは:

  解決する (With resolution)
  :   要求が完了し、特定の部門またはサービスである ユニバーサル要求 に戻されることを示します。

  解決しない (With resolution)
  :   要求が完了せず、特定の部門またはサービスである ユニバーサル要求 に戻されることを示します。
{#UR-datamodel__ul_xzm_4sg_llb}  
ユニバーサル要求 テーブルには次が含まれます。

* 顧客向けステータスの状況理由
* 部門固有の要求のプライマリチケット詳細
* 作成された要求が機密かどうかを示す制限付きフィールド
{#UR-datamodel__ul_xq3_3lm_3nb}

ユニバーサル要求 には、顧客がさまざまなテーブルへのアクセスを提供するために使用できるユーザーロールと ACL も含まれています。これには、内部および外部ユーザーロールの両方が含まれます。  
ユニバーサル要求は、ベースタスク \[task\] テーブルから拡張された新しいタスクタイプであり、UR というプリフィックスが付いた番号で一意に識別されます。{#UR-datamodel__simpletable_bpc_mtg_llb__entry__2}

| フィールド | 説明 |
|-|-|
| プライマリチケット | ユニバーサル要求で現在アクティブな要求を参照します。例：INC1022201 |
| 依頼者 | ユニバーサル要求が作成される要求者 |
| 状況 | ユニバーサル要求の現在のステータス。UR は次のいずれかの状況になります。 * 新規 * 進行中 * ユーザからの応答待ち (Awaiting Response From User) * クローズ済み {#UR-datamodel__ul_ghn_bnt_3mb} UR 状況の詳細については、「[ユニバーサル要求 ステータスと理由](https://servicenow-prod.fluidtopics.net/CyJyiMiZw4hQ4NDJH0SJMA "ユニバーサル要求 (UR) 状況はプライマリチケットのステータスによって決定されます。UR のプライマリチケットは、IT インシデントや HR ケースなどの子部門チケットです。1 つのユニバーサル要求は、一度に 1 つのプライマリチケットのみを使用できます。")」を参照してください。 |
| 状況の理由 | 一部の要求者向け状況に対するエージェント向けの理由。ステータスの理由の値は次のとおりです。 トリアージ (Triaging)： :   ユニバーサル要求状況が \[処理中\] の場合に考えられるステータスの理由。ユニバーサル要求がトリアージされていることを示します。 プライマリチケット WIP： :   ユニバーサル要求状況が \[処理中\] の場合に考えられるステータスの理由。アクティブなプライマリチケットの作業が処理中であることを示します。 応答確認 (Confirm response)： :   ユニバーサル要求状況が \[処理中\] である場合に考えられるステータスの理由ですが、要求者に対するチケットをクローズする前にステータスの理由が \[応答確認\] に変わり、応答を承認または却下するよう階層 1 エージェントに通知します。これは、ユニバーサル要求の \[レビューが必要 (Needs Review)\] フラグが true に設定されている場合に発生します。 解決策の承認 (Accept Resolution)： :   ユニバーサル要求が \[応答待ち (Awaiting Response)\] ステータスの場合に考えられるステータス理由。提供された解決策を承認する要求者の処理待ちのアクションがあることを示します。 アクションが必要： :   ユニバーサル要求が \[応答待ち (Awaiting Response)\] ステータスの場合に考えられるステータス理由。要求者によって実行する追加のアクションがあることを示します。 |
| 制限付き | 機密データがあるチケットへのアクセスを制限するオプション。チケットが制限付きとしてマークされている場合、機密要求へのアクセス権を持つエージェントのみがチケットを表示して解決できます。 |
[表 : 1. ユニバーサル要求 テーブル]

{#UR-datamodel__simpletable_bpc_mtg_llb}

## ユニバーサル要求テーブルの \[プライマリチケット (Primary Ticket)\] フィールド {#UR-datamodel__section_mmr_nv2_hmb}

ユニバーサル要求の \[プライマリチケット (Primary Ticket)\] フィールドによって、UR 状況と要求者のチケットビューエクスペリエンスが決定します。プライマリチケットの \[標準チケット\] ページ構成を使用して、標準チケットページのさまざまなセクションに表示する必要があるコンテンツを決定します。UR のプライマリチケットは、IT インシデントや HR ケースなどの部門チケットです。  
注:  
1 つのユニバーサル要求は、一度に 1 つのプライマリチケットのみを使用できます。

初めて作成されたユニバーサル要求の場合、プライマリチケットは存在しません。IT インシデントや HR ケースなどの子部門チケットが UR から作成された場合、その子チケットがプライマリチケットになります。プライマリチケットが UR または別の部門に戻されると、\[プライマリチケット (Primary Ticket)\] フィールドは空になります。新しいプライマリチケットが追加され、UR または別の部門に戻されると、このシーケンスが続行されます。

ユニバーサル要求を自動的に作成するようにレコードプロデューサーが構成されている場合、その UR が親レコードになります。また、部門チケットが作成されると、そのレコードがプライマリチケットになり、UR、別の部門、またはサービスに戻されるまで残ります。