4.3.8.3 チケットの承認機能

チケットの承認機能により、承認者がチケットの記載内容の確認ができるため、チケット管理上の品質を確保できます。例えばリクエストチケットのインシデントの承認は、インシデントの重要度や影響度を評価し、適切な優先度を設定するために行われます。これにより、リソースの適切な割り当てや対応の優先順位付けが可能となります。
チケットの承認機能は、タイプごとに有効/無効を設定できます。チケット機能を有効にする際に、承認が必要なステータス、承認された場合に遷移するステータス、却下された場合に遷移するステータスを設定します。

【承認機能の利用条件】

承認機能を利用するには以下の対応が必要です。

  • 承認機能が有効になっている：
    詳細は「承認機能の有効化・無効化」を参照してください。
  • 承認フローダイアログの「ステータス」フィールドに、承認機能を適用するステータスを設定している：
    詳細は「承認フロー」を参照してください。チケットタイプのデフォルトのステータス、およびユーザーが追加したステータスを設定できます。ステータスを追加する場合は「チケットのステータス」を参照してください。

注意事項注意事項

  • 特定のチケットタイプで承認機能を利用する場合は、承認が必要なステータスは、チケットタイプごとに設定されたステータス遷移に含まれる必要があります。例えば、rfcチケットの承認機能が有効化されている場合、変更種別によってステータス遷移が異なるため、承認が必要なステータスがステータス遷移に含まれる変更種別のみ、承認フローボタンが表示されます。
  • 承認機能で承認、却下された場合に遷移するステータスは、チケットタイプごとに設定されたステータス遷移とは関係ありません。
  • 承認中のチケットがある状態で、承認フローに設定されたユーザーやグループを削除した場合、当該チケットは承認できなくなります。承認中のチケットがあるユーザーやグループは削除しないでください。また、承認ができなくなった場合は「承認中のチケットが承認できなくなった場合」の方法で回避してください。


承認機能を利用する場合のユースケースを以下に示します。

（表）承認機能のユースケース

作業 説明
承認機能が必要なチケットタイプに承認機能を設定する
  1. チケットの承認機能を有効化する
    承認が必要なステータス"awaiting_approval"、承認された場合に遷移するステータス"awaiting_implementation"、却下された場合に遷移するステータス"declined"を設定する
チケット作成後、チケット詳細画面で承認者を設定する
  1. チケットに承認者を設定する
    チケットに1人以上の承認者と承認順を設定する
  2. チケットを保存する
承認者に通知する※
  1. チケットのステータスを"awaiting_approval"にする
  2. 最初の承認者へ自動的に承認依頼が通知される
承認者はチケットの記載を確認し、承認または却下ができる
  • 承認する
    1. 承認日時が保存される
    2. 次の承認者がいる場合：次の承認者に自動的に通知される
      次の承認者がいない場合：次のステータス"awaiting_implementation"に自動的に遷移する
  • 却下する
    1. 次のステータス"decline"に自動的に遷移する
      このとき承認済の日時はリセットされる
    2. 担当者に却下通知が自動的に通知される
    3. 担当者がチケットを修正し、再申請するためステータスを"awaiting_approval"にすることで、最初の承認者に再度承認依頼が通知される。このとき承認日時は再設定される
※チケットが承認者以外のユーザーによって編集された場合、承認依頼は更新後の内容で承認者に再度通知されます。

作業の詳細について以下に示します。

（1）承認機能の有効化・無効化

チケットの承認機能は、デフォルトで無効化されています。承認機能はREST APIで、チケットタイプごとに有効化できます。承認機能が有効化されると、新規チケット追加画面とチケット詳細画面の操作ボタンに「承認フロー」が表示され、承認者の設定を行えます。承認フローボタンはタスクアプリケーションにのみ表示されます。チケット詳細画面の構成の詳細は「（表）チケット詳細画面の構成」、新規チケット追加画面の詳細は「（表）新規チケット追加画面の構成」を参照してください。

承認機能の有効化、無効化、および設定の変更を行うには、Primitiveロール「itsm_admin」または「itsm_manager」が割り当てられている必要があります。ただしPrimitiveロール「free_user」または「manager」が割り当てられている場合は、承認機能の設定の取得、有効化、無効化、および設定の変更を行えません。

設定は以下のREST APIで行います。詳細は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス詳細＞カスタムAPI」を参照してください。

【承認機能を有効化する】

POST /capi/v1/ticket-settings/approval

有効化すると以下が表示されます。

  • 承認フローボタン（新規チケット追加画面、チケット詳細画面）
  • 「承認者」フィールド※：現在の承認者の名前（チケット詳細画面）
  • 「承認グループ」フィールド※：現在の承認グループ名（チケット詳細画面）
※読み取り専用です。承認が必要なステータス以外では空欄になります。承認者、承認グループの設定方法は「（表）承認フローダイアログの構成」を参照してください。

承認機能を有効化するタイプごとにAPIで以下を設定します。承認が必要なステータスは複数設定できます。

  • type：承認を有効化するチケットタイプ
  • approval：承認が必要なステータス
  • transition
    • approved：承認された場合に遷移するステータス
    • declined：却下された場合に遷移するステータス
  • reset：遷移した際に承認済の承認日時がリセットされるステータス（任意）

以下にリクエストボディの例を示します。

＜承認が必要なステータスが1つの場合＞

{
  "type": "rfc",
  "statuses": [
    {
      "approval": "awaiting_approval",
      "reset": "new",
      "transition": {
        "approved": "awaiting_implementation",
        "declined": "declined"
      }
    }
  ]
}


＜承認が必要なステータスが2つの場合＞

{
  "type": "rfc",
  "statuses": [
    {
      "approval": "awaiting_approval",
      "reset": "new",
      "transition": {
        "approved": "awaiting_implementation",
        "declined": "declined"
      }
    },
    {
      "approval": "completed",
      "reset": "new",
      "transition": {
        "approved": "closed",
        "declined": "cancelled"
      }
    }
  ]
}


【承認機能を無効化する】

DELETE /capi/v1/ticket-settings/approval/{id}

チケットの承認機能を無効にした時点で、既存のチケットにも適用されます。承認が必要なステータスになっても承認を行わずに処理を進めることができます。承認フローが設定されている場合は、無効化された後もチケット詳細画面から読み取り専用で確認できます。


【承認機能を有効にするタイミングの影響】

チケットの承認機能を有効にした時点で、既存のチケットにも適用されます。ただし、ステータスの状態によっては、承認なしで処理を進めることができます。

  • 承認が必要なステータスの前に承認機能が有効になった場合：承認あり
    承認が必要なステータスに遷移するまでに、承認フローのダイアログで承認者の設定をする必要があります。
  • 承認が必要なステータスで承認機能が有効になった場合：承認なし
  • 承認が必要なステータスの後で承認機能が有効になった場合：承認なし
例：既存のチケットのステータス遷移A～Eの中で、承認が必要なステータスがBとDの場合

A  →  B  →  C  →  D  →  E

既存のチケットのステータスがAの場合、BとDで承認が必要です。既存のチケットのステータスがBまたはCの場合、Dで承認が必要です。既存のチケットのステータスがDまたはEの場合、承認は不要です。

注意事項注意事項

  • チケットの承認機能の有効化・無効化は、チケットタイプごとに設定され、顧客ごとに設定を変えることはできません。
  • 承認が必要なステータスには以下のステータスを設定しないでください。
    • チケットの新規作成時に設定されるステータス
    • 承認機能で承認、却下した際に遷移するステータス
    • 遷移した際に承認済の承認日時がリセットされるステータス
  • 一度承認したステータスは基本的には繰り返さないように設計してください。再承認を行いたい場合は、resetに指定したステータスを経由するように設計してください。



（2）承認者の設定

承認機能では、以下の設定ができます。さらに複雑な承認フローが必要な場合は、ワークフローの機能を用いてください。

  • チケットごとに1名以上の承認者と承認順を設定できる
  • 承認の同一ステップに複数の承認者を設定し、指定した人数以上が承認すれば次ステップへ遷移する設定にできる
  • ユーザーまたはグループでの承認者の指定ができる
  • 承認フローの設定がブラウザーに保持されるため、同一ユーザーが同じブラウザーで操作する場合、前回の承認フローの設定を初期値として用いることができる

承認者の設定はタスクアプリケーションから実施できます。設定方法、承認フローの設定の保持の詳細は「承認フロー」を参照してください。


（3）承認者による承認・却下

チケットを保存するときに、承認フローが設定されたステータスに変更すると、最初のステップの承認者または承認グループに通知されます。このステータスでチケットが承認者以外のユーザーによって編集された場合、編集された時点で再度通知されます。
通知を受け取った承認者は、チケット詳細画面の承認ボタンまたは却下ボタンからチケットを承認、または却下できます。このステータスでは他のステータスへの変更はできません。

承認フローの次のステップに遷移すると次の承認者または承認グループへ通知されます。最後のステップの承認者または承認グループの承認が完了すると、次のステータスに遷移します。
却下された場合、承認日はリセットされ、却下後のステータスに遷移し担当者に通知されます。
担当者はチケットを修正し、承認フローで設定されたステータスで保存することで、再度承認の依頼を出せます。このとき承認フローは最初のステップからやり直しになり、新たな承認日が設定されます。
作業の詳細は「承認フロー」を参照してください。また、通知方法の詳細については「チケットの通知機能」を参照してください。


【承認中のチケットが承認できなくなった場合】

ユーザーやグループの削除などで承認中のチケットが承認できなくなった場合は、以下の方法で承認をキャンセルし、ステータスを変更することができます。

  1. REST API「PATCH /capi/v1/tickets/{id}」 を以下のリクエストボディで実行してください。

    {
        "approvalFlows": []
    }

    この操作を行うと、指定したチケットのすべての承認フローがリセットされ、承認日時も取り消されます。

  2. チケット詳細画面からステータスを変更してください。
    • 承認が必要な場合：承認が必要なステータスより前のステータスに変更し、承認フローを設定してください。
    • 承認が必要ない場合：承認が必要なステータスより後のステータスへ変更してください。

    チケット詳細画面で表示されるステータスの候補は、ステータス遷移で設定した項目となります。
    2つ以上の承認が必要なステータスを設定している場合は、そのステータスに遷移すると再度承認が行われます。承認が必要なステータスになる前に承認フローの設定を行ってください。

注意事項注意事項

  • 承認ステップはスキップすることはできません。