標準チケットページ

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間:3分
  • 他の要求タイプと同様の一貫したレイアウトを維持しながら、要求固有の情報を表示するように個々の要求タイプを構成します。この構成により、送信された要求を表示する際の一貫したエクスペリエンスが保証されます。

    新しいインスタンスの場合、標準チケットページはデフォルトで利用できます。アップグレードされたインスタンスの場合は、[標準チケットルート] ページのルートマップを有効にする必要があります。このページルートマップのアクティブ化については、「 標準チケットページのページルートマップのアクティブ化」を参照してください。

    標準チケットページの各セクションに表示される情報は、個々の要求タイプによって異なります。構成可能なセクションに値が指定されていない場合、またはユーザーが情報へのアクセス権を持っていない場合、セクションは表示されません。

    図 : 1. インシデントの標準チケットページ
    インシデント標準チケットページ

    ヘッダーセクション

    デフォルトでは、このセクションには送信された要求に関する次の情報が表示されます。
    • 識別番号
    • 作成日および更新日
    • ステータス。[ ステータス ] フィールドの代わりに、チケットのステータスを表す他のフィールドを設定することもできます。

    [情報] セクション

    設定されている場合、このセクションには送信された要求の次のリージョンが表示されます。
    • 簡単な説明を含むチケットの説明領域、およびオプションで説明。
      注:
      [ 説明] フィールドをレコードの他のフィールドにマッピングできます。
    • フィールド 関連付けられたフィールドが構成されているリージョン。設定されたフィールドは、値がない場合、またはユーザーがフィールドへのアクセス権を持っていない場合には表示されません。
      注:
      ワークフロータイプのフィールドは、どのテーブルでもサポートされていません。要求アイテム [sc_req_item] テーブルでのみ、[ステージ] フィールドなどのワークフロータイプのフィールドはサポートされます。このフィールドは、構成内のフィールドの位置に関係なく最後に表示されます。
    • アクションリージョン

    タブのセクション

    設定されている場合、このセクションには、送信された要求に対して次のタイプのタブが表示されます。
    • アクティビティ
    • 添付ファイル
    • 変数エディター
    • 変数サマライザー
    • 関連する要求。現在のチケットが親である、関連するすべての要求 (サービスポータルの [自分の要求 ] ウィジェットに表示されます)。これは、次のいずれかのシナリオに適用できます。
      • 現在のチケットがユニバーサル要求の場合、ユニバーサル要求の子チケットに関連付けられたすべての要求が (タスクテーブルの [ ] フィールドを介して) 表示されます。
      • 現在のチケットがユニバーサル要求でない場合は、現在のチケットに関連付けられているすべての要求が (タスクテーブルの [親 ] フィールドを介して) 表示されます。

      [自分の要求] ウィジェットのフィルターの定義については、「 自分の要求のフィルターの定義」を参照してください。

    • カスタムタブ

    デフォルトでは、[ アクティビティ] タブと [添付ファイル] タブが使用可能です。

    クロススコープアプリケーションの構成

    クロススコープアプリケーションの要求タイプごとに、次の構成が必要です。
    • 次の標準チケットページウィジェットに対する限定呼び出し元アクセス権限により、これらのウィジェットがアプリケーションテーブルにアクセスできるようにします。これらの特権の詳細については、「 Application access settings」を参照してください。
      • ウィジェット:標準チケットヘッダー
      • ウィジェット:標準チケット添付ファイル
      • ウィジェット:標準チケットタブ
    • アプリケーションの [説明] フィールドに対する制限付き発信者アクセス特権。このフィールドは、標準チケットページのヘッダーに表示されます。
    • そのアプリケーションのすべての要求を標準チケットページにルーティングするためのページルートマップ

    標準チケットページのドメインセパレーション

    タブ構成はドメインセパレーションされていません。

    チケット構成はプロセスドメインセパレーションされています。どの要求タイプレコードでも、ユーザーが標準チケットページを開くと、ユーザーのドメインに関係なく、次の順序でチケット構成がチェックされます。

    1. レコードのドメイン内
      1. レコードテーブルのチケット構成
      2. レコードテーブルの親テーブルのチケット構成
    2. レコードドメインの親階層内
      1. レコードテーブルのチケット構成
      2. レコードテーブルの親テーブルのチケット構成
    注:
    テーブルの場合、ドメインごとに許可されるアクティブな構成は 1 つだけです。