チーム管理対象プロジェクトで利用可能なワークフロー ルール

このページでは、チーム管理対象プロジェクトに追加できる各ワークフロー ルールについて説明して、それらの使用例を紹介します。

Read about how add a rule to your team-managed project's workflow

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

このルールを設定すると、適切なエージェントが適切なタイミングで適切な課題に取り組むようにすることができます。これにより、ワークフローの 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. Nominate the person who you want to assign the request to in the Assign to dropdown.

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

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

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

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

例

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

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

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

• Navigate to the request type settings for IT help and edit its workflow.

• Select the first transition in the workflow (the Create work item transition from Start to Waiting for support).

• Add the Assign a request to someone rule to automatically assign these requests to your access specialist. Now, when an IT help request is created, your IT help specialist will be assigned the ticket automatically, skipping the need to triage your requests manually.

• Repeat this for each type of request, assigning them to the correct subject matter expert on your service team, and you’ll never have to triage requests again.

Or,

• Edit your workflow to change the assignee when requests are moved into the Escalated status.

• You can set a rule to automatically assign these requests to a senior service agent or manager and they’ll be notified of particularly difficult or high-impact requests. Service agents can continue to work on other requests in their queue, safely knowing that the trickier requests are in good hands.

リクエストが特定の値になっている場合に制限する

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

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

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. [追加] を選択します。

以下として値を確認

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.

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

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

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

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

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

  • 値の大きな数字には指数表記を使用できます。たとえば、数値 5000 は「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.

以下の場合はチェック

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.

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

• 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

例

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

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.

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

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

2. Create a Checkbox field, named Verification.

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

4. [変更を保存] を選択します。

5. Select Edit workflow. The workflow editor appears.

6. Select the Start work transition.

7. From the toolbar, select Rule.

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.

リクエストがステータスを経ている場合に制限する

This rule helps ensure that requests go through one or more required stages in your team’s workflow. It lets you enforce automated checks in your workflow, and prevents requests from skipping steps in your process. Or, the rule can be set up to do the exact opposite – check that a request hasn’t been through a particular status.

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

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

2. Select the status you want to check for in the Check that the request has been through dropdown.

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

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

By default, this workflow rule only looks at prior statuses when evaluating whether to allow a transition. If you want to also evaluate the current status, select the Include the request’s current status checkbox. This can help prevent looping transitions, where a transition resets the status and it appears unchanged. It keep work items moving down your workflow.

このルールを取り消す

You can change the behavior of this workflow rule to check that a request hasn’t been through a particular status before allowing the transition. This can enforce that purchase requests or feature requests that have been in a “rejected” status don’t make their way back into your queue.

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

By default, this workflow rule checks the entire history of a request from its creation in the project. Selecting this option forces the rule to only evaluate the status set just prior to the request’s current status. In some cases, this may be the same as the current status. We recommend also selecting the Ignore status updates from looped transitions option to ensure the rule evaluates the most recent different status from the request’s current status.

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

Some projects use transitions to trigger automation rules or actions in connected apps. These transitions usually reset the request’s status to the current request status. If you’ve selected to Only consider the request’s most recent status, the most recent status may be the same as the current status. Selecting the Ignore status updates from looped transitions option forces the rule to evaluate the most recent different status from the request’s current status.

例

Service teams that collaborate with software teams may need to wait for verification that a bug or other work item 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 work items 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.

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

Open → Pending development → In review → Done

You can use a workflow status as a quality gate before allowing the customer request to be set to “Done” in your project. Add the Check that a work item has been through a status rule to the final transition in your workflow, and you can ensure that work has been reviewed properly by your quality assurance engineer before marking the task as complete:

1. Add a Check that a work item has been through a status rule to the “Any status” transition leading to your “Done” status.

2. In the Check that the work item has been through dropdown, select the “In review” status.

3. Select the Include the work item’s current status option.

4. Select the Only consider the work item’s most recent status option.

5. Select the Ignore status updates from looped transitions option.

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

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

This rule makes sure agents capture relevant information when changing a request's status. When you create the rule on any transition, you can prompt agents to complete empty fields that are relevant to that stage in resolving the request. The rule removes a burden on your teams to remember to fill in specific fields until they matter. It keeps them focused on the important work of helping your customers.

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. More about custom fields

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

例

Most service teams categorize how they resolve a request when they mark a ticket as "done". If you use a field to capture how agents resolve tickets, you can use this information in reports. This can bring you insights into how your service team interacts with their customers. You can see if agents are closing tickets because they've lost touch with customers. Or, you might see that one channel is more successful in completing requests than another.

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

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.

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

このルールでは、特定のトランジションを使用してリクエストを移動できるユーザーを強制します。

リクエストを移動できるユーザーを次のように制限できます。

• リクエストの担当者。

• リクエストの報告者。

• 自分が選択したユーザー

• 特定のロールを持つユーザー

• 特定のグループに所属するユーザー

• 特定の権限を持つユーザー

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

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

ユーザーが特定の権限を持っていることを確認する

このルールでは、特定のトランジションの使用をユーザーに許可する前に、ユーザーが持つ権限を確認します。この確認は、チームにとって適切なユーザーだけが適切なタイミングでリクエストを移動できるようにするのに役立ちます。このルールを使用すると、ユーザーの Jira 権限に基づいてワークフローを保護できます。

例

基本的なワークフローを使用するチームでは、ワークフローに以下のステータスがあります。

Start → To do → In progress → Done

このルールを使用すると、ユーザーが特定の権限を持っていることを次の方法で確認できます。

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

• Only allowing people with the Assign work items permission to move a request from To do → In progress. This ensures that whoever starts working on a request can assign it to someone.

• Only allowing people with the Close work items permission to move a request from In progress → Done. This ensures that people aren’t able to resolve a request without being allowed to.

あるフィールドの値を別のフィールドにコピーする

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.

フィールドの値は次の場所からコピーできます。

• 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).

このルールがスキップされる場合

このルールを設定した情報は、ワークフローを共有するすべてのリクエスト タイプには適用されない場合があります。そのため、次の場合はこのルールがスキップされます。

• 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.

このルールがスキップされたからといって、何か間違ったことをしたわけでも、バグがあるということでもないため心配は無用です。そのまま作業を続けても問題ありません。ルールがスキップされても、どのフィールドもコピーも更新もされないだけです。

フィールドのコピー方法

次の 3 通りの方法でフィールドを別のフィールドにコピーできます。

• 追加: フィールドの値がコピー先フィールドの値に追加されます。

• 先頭に追加: フィールドの値がコピー先フィールドの値の先頭に追加されます。

• 置換: フィールドの値でコピー先フィールドの値が置換されます。

コピーに対応しているフィールド タイプとそのコピー方法のリストは次のとおりです。

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

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

Jira Service Management can update certain fields for you automatically when you move work items 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. 自動更新するフィールドを選択します。

You can update most text, number, label, date, or time fields you’ve added to your project, including custom fields. Read more about custom fields

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

• 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.

不明なカスタム フィールド タイプ

不明なタイプのカスタム フィールドをワークフロー エディターに更新するときは、必ずカスタム フィールドのタイプと一致する値をご入力ください。そうしないとルールが機能しない場合があります。

次を使用できます。

• %%CURRENT_USER%%、リクエストをトランジションしたユーザーに置き換えられます。

• %%CURRENT_DATETIME%%、トランジションの日時に置き換えられます。

• For Select List (cascading) fields, you can either use the value or the id of the option to be selected.

カスタムの日時形式

カスタムの日時形式をセットアップして、日時のフィールドを更新するようにこのルールを設定する場合は、正しい形式で入力する必要があります。その場合は、日付ピッカー フィールドの代わりに、入力方法の説明が記載されたテキスト フィールドが表示されます。

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.