次世代プロジェクトで利用可能なワークフロー ルール

次世代プロジェクトでワークフロー ルールを追加または削除する

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問



robotsnoindex



descriptionリクエスト タイプのワークフローでアクションを自動化する方法について、ルールの説明と例をご覧ください。このリファレンスは、サービス チームのプロセスを効率化するのに役立ちます。

This page describes each of the workflow rules you can add to your team-managed projects and gives an example of why you might want to use one. Learn how to add a rule to your team-managed project's workflow.

リクエストを誰かに割り当てる

このルールを設定すると、適切なエージェントが適切なタイミングで適切な課題に取り組むようにすることができます。これにより、ワークフローの 1 つのステージが完了した後に手動でトリアージを行ってエージェントを割り当てる必要がなくなります。

ステータスを変更したときに、Jira Service Management でリクエストの担当者を自動的に変更できます。

  1. [For transition] ドロップダウンを使用して、リクエストの担当者フィールドを更新するトランジションを Jira Service Management に伝えます。

  2. [担当者] ドロップダウンで、リクエストを割り当てる担当者を指定します。

リクエストを次のユーザーに割り当てることができます。

  • 現在のユーザーまたはリクエストのステータスの更新者。

  • なし。リクエストは割り当てられません

  • サービス プロジェクトの特定のユーザー

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

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

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

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

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

Restrict to when a request is a specific value

このルールでは、特定のトランジションの使用をユーザーに許可する前に、リクエストのフィールドの値を確認します。この仮想チェックにより、ワークフローでリクエストが利用できるパスを、リクエストで提示される情報に基づいて絞り込むことで、サービス チームが課題を解決しやすくなります。この機能を使用することで、新しいリクエスト タイプやワークフローを作成することなく、類似したリクエストのベスト プラクティスを適用できます。

特定のトランジションの使用をユーザーに許可する前にリクエストのフィールドの値を確認するには、次の手順を実行します。

  1. [トランジション] ドロップダウンを使用して、フィールドの値を確認するトランジションを Jira Service Management に伝えます。

  2. [このフィールドに対応] ドロップダウンで、確認したい値のフィールドを選択します。

  3. 任意で [以下として値を確認] ドロップダウンを調整して、フィールドの評価方法を変更します (詳細は後述)。

  4. [以下の場合はチェック] ドロップダウンを使用して、Jira Service Management でのフィールドの値の比較方法を選択します (詳細は後述)。

  5. 比較したい値を [この値] フィールドに追加します。

  6. [追加] をクリックします。

以下として値を確認

この機能は、古い構成の Jira や、このワークフロー ルールの高度な使い方をサポートするために含まれています。このオプションの初期設定を変更することはお勧めしません。

Jira Service Management allows you to evaluate the value entered in a field in a number of different ways. This can be useful when comparing numerals entered as text in a short text field to see if they are equal to an integer, for example.

確認するフィールドの種類に応じて、内容を次のように評価できます。

  • 数字 - 小数を含む、-1 兆から 1 兆 (100000000000000) までの任意の正または負の数。次の点にご注意ください。

    • このフィールドでは、分数は使用できません。

    • このフィールドでは、小数点のみを区切り文字として使用できます。それ以外の記号 (たとえば桁を示すカンマなど) はルール違反となります。

    • Jira は小数点以下 3 桁以降を四捨五入します。たとえば、5.555555 は四捨五入されて 5.6 となります。 

    • 値の大きな数字は指数表記で入力できます。たとえば、数値 5000 は「5e3」と入力できます。

  • 選択 - ドロップダウン フィールドやチェックボックス フィールドに構成された利用可能なオプションや、ユーザー フィールドのユーザー ID が含まれます。

  • タイム スタンプ - 日付と、タイム スタンプ フィールドの場合は時刻が含まれます。日付や時刻を正確に選択するためにカレンダーや時計が表示されるため、管理者が特定の書式を覚えておく必要はありません。

  • テキスト - 特殊文字や非ラテン文字を含む文字列として評価されます。

以下の場合はチェック

ここで行う選択は、Jira Service Management に対し、確認するフィールドの内容をどのように評価するかを指定します。たとえば、数値フィールドの値が指定した値よりも大きいか小さいかを確認することができます。

確認するフィールドの種類に応じて、以下の演算子を使用してフィールドの値を比較できます。

  • contains - この演算子は、選択フィールドまたはテキスト フィールドの形式で評価する場合に、指定された文字列または選択肢がフィールド内に存在するかどうかを確認します。

  • doesn’t contain - この演算子は、選択フィールドまたはテキスト フィールドの形式で評価する場合に、指定された文字列または選択肢がフィールドに存在しないことを確認します。

  • が次に等しくない - この演算子は、評価するフィールドが特定のパターンに正確に一致しないかどうかを確認します。

  • が次に等しい - この演算子は、評価するフィールドが特定のパターンに正確に一致するかどうかを確認します。テキスト フィールドの場合、評価では大文字と小文字が区別され、正確な書式設定が考慮されます。

  • is after - この演算子は、日付およびタイム スタンプ フィールドで、指定した値の後に発生したタイム スタンプを時系列で検索します。

  • is before - この演算子は、日付およびタイム スタンプ フィールドで、指定した値の前に発生したタイム スタンプを時系列で検索します。

  • is or is after - この演算子は、日付およびタイム スタンプ フィールドで、指定した値と正確に同時またはその後に発生したタイム スタンプを時系列で検索します。

  • is or is before - この演算子は、日付およびタイム スタンプ フィールドで、指定した値と正確に同時またはその前に発生したタイム スタンプを時系列で検索します。

  • is greater than - この演算子は数値フィールドで、ルールで指定された内容よりも大きな値を検索します。

  • is greater than or equal to - この演算子は数値フィールドで、ルールで指定された内容と正確に等しいか、それより大きな値を検索します。

  • is less than - この演算子は数値フィールドで、ルールで指定された内容よりも小さな値を検索します。

  • is less than or equal to - この演算子は数値フィールドで、ルールで指定された内容と正確に等しいかそれより小さな値を検索します。

ご利用のサービス プロジェクトで、組織のソフトウェアを使用してユーザーからバグ レポートを収集している場合、課題に対応する必要がある旨をソフトウェア チームに通知する前にバグを確認するための、ベスト プラクティスを適用できます。

この例では、"Verified" というバグ報告リクエスト タイプにチェックボックス フィールドを作成できます。次に、[リクエスト フィールドを確認] を設定することで、バグの解決プロセスを開始する前に、"Verified" フィールドをエージェントが選択したかどうかを確かめることができます。

Jira Service Management の既定のバグ報告ワークフローは以下のようになっています。

課題の作業を開始する前にバグ レポートが確認されるようにするには、次の手順を実行します。

  1. 外部サービス プロジェクトで、バグを報告リクエスト タイプを編集します。外部サービス プロジェクトについて詳しく説明します

  2. チェックボックス フィールドを作成し、"Verification" という名前を付けます。

  3. このフィールドに、"Verified" と "Rejected" の 2 つのオプションを追加します。

  4. Click Save changes.

  5. [ワークフローを編集] を選択します。ワークフロー エディタが表示されます。

  6. [Start work] トランジションを選択します。

  7. ツールバーで [ルール] を選択します。

  8. [リクエスト フィールドを確認] ルールを選択し、[選択] をクリックします。

  9. [このフィールドに対応] ドロップダウンで、新しい "Verification" フィールドを選択します。

  10. [以下として値を確認] ドロップダウンの設定は、既定の [選択] のままにします。

  11. [以下の場合はチェック] ドロップダウンで、演算子 "が次に等しい" を選択します。

  12. [この値] フィールドで "Verified" オプションを選択します。

これでエージェントは、リクエストの "Verified" チェックボックスを選択するまで、"Work in progress" ステータスへのトランジションを表示したり実行したりすることができなくなりました。

このプロセスを [Set as done] トランジションでも繰り返し、"Verification" フィールドで "Rejected" オプションが選択されていることを確認するようにします。これにより、ワークフローには、バグ報告への対応を実行する前に、製品でバグを確認するためのベスト プラクティスが適用されます。

Restrict to when a request has been through a status

このルールは、リクエストがチームのワークフローで 1 つ以上の必須ステージを経由していることを確認するのに役立ちます。ワークフローの自動確認を実施し、リクエストがプロセスの手順をスキップしないようにします。または、まったく逆に、リクエストが特定のステータスを通過していないことを確認するようにセットアップすることもできます。

特定のトランジションを許可する前に、課題が特定のステータスにあったことを確認するには、次の手順を実行します。

  1. [トランジション] ドロップダウンを使用して、前のステータスを確認するトランジションを Jira Service Management に伝えます。

  2. [リクエストが次のステータスを経ていることを確認する] ドロップダウンで、確認したいステータスを選択します。

次のオプションを選択することもできます。

リクエストの現在のステータスを含める

既定では、トランジションを許可するかどうかを評価する際、このワークフロー ルールは以前のステータスのみを確認します。現在のステータスも評価したい場合は、[リクエストの現在のステータスを含める] チェックボックスを選択します。トランジションがステータスをリセットして未変更と表示されてしまう、トランジションのループを防ぐのに役立ちます。これによってワークフローで課題を引き続き進めることができます。

このルールを取り消す

トランジションを許可する前に、リクエストが特定のステータスを通過していないことを確認するよう、このワークフロー ルールの動作を変更できます。これにより、"却下" ステータスになった購入リクエストや機能リクエストがキューに戻されないようにできます。

リクエストの最新のステータスのみを考慮する

既定では、このワークフロー ルールはプロジェクトでのリクエストの作成以降の履歴全体を確認します。このオプションを選択すると、ルールはリクエストの現在のステータスの直前に設定されたステータスのみを評価します。場合によっては、これが現在のステータスと同じ可能性があります。また、直近のステータスがリクエストの現在のステータスと異なることを評価するため、[ループが設定されたトランジションのステータス更新を無視する] を選択することをおすすめします。

ループが設定されたトランジションのステータス更新を無視する

一部のプロジェクトはトランジションを使用して、自動化ルールや接続されたアプリのアクションをトリガーします。これらのトランジションは通常、リクエストのステータスを現在のリクエスト ステータスにリセットします。[リクエストの最新のステータスのみを考慮する] を選択した場合、最新のステータスが現在のステータスと同じである場合があります。直近のステータスがリクエストの現在のステータスと異なることを評価するため、[ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。

ソフトウェア チームと連携するサービス チームでは、バグやその他の課題の修正が品質保証エンジニアによって検証されるのを待機してから、顧客リクエストをクローズする必要がある場合があります。たとえば、サービス チームはサービス プロジェクトからバグ レポートを収集およびリンクします。その後、サービス チームは開発チームとやり取りし、これらの課題を解決します。この場合、ワークフロー ステータスを使用して、品質保証エンジニアがレビューを行うまで、チームがチケットをクローズしないようにすることができます。

例えば、バグ レポート リクエストで、カスタマー サービス チームのステータスが次のようになる場合があります。

作業前 → 開発待ち →レビュー中 → 完了

カスタマー リクエストをプロジェクトで "完了" に設定する前に、ワークフローのステータスを品質ゲートとして使用できます。ワークフローの最後のトランジションに [リクエストがステータスを経ていることを確認する] ルールを追加すると、タスクを完了としてマークする前に品質保証エンジニアが確実にレビューを行うようにすることができます。

  1. [リクエストがステータスを経ていることを確認する] ルールを、"完了" ステータスにつながる "すべてのステータス" トランジションに追加します。

  2. [リクエストが次のステータスを経ていることを確認する] ドロップダウンで、"レビュー中" ステータスを選択します。

  3. [このリクエストの現在のステータスを含める] オプションを選択します。

  4. [リクエストの最新のステータスのみを考慮する] オプションを選択します

  5. [ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。

これで、最新のステータスが "レビュー中" の場合にのみ "完了" にトランジションできるようになりました。

Jira Service Management を使用したバグ レポートの収集の詳細をご覧ください

Remind people to update fields

This rule is only available in team-managed projects.

このルールによって、エージェントがリクエストのステータスの変更時に関連情報を把握できるようにします。トランジションのルールを作成すると、その段階でリクエストの解決に関連する空のフィールドを記入するようにエージェントに要求することができます。このルールにより、チームで特定のフィールドに入力する必要性を覚えておくための負荷を軽減することができます。これにより、カスタマーを支援するための重要な作業に注力することができます。

Jira Service Management では、チームに各トランジションで最大 40 個のフィールドを更新または確認するように要求できます。

  1. [For transition] ドロップダウンを使用して、チームにプロンプトを表示するタイミングを Jira Service Management に伝えます。

  2. 更新または確認してほしいフィールドを選択します。

カスタム フィールドを含む、サービス プロジェクトに追加したほとんどのテキスト、数値、ラベル、日付、または時刻フィールドを入力するように要求することができます。カスタム フィールドの詳細をご確認ください

更新するフィールドと理由を示すパーソナライズされたメッセージを含めることができます。

ほとんどのサービス チームは、チケットを "完了" とマークする際にリクエストの解決方法を設定します。エージェントがチケットを解決した方法をフィールドで取得している場合、この情報をレポートで使用できます。これによって、サービス チームがカスタマーとどのようなやり取りをしたのかを詳細に確認できます。カスタマーからの連絡がなくなったためにエージェントがチケットをクローズしているかどうかを確認できます。あるいは、あるチャンネルが別のチャンネルよりもリクエストの完了に成功していることがわかります。

たとえば、リクエスト タイプに "解決状況" というカスタム ドロップダウン フィールドを作成します。このフィールドには、"修正済み"、"キャンセル済み"、"中止" などのオプションがあります。

次に、リクエスト タイプのワークフローをセットアップして、エージェントがチケットを [完了] ステータスに移動する際にリクエストの解決方法を取得するようにします。そのためには、[空のフィールドを更新するようにユーザーにリマインド] ルールをトランジションに追加し、[解決状況] フィールドを選択します。Jira Service Management はチケットを完了とマークする際に解決状況を追加するようにチームに要求します。

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

This rule enforces who can move requests using certain transitions.

You can restrict who can move a request to:

  • The request’s assignee.

  • The request’s reporter.

  • A user of your choice.

  • People in a specific role.

  • People in a specific group.
  • People with specific permissions.

It’s handy for service teams that must enforce compliant or industry-standard ways of working. The rule makes sure the right person reviews and moves requests along their workflow.

Jira Service Management ではリクエスト タイプのワークフローで任意のトランジションを制限できます。

  1. [For transition] ドロップダウンを使用して、制限したい経路を Jira Service Management に伝えます。

  2. トランジションの使用を許可される個人ユーザーまたはプロジェクト ロールを選択します。最大 20 のユーザーまたはロールを選択できます。

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

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

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

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

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

  4. この新しいトランジションに "Restrict who can move a request" ルールを追加して、マネージャーまたはチーム リードに制限します。

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

Validate that people have a specific permission

This rule looks at what permissions someone has before they’re allowed to use a specific transition. This check helps your team ensure only the right people can move a request at the right time. Use this rule to secure your workflow based on people’s Jira permissions.

A team with a basic workflow might have these statuses in their workflow:

StartTo do → In progress → Done

You can use this rule to validate people have a specific permission by:

  • Only allowing people with the Create issues permission to move a request from StartTo do. This ensures that only the right people can create work for your team.

  • Only allowing people with the Assign issues permission to move a request from To doIn progress. This ensures that whoever starts working on a request can assign it to someone.

  • Only allowing people with the Close issues permission to move a request from In progressDone. This ensures that people aren’t able to resolve a request without being allowed to.

Copy the value of one field to another

Just like the Update a request field rule, this one also helps ensure your work is updated in the right places at the right time by reducing data entry errors. The key difference is that this rule updates a field based on another field.

You can either copy the value of a field from:

  • within the request itself, which copies a field from a request to another field on the same request.

  • the parent request, which copies from the request’s parent to itself. This option only works if the request is the child of another request e.g. copying a request from an epic (parent) to a story (child), or from a story (parent) to a subtask (child).

When we’ll skip this rule

The information you configure this rule with may not apply to all request types that share the workflow. So we’ll skip this rule when:

  • it’s on a request that doesn’t have both your selected fields (in Copy from this field and To this field).

  • it’s configured to copy from the parent request and the request doesn’t have a parent.

Don’t worry, this rule being skipped doesn’t mean you’ve done something wrong, or that there’ll be a bug. You’ll be able to go on with your work. It just means there won’t be any fields copied or updated.

How fields are copied

There are three ways a field is copied to another:

  • Append: The field’s value is added to the destination field’s value.

  • Prepend: The field’s value is added to the start of the destination field’s value.

  • Replace: The field’s value replaces the destination field’s value.

Here’s a list of compatible field types and how they’re copied:

フィールド タイプ

Can be copied to

Is copied by

Text

Text

要約

説明

Append

日付

日付

Replace

ラベル

ラベル

Append

数値

数値

Replace

チェックボックス

チェックボックス

Replace

Single select

Single select of the same type e.g. group picker → group picker.

Replace

複数選択


Multi select of the same type. e.g. version picker → version picker.

Replace

User picker (single user)

User picker (single user)

Replace

User picker (multiple users)

Append

User picker (multiple users)

User picker (multiple users)

Replace

担当者

担当者

報告者

User picker (single user)

User picker (multiple users)

Replace

添付ファイル

添付ファイル

Append

リクエスト フィールドを更新

このルールを設定すると、リクエストに適切なタイミングで適切な情報を取り込むようにすることができます。これにより、データの入力エラーを減らし、一貫性を向上させることができます。サービス プロジェクトの内部フィールドに特に便利です。

Jira Service Management では、課題の列間での移動またはステータスの変更時に、特定のフィールドを自動的に変更できます。

  1. [For transition] ドロップダウンを使用して、特定のフィールドを更新するステータスを Jira Service Management に伝えます。

  2. 自動更新するフィールドを選択します。

テキスト、数値、ラベル、日付、または期間フィールドやカスタム フィールドなど、プロジェクトに追加したほとんどのフィールドを更新できます。カスタム フィールドの詳細をご確認ください

挙動には次の違いがあります。

  • ルールを使用してテキスト フィールドを更新すると、Jira Service Management は目的のテキストをフィールド内の既存のテキストに追加します。フィールド内の既存のテキストの置き換えは行いません。

  • 時間または日付フィールドを更新すると、Jira Service Management はリクエストのステータス変更時の日付とタイムスタンプ (またはこのいずれか) でフィールド内のすべての要素を置き換えます。静的な時間または日付を指定することはできません。

Unknown custom field type

When updating a custom field of a type unknown to the workflow editor, make sure you enter a value that matches the custom field's type. Otherwise, the rule might not work.

You can use these:

  • %%CURRENT_USER%%, which will be replaced with the user who transitioned the request.
  • %%CURRENT_DATETIME%%, which be replaced with the date and time of the transition.
  • For Select List (cascading) fields, you can either use the value or the id of the option to be selected.

Custom date and time formats

If you’ve set up a custom date and time format and want to configure this rule to update a date and time field, you must enter your desired in the correct format. If this is the case, you’ll see a text field with instructions on how to fill it instead of a date picker field.

For example, you might see a text field that says to enter a date in the “dd/MMMM/yyyy h:mm a” format. One date you could enter would be “15/July/1968 9:30 PM”. To learn more about these formats, check out Java SimpleDateFormat.

To change your date and time formats, you can configure the look and feel of Jira. Learn more about configuring the look and feel of Jira.

Last modified on Mar 1, 2024

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.