検索定義の例

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む3読むのに数分

    • 検索定義のユースケースを以下で説明します。

    ユースケース 1a:グループ間でのレコードのバウンスアナリストは多くの場合、特定のグループ (サービスデスクなど) からのレコードを特定し、別のグループに再アサインし、最終的に最初のグループによって再度解決されます。 グループ間でのレコードのバウンス

    最初のグループがわかっている場合は、メッセージとカテゴリの検索ルールを使用します。
    • 開始条件テーブル構成:インシデント
    • 開始条件
      • 名前:グループ名 (Service Desk など)
      • 条件タイプ:フィールド/値条件
      • フィールド = アサイン先グループ
      • 述語 = 次の条件に一致
      • フィールド値 = Service Desk
      • 一致する出現件数:最初のみ
    関係:最終的に次が続く
    • 終了条件テーブル構成:インシデント
    • 終了条件
      • 名前:グループ名 (Service Desk など)
      • 条件タイプ:フィールド/値条件
      • フィールド = アサイン先グループ
      • 述語 = 次の条件に一致
      • フィールド値 = Service Desk
      • 一致する発生件数:最後のみ
      • 追跡期間:true

    ユースケース 1b:類似した初期グループを持つグループ間ですべてのバウンスレコードを特定する必要がある場合は、メッセージとカテゴリの検索ルールを使用します。

    • 開始条件テーブル構成:インシデント
    • 開始条件
      • 名前:アサイン先グループは何でも
      • 条件タイプ:フィールド/値条件
      • フィールド = アサイン先グループ
      • 述語 = 何でも
      • 一致する出現件数:最初のみ
    関係:最終的に次が続く
    • 終了条件テーブル構成:インシデント
    • 終了条件
      • 名前:アサイン先グループは何でも
      • 条件タイプ:フィールド/値条件
      • フィールド = アサイン先グループ
      • Predicate=Is anything (述語=は何でも)
      • 一致する発生件数:すべて
      • 追跡期間:true
      • 関係制約:同じアサイン先グループを持つ

    ユースケース 2:SLA 違反SLA 違反が発生したときに [新規] ステータスだったすべてのレコードを表示します。SLA 違反フロー

    検索定義にメッセージとカテゴリを指定したら、次のように検索ルールを指定します。
    • 開始条件テーブル構成:インシデント
    • 開始条件
      • 名前 = ステータス
      • 条件タイプ:フィールド/値条件
      • フィールド = 都道府県
      • 述語=Is
      • [フィールド値] = [新規]
      • 一致する発生件数 = 最初のみ
    • コンテキスト条件:
      • 名前 = SLA 違反
      • Finding Def = 検索定義メッセージを追加
      • 条件タイプ = コンテキストフィールド/値条件
      • Field=Made SLA (プロジェクトでアクティビティ定義として [Made SLA] が定義されていることを確認してください)
      • 述語=は次の値と異なる
      • フィールド値 = true
    • 関係:直行
    • 終了条件テーブル構成:インシデント
    • 終了条件
      • 名前:都道府県
      • 条件タイプ:フィールド/値条件
      • フィールド = 都道府県
      • 述語=is
      • [フィールド値] = [対応中]
      • 一致する発生件数 = 最初のみ
    • コンテキスト条件:
      • 名前 = SLA 違反
      • 条件タイプ = コンテキストフィールド/値条件
      • Field=Made SLA (プロジェクトでアクティビティ定義として [Made SLA] が定義されていることを確認してください)
      • 述語=is
      • フィールド値 = true
    • 追跡期間:true
    SLA 違反

    ユースケース 3:親ステータスが [対応中] からタスクの作成まで 6 時間を超えている。解決時間またはレコードは、多くの場合、1 つ以上のタスクの完了によって異なります。したがって、メインレコードの解決時間を改善するには、メインレコードが [対応中] ステータスに達した後、できるだけ早くタスクを開始することが重要です。この例では、ユーザーは、メインレコードが [対応中] になってから、基になるタスクの作成に 6 時間以上かかったすべてのレコードを検索したいと考えています。検索定義にメッセージとカテゴリを指定した後、次のように検索ルールを指定します。

    • 開始条件テーブル構成:インシデントなどの親
    • 開始条件
      • 名前:対応中の最初の発生
      • 条件タイプ:フィールド/値条件
      • フィールド = 都道府県
      • 述語=Is
      • [フィールド値] = [対応中]
      • 一致する出現件数:first、only
        • 関係:最終的に次が続く
        • 終了条件テーブル構成:インシデントタスク
        • 終了条件
          • 名前 = incident task start
          • [条件タイプ] = [プロセスの開始]
            • 制約:最短期間は 6 時間です
            • 追跡期間:true 検索定義の発生
    検索ルールの仕様