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

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

このページの内容

お困りですか?

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

コミュニティに質問

robotsnoindex

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

このページでは、次世代プロジェクトに追加できる各ワークフロー ルールについて説明し、それらの使用例を提供します。次世代プロジェクトのワークフローにルールを追加する方法をご覧ください

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

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

Jira Service Management can change the request's assignee automatically when you change its status:

  1. Use the For transition dropdown to tell Jira Service Management the transition that updates the request's assignee field.

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

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

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

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

  • A specific person in your service project

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

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

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

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

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

Check a request's field

This rule looks at the value of a request’s field before allowing someone to use a specific transition. This virtual check can help your service team better resolve issues by narrowing down the request’s available paths in your workflow based on the information present on the request. You can use it to enforce best practices for similar requests without having to create a new request type and workflow.

To review the value of a request’s field before allowing someone to use a specific transition:

  1. Use the For transition dropdown to tell Jira Service Management the transition that checks for the field’s value.

  2. Select the field whose value you want to check in the For this field dropdown.

  3. Optionally, adjust the Review its value as dropdown to change how you want to evaluate the field (see below for details).

  4. Use the Check if it dropdown to select how Jira Service Management should compare the field’s value (see below for details).

  5. Add the value you want to compare against to the This value field.

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

Review its value as

This capability is included to support older configurations of Jira and advanced uses of this workflow rule. We don’t recommend changing this option from its default.

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 equals to an integer, for example.

Depending on the type of field you’re checking, you can evaluate its contents as:

  • a number - any positive or negative number, including decimal values, between -1 trillion and 1 trillion (100000000000000). Keep in mind:

    • The field will not accept a number expressed as a fraction.

    • The field only accepts one separator–the decimal. Other notation (for example, commas to denote places) will break the rule.

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

    • You may enter large numbers using scientific notation. For example, the number 5000 can be entered as 5e3.

  • a selection - including the available options configured in the field for dropdown and checkbox fields, or user IDs in people fields.

  • a time stamp - including a date and, for time stamp fields, a time. We provide a calendar and clock to accurately select the date and time, so you don’t need to know specific formatting.

  • text - evaluated as a string, including special and non-Latin characters.

Check if it

The selection you make here tells Jira Service Management how they should evaluate the contents of the field you’re checking. For example, you can check if the value of a number field is greater than or less than a desired value.

Depending on the type of field you’re checking, you can compare the field’s value with these operators:

  • contains - for evaluating fields as either a selection or text, this operator looks to see if the desired string or selection is present in the field

  • doesn’t contain - for evaluating fields as either a selection or text, this operator looks to see that the desired string or selection is absent from the field

  • doesn’t equal - this operator looks to see if the field being evaluated doesn’t exactly match a specific pattern

  • equals - this operator looks to see if the field being evaluated does exactly match a specific pattern. For text, the evaluation is case sensitive and considers exact formatting.

  • is after - for date and time stamp fields, this operator looks for time stamps that occur after the desired value chronologically

  • is before - for date and time stamp fields, this operator looks for time stamps that occur before the desired value chronologically

  • is or is after - for date and time stamp fields, this operator looks for time stamps that occur at exactly the same time or after the desired value chronologically

  • is or is before - for date and time stamp fields, this operator looks for time stamps that occur at exactly the same time or before the desired value chronologically

  • is greater than - for number fields, this operator looks for values that are larger than what’s specified in the rule

  • is greater than or equal to - for number fields, this operator looks for values that are either exactly equal to or larger than what’s specified in the rule

  • is less than - for number fields, this operator looks for values that are smaller than what’s specified in the rule

  • is less than or equal to - for number fields, this operator looks for values that are either exactly equal to or smaller than what’s specified in the rule

If your service project collects bug reports from people using your organization’s software, you can enforce a best practice for verifying the bug before notifying your software team that they need to address the issue.

In this example, you can create a checkbox field on your bug report request type called Verified. Then you can set up the Check a request’s field to check if the Verified field has been checked by an agent before allowing the bug resolution process to begin.

Jira Service Management’s default bug report workflow looks like this:

To ensure that the bug report is verified before starting work on the issue:

  1. In your external service project, edit the Report a bug request type. Learn more about external service projects.

  2. Create a Checkbox field, named Verification.

  3. Add two options to this field: Verified and Rejected.

  4. [変更を保存] をクリックします。

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

  6. Select the Start work transition.

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

  8. Choose the Check a request’s field rule and click Select.

  9. In the For this field dropdown, select your new Verification field.

  10. Leave the Review its value as dropdown set to its default a selection.

  11. In the Check if it dropdown, select the equals operator.

  12. In the This value field, select the Verified option.

Now, your agents won’t see and can’t transition a bug report to the Work in progress status without selecting the Verified checkbox on their requests.

Repeat this process for the Set as done transition, checking that the Rejected option is ticked in your Verification field, and your workflow will enforce a best practice for checking bug in your products before acting on bug reports.

リクエストがステータスを通過したことを確認する

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

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

  1. Use the For transition dropdown to tell Jira Service Management the transition that check previous statuses.

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

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

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

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

このルールを取り消す

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

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

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

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

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

Service teams that collaborate with software teams may need to wait for verification that a bug or other issue has been fixed from a quality assurance engineer before closing a customer request. For example, your service team may collect and link bug reports from your service project. Your service team then communicates with your development team to get these issues resolved. In this case, you can use your workflow statuses to ensure your team doesn’t close a ticket until its been reviewed by a quality assurance engineer.

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

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

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

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

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

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

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

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

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

Learn more about using Jira Service Management to collect bug reports.

空のフィールドを更新するようにユーザーにリマインド

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

Jira Service Management can prompt your team to update or review up to 40 fields on each transition:

  1. Use the For transition dropdown to tell Jira Service Management when to prompt your team.

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

You can prompt them to complete most text, number, label, date, or time fields you’ve added to your service project, including custom fields. Learn more about custom fields.

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

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

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

Then, you can set up your request type's workflow to capture how agents resolved a request when then move the ticket into a “Done” status. To do so, add a Remind people to update empty fields rule to your transition, and choose your “Resolution” field. Jira Service Management will prompt your team to add a resolution when they mark a ticket as done.

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

このルールでは、特定のトランジションを使用してリクエストを移動できるユーザーを強制します。特定のプロジェクトのユーザーまたはロールにトランジションを制限します。標準準拠や業界標準の作業方法を強制する必要があるサービス チームに便利です。ルールにより、適切な人物がワークフローに沿ってリクエストのレビューと移動を実施できるようにします。

Jira Service Management can restrict any transition in a request type’s workflow:

  1. Use the For transition dropdown to tell Jira Service Management what pathway you want to restrict.

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

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

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

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

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

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

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

Jira Service Management prevents any other person in the project from moving newly-created requests forward.

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

This rule helps ensure that requests capture the right information at the right time. You can reduce data entry errors and increase consistency. There are particularly useful for internal fields in your service project.

Jira Service Management can update certain fields for you automatically when you move issues between columns or change their status:

  1. Use the For transition dropdown to tell Jira Service Management the status that updates a certain field.

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

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

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

  • When you update a text field using a rule, Jira Service Management adds the desired text to existing text in the field. It won’t replace any existing text in the field.

  • When you update a time or date field, Jira Service Management replaces anything in the field with the date and/or timestamp of when the request changed statuses. You can’t specify a static time or date.

最終更新日: 2021 年 2 月 23 日

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

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