Assign a work item to someone

This rule helps ensure that the right people address the right work items at the right time. It takes the manual work out of assigning a team member after a stage in the workflow is complete.  

Jira can change the work item's assignee automatically when you move a work item between columns or change its status:

1. Use the For transition dropdown to tell Jira the column or status that updates the work item's assignee field.
2. Nominate the person who you want to assign the work item to in the Assign to dropdown.

You can assign work items to:

• 報告者。通常は、課題の作成者。
• The current user, or the person updating the work item's status
• No one, making the work item unassigned
• プロジェクト内の特定のユーザー。

例

幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

作業前 → 設計中 → 開発中 → レビュー中 → 完了

You can create rules to assign work items to each discipline across the board:

• For work items moving to In design, assign to the team's designer. They then provide implementation details, specifications, and requirements.

• For work items moving to In development, assign to the team's feature lead. They then write the code or delegate to other developers in the team.

• For work items moving to In review, assign to the team's quality assurance champion. They then provide testing notes or build automated quality tests.

• For work items moving to Done, unassign the work item.

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

このルールを設定すると、適切なエージェントが適切なタイミングで適切な課題に取り組むようにすることができます。これにより、ワークフローの 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. [担当者] ドロップダウンで、リクエストを割り当てる担当者を指定します。

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

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

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

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

例

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

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

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

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

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

Restrict to when a work item is a specific value

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

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

1. Use the For transition dropdown to tell Jira Software 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 Software 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. Click Add.

以下として値を確認

Jira Software 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 は小数点以下 3 桁以降を四捨五入します。たとえば、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 Software 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

Restrict to when a request is a specific value

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 work items 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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

以下の場合はチェック

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

• 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 - この演算子は数値フィールドで、ルールで指定された内容と正確に等しいかそれより小さな値を検索します。

例

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 work item.

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

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

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

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 work item has been through a status

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

To check if a work item has been in a status before allowing a specific transition:

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

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

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

Include the work item’s current status

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 work item’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. Read more about looped transitions below.

このルールを取り消す

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

Only consider the work item’s most recent status

By default, this workflow rule checks the entire history of a work item from its creation in the project. Selecting this option forces the rule to only evaluate the status set just prior to the work item’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 work item’s current status.

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

Some projects use transitions to trigger notifications, automations in connected apps, or other actions. These transitions usually reset the work item’s status to the current work item status. If you’ve selected to Only consider the work item’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 status that’s different from the work item’s current status.

例

品質保証の例

ここでの目的は、作業が完了する前に品質管理を確実に通過させることです。このような場合、ワークフロー ステータスを使用して、顧客へのデプロイ前に品質保証エンジニアがチームの仕事を検討するよう、チームに実行させるようにします。

たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

やること→開発待ち→レビュー中→完了

You can use a workflow status as a quality gate before allowing work to be completed 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. [ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。

これで、作業はどのステータスでも自由に流れることができます。ただし、最新のステータスが「レビュー中」の場合にのみ「完了」にトランジションできます。

To add extra assurance, you may also add the Restrict who can move a work item rule to this transition, and restrict it to a “Quality assurance engineer” custom role. This way, only people in your “Quality assurance engineer” role can move the work item to done. Learn more about custom roles.

中断されたステータスの例

ソフトウェア チームは、定期的にプロジェクトに参加しているわけではない同僚と相談する必要がある場合があります。たとえば、フロントエンド タスクでは、ユーザー インターフェイスを構築する際に、設計者からのインプットが必要な場合があります。

This type of input isn’t regularly needed in your workflow, but you want to be able to see and check in on the work items that are waiting for your designer’s input.

この場合、「設計待ち」と呼ばれるこのような中断のステータスを作成できます。ワークフローは次のようになります。

You can use the Check that a work item has been through a status rule to ensure the work item goes back to where it came from before the interruption in your normal workflow:

1. 中断された状態用のステータスを作成し、すべてのステータスが新しいステータスに移行できるようにします。上の例では、中断状態を「設計待ち」と呼びます。

2. Create transitions from the interrupted status back to your main workflow. In the diagram above, the “Restart task” and “Back to in progress” transitions direct work items from our “Awaiting design” interrupted status back into the main workflow (TO DO → IN PROGRESS → DONE).

3. Add a Check that a work item has been through a status rule to allow the transition that puts the work item back where it came from. For example, if work items were interrupted while they were “In progress”:

   1. [移行の場合] ドロップダウンで、[処理中に戻る] トランジションを選択します。

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

4. Add a Check that a work item has been through a status rule to prevent the work item moving backward in your workflow. For example, if work items were interrupted while they were “In progress”, you can prevent them from moving back to “To do”:

   1. [移行の場合] ドロップダウンで、[タスクの再起動] トランジションを選択します。

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

   3. このルールを取り消すオプションを選択します。

Now, work items that are interrupted from your main flow and set to “Awaiting design” can only move the following ways:

• work items that move from “To do” to “Awaiting design” can only move back to “To do”.

• work items that move from “In progress” to “Awaiting design” can only move back to “In progress”.

Restrict to when a request has been through a status

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

To check if a work item has been in a status before allowing a specific transition:

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

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

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

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

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.

このルールを取り消す

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

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

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

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

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

例

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.

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

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

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. [ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。

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

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

Remind people to update fields

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

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. 更新または確認してほしいフィールドを選択します。

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

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

例

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

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

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.

Restrict who can move a work item

This rule helps ensure only the right people can move a work item at a particular point in your team’s process. You can reduce missed steps in your workflow and make sure your team’s work goes through all the people required.

You can restrict who can move a work item to:

• The work item’s assignee.

• The work item’s reporter.

• A user of your choice.

• People in a specific role.

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

例

Multi-discipline teams usually have different people working on a task at different stages in their process. For example, a small feature team may have these steps in their process:

作業前 → 設計中 → 開発中 → レビュー中 → 完了

The disciplines in the team may be mapped to roles:

• Designer.

• Software engineer.

• Quality assurance.

Learn more about managing project roles.

Using the rule, they can add these restrictions to make sure the right roles move their work items:

• For work items moving from In design, restrict who can move the work item to the role Designer.

• For work items moving from In development, restrict who can move the work item to the role Software engineer.

• For work items moving from In review, restrict who can move the work item to the role Quality assurance.

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

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

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 work item 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:

Start → To do → In progress → Done

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

• Only allowing people with the Create work items permission to move a work item 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 work item from To do → In progress. This ensures that whoever starts working on a work item can assign it to someone.

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

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:

Start → To do → In progress → Done

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

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

Copy the value of one field to another

Just like the Update a work item 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 work item itself, which copies a field from a work item to another field on the same work item.

• the parent work item, which copies from the work item’s parent to itself. This option only works if the work item is the child of another work item e.g. copying a work item 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 work types that share the workflow. So we’ll skip this rule when:

• it’s on a work item 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 work item and the work item 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:

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:

Update a work item field

This rule helps ensure that work items capture the right information at the right time. You can reduce data entry errors and increase consistency.

Jira can update certain fields for you automatically when you move work items between columns or change their status:

1. [トランジション] ドロップダウンで、特定のフィールドを更新する列またはステータスを Jira に設定します。
2. 自動更新するフィールドを選択します。

テキスト、数値、ラベル、日付、または期間フィールドやカスタム フィールドなど、プロジェクトに追加したすべてのフィールドを更新できます。カスタム フィールドについては、こちらを参照してください。

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

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

• 期間または日付フィールドを更新すると、Jira はボード上のカードの移動時の日付とタイムスタンプ (またはこのいずれか) でフィールド内のすべての要素を置き換えます。静的な時間または日付を指定することはできません。

例

幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

作業前 → 設計中 → 開発中 → レビュー中 → 完了

For traceability and reporting, teams might add custom date fields to their work types to track hand-off dates:

• 設計部門による確認
• 開発への引き継ぎ
• QA 担当者への引き継ぎ

They can create simple rules that update these hand-off date fields to the current date of when someone moves the work item to a certain column or status:

• For work items moving to In design, update the Picked up by design field to the current date/time.
• For work items moving to In development, update the Handed to development field to the current date/time.
• For work items moving to In review, update the Handed to QA champion field to current date/time.

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 work item.
• %%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.

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

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

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. 自動更新するフィールドを選択します。

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

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

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

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.