• 製品
  • 使用を開始する
  • 関連ドキュメント
  • リソース

Jira Automation のドキュメントが移動しました。

以前「Jira のプロセスとワークフローを自動化する」セクションにあった Jira Cloud Automation に関連するすべてのコンテンツ、新しい Cloud Automation のドキュメントに移動しました。

Cloud の自動化のドキュメントに移動する | これを行った理由

ワークフロー ルールのさまざまなタイプとは

このページでは使用できる各ワークフロー ルールのタイプについて説明して、それらを使用する理由の例を紹介します。ワークフロー ルールの詳細についてご確認ください。

ワークフロー ルールの 3 つのタイプは、次の順序で発生します。

  1. トランジションを制限: ユーザーがリクエストをトランジションしようとする前に発生します。

  2. 詳細を検証: ユーザーがリクエストをトランジションしようとした時点で発生します。

  3. アクションを実行: ユーザーがリクエストをトランジションした後に発生します。

トランジションを制限

このルール タイプでは、特定のユーザーまたは条件に該当しない全ユーザーからのトランジションが非表示になります。このルールをトランジションに追加すると、条件に該当しない限りリクエストのトランジションがユーザーに表示されなくなります。詳細を検証ルール タイプとは異なり、このタイプではリクエストを修正して再度トランジションはできません (トランジションは表示もされません)。これはセキュリティ上とても有用ですが、トランジション前にやるべきことを誰かにリマインドするだけの場合には役に立ちません。

ほとんどのトランジションの制限ルールには「制限」が含まれます。

例: リクエストを移動できるユーザーを制限

一部のサービス チームには、受信したリクエストをトリアージして最適なエージェントに振り分けるマネージャーがいます。彼らはリクエストを誰かに割り当てて作業を依頼する前に、リクエストの有効性を検証したり、プロジェクト内の他の既知のリクエストにリンクさせたりする場合があります。

この場合、マネージャーやチーム リードがリクエストを適切にトリアージする前にリクエストがワークフローを移動することのないよう、ルールを使用できます。この操作を行うには、次の手順を実行します。

  1. ワークフローで "トリアージ" ステータスを作成します。

  2. 開始ステータスを変更し、リクエストを "トリアージ" ステータスに移動させます。

  3. リクエストの残りのワークフローへの発信トランジション ("チームに送信") を作成します。

  4. [リクエストを移動できるユーザーを制限] ルールをこの新しいトランジションに追加して、ユーザーをマネージャーまたはチーム リードに制限します。

Jira Service Management により、新しく作成されたリクエストをプロジェクトの他のメンバーが進められないようにすることができます。

詳細を検証

このルール タイプではリクエストのトランジション時に詳細が正しいことを確認して、正しくない場合はトランジションを停止します。正しくない情報がある場合、リクエストをトランジションしているユーザーはその情報を修正するように求められます。

このタイプとトランジションを制限には微妙な違いがあります。トランジションを制限では特定の条件を満たさないトランジションが非表示になりますが、詳細を検証ではトランジションが非表示になりません。ユーザーはトランジションを参照して選択できますが、詳細が条件を満たさない場合はリクエストの移動を完了できません。そのため、詳細を検証ルールはユーザーがリクエストをトランジションしているその時点で発生します。そのタイミングは、トランジションが選択されたでトランジションが発生するです。

ほとんどの詳細を検証ルールには「検証」が含まれます。例外は次のとおりです。

  • 画面を表示する (企業管理対象プロジェクト)

  • フィールドを更新するようにユーザーをリマインドする (チーム管理対象プロジェクト)

これは他の詳細を検証ルールの前に発生して、リクエストをトランジションしているユーザーなら誰でもリクエストに情報を追加できるようにします。

アクションを実行

このルール タイプでは、リクエストのトランジション後に何らかのアクションを自動で実行します。手動でやる必要のあったタスクを実行する時間の節約に役立ちます。トランジションの成功に条件を強制するトランジションを制約詳細を検証のルールとは異なり、アクションを実行ルールはリクエストをトランジションできるユーザーやタイミングを限定しません。このルールの目的はスピーディな作業をサポートすることだけです。

例: リクエストを割り当てる

サービス チームの特定のメンバーがサービスの特定の分野の専門知識を持っていたり、特定のリクエストの実施を明示的に担当している場合があります。たとえば、サービス エージェントがソフトウェア ツールまたはメッセージ リストへのアクセスの提供を担当し、シニア サービス エージェントが困難なリクエストや影響の大きいリクエストのエスカレート方法の評価を担当する場合があります。

特定のリクエスト タイプを、そのタイプのリクエストを担当しているユーザーに自動的に割り当てるよう、リクエスト ワークフローを設定できます。

上記の例では、次のようになる場合があります。

  • IT help のリクエスト タイプ設定に移動して、ワークフローを編集します。ワークフローの最初のトランジションを選択 ("Create issue" から "Waiting for support" への "Create issue" トランジション) します。"リクエストを割り当てる" ルールを追加して、これらのリクエストをアクセス担当者に自動的に割り当てます。これで、IT ヘルプ リクエストが作成されると、チケットが IT ヘルプ担当者に自動的に割り当てられ、リクエストの手動トリアージは不要になります。リクエストの各タイプに対してこの手順を繰り返し、サービス チームの適切な専門家に割り当てることで、リクエストのトリアージは不要になります。

  • リクエストが [エスカレート済み] ステータスに移動すると担当者を変更するようにワークフローを編集します。これらのリクエストをシニア サービス エージェントやマネージャーに自動的に割り当てるようなルールを設定し、困難なリクエストや影響が大きいリクエストの場合にこれらのユーザーに通知できます。

その他のヘルプ