作業項目の種類に関するワークフローの変更Change the workflow for a work item type

Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018-TFS 2013Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

重要

この記事は、オンプレミスの XML プロセスモデルのプロジェクトカスタマイズに適用されます。This article applies to project customization for On-premises XML process models. プロセスモデルの概要については、「 作業追跡エクスペリエンスのカスタマイズ」を参照してください。For an overview of process models, see Customize your work tracking experience.

作業項目の種類 (WIT) のワークフローを変更して、ビジネスおよびチームのプロセスをサポートすることができます。You can change the workflow for a work item type (WIT) to support your business and team processes. Wit は — 、ソフトウェア開発をサポートするためのあらゆる種類の作業要件、タスク、コード障害の追跡をサポート — しています。WITs support tracking all types of work—requirements, tasks, code defects—to support software development.

ワークフローは、チーム メンバーが実行する作業の論理的な進行と回帰を決定します。The workflow determines the logical progression and regression of work that team members will perform. また、[状態] フィールドおよび [理由] フィールドのドロップダウン メニューに表示される値を指定します。It also specifies the values that appear in the drop-down menus for the State and Reason fields. 既定のプロセステンプレートでサポートされる既定のワークフロー状態の概要については、「 プロセスを選択する」を参照してください。For an overview of the default workflow states supported in the default process templates, see Choose a process.

プロダクトバックログ項目のワークフロー (スクラムプロセステンプレート)Workflow for Product Backlog Item (Scrum process template)

製品バックログ項目のワークフロー、スクラム プロセスProduct backlog item workflow, Scrum process

注意

この記事では、ワークフローの状態をカスタマイズする方法について説明します。This article describes how to customize a workflow state. 代わりに、特定の作業項目に割り当てられた 状態 を変更する場合は、「作業項目の追加」、「 作業状態の更新」、「 かんばんボード」、「進行中の作業の追跡」、または「タスクボード」、「タスク の状態の更新」のいずれかのトピックを参照してください。If instead, you want to change the State assigned to a specific work item, see one of the following topics: Add work items, Update work status, Kanban board, Track work in progress, or Task board, Update task status. 多くの作業項目に対して、状態 の一括更新を実行することもできます。You can also perform a bulk update of the State for many work items.

ビルドパイプラインワークフローの詳細については、「 CI/CD の概要」を参照してください。For information about build pipeline workflows, see Get started with CI/CD.

WIT の XML 定義を更新するUpdate the XML definition for a WIT

WIT のカスタマイズを初めて使用する場合は、次の点に注意してください。If you are new to WIT customization, note the following:

ワークフローをカスタマイズするには、次の2つの手順を実行します。To customize the workflow, follow these two steps:

  1. WORKFLOWこのトピックで説明されているように、WIT 定義のセクションを変更します。Modify the WORKFLOW section of the WIT definition as described in this topic.

  2. 新しいワークフロー状態をメタ状態にマップするようにプロセス構成を変更します。Modify the process configuration to map new workflow states to metastates.

    アジャイルツールページに表示される WIT のワークフローを変更する場合は、この2番目の手順が必要です。This second step is required when you change the workflow for a WIT that appears on an Agile tool page. こうした WIT は、要件またはタスクのカテゴリに属します。These WITs belong to either the Requirement or Task categories. 状態カテゴリの詳細については、「 ワークフローの状態と状態のカテゴリ」を参照してください。To learn more about state categories, see Workflow states and state categories.

ワークフローのデザインのガイドラインWorkflow design guidelines

ワークフローでは、最初に状態、および状態間で有効な遷移の識別方法を定義します。You define the workflow by first identifying the states and the valid transitions between them. WORKFLOWWIT 定義のセクションでは、有効な状態、遷移、遷移の理由、およびチームメンバーが作業項目の状態を変更したときに実行されるオプションのアクションを指定します。The WORKFLOW section of the WIT definition specifies the valid states, transitions, reasons for the transitions, and optional actions that will be performed when a team member changes the state of a work item.

通常、各状態は、チーム メンバーの役割とタスクに関連付けます。この役割とタスクでは役割を割り当てられた人が作業項目を処理してから、状態を変更する必要があります。In general, you associate each state with a team member role and a task that a person in that role must perform to process the work item before changing its state. 遷移では、状態間で有効な進行と回帰を定義します。Transitions define the valid progressions and regressions between states. チーム メンバーがある状態から他の状態に作業項目を変更する理由の指定、およびワークフローのある時点における作業項目の遷移のオートメーションをサポートするアクションです。Reasons identify why a team member changes a work item from one state to another, and actions support automation of the transition of a work item at a point in the workflow.

たとえば、テスト担当者が既定のアジャイルプロセスを基に新しいバグを開くと、状態は [ 新規 ] に設定されます。For example, the State is set to New when a tester opens a new bug that is based on the default Agile process. バグの修正時に開発者が状態を アクティブ に変更し、修正されたら、開発者はその状態を [ 解決済み ] に変更し、[理由] フィールドの値を [ 固定] に設定します。The developer changes the State to Active when fixing the bug, and once fixed, the developer changes its state to Resolved and sets the value of the Reason field to Fixed. 修正を確認すると、テスト担当者がバグの状態を [ 終了 ] に変更し、[理由] フィールドが [ 検証済み] に変わります。After verifying the fix, the tester changes the state of the bug to Closed and the Reason field changes to Verified. テスト担当者がバグを修正していないと判断した場合、テスト担当者はバグの状態を アクティブ に変更し、その理由を [ 未修正 ] または [ テスト失敗] として指定します。If the tester determined that the developer had not fixed the bug, the tester would change the state of the bug to Active and specify the Reason as Not Fixed or Test Failed.

ワークフローを設計または変更するときは、次のガイドラインを考慮してください。As you design or modify a workflow, consider the following guidelines:

  • 要素を使用して、 STATE 作業項目に対して特定のアクションを実行するチームメンバーロールごとに一意の状態を定義します。Use the STATE element to define a unique state for each team member role that will take a specific action on a work item. 定義する状態の数が増えれば、定義する必要のある遷移の数も増えます。The more states you define, the more transitions you must define. 状態を定義する順序に関係なく、[ 状態 ] フィールドのドロップダウンメニューには、その状態がアルファベット順に表示されます。Regardless of the sequence in which you define the states, they are listed in alphanumeric order in the drop-down menu for the State field.

    Web ポータルのバックログページまたはボードページに表示される作業項目の種類に状態を追加する場合は、状態を状態カテゴリにマップする必要もあります。If you add a state to a work item type that appears on the backlog or board pages in the web portal, you must also map the state to a state category. 詳細については、「 ワークフローの状態と状態のカテゴリ」を参照してください。To learn more, review Workflow states and state categories.

  • 要素を使用して、 TRANSITION 有効な進行と回帰をそれぞれ1つの状態から別の状態に遷移するように定義します。Use the TRANSITION element to define a transition for each valid progression and regression from one state to another.

    少なくとも、状態ごとに 1 つの遷移、および null 状態から初期状態への遷移を定義する必要があります。At a minimum, you must define one transition for each state, and the transition from the null state to the initial state.

    割り当てられていない状態 (null) から初期状態への遷移は、一度だけ定義できます。You can define only one transition from unassigned (null) to the initial state. 新しい作業項目を保存すると、自動的に初期状態に割り当てられます。When you save a new work item, it is automatically assigned to the initial state.

    チーム メンバーが作業項目の状態を変更すると、変更によって遷移が発生し、選択された状態と遷移に対して実行されるように定義したアクションが実行されます。When a team member changes the state of a work item, that change triggers the transition and the actions that you define to be performed for the selected state and the transition. ユーザーは、現在の状態に対して定義した遷移に基づき、有効な状態のみを指定できます。Users can specify only those states that are valid based on the transitions that you define for the current state. さらに、 ACTION の子要素である要素は、 TRANSITION 作業項目の状態を変更できます。In addition, an ACTION element, which is a child element of TRANSITION, can change the state of a work item.

  • 遷移ごとに、要素を使用して既定の理由を定義し DEFAULTREASON ます。For each transition, you define a default reason by using the DEFAULTREASON element. 必要に応じて、要素を使用して任意の数のオプションを定義でき REASON ます。You can define as many optional reasons as you want by using the REASON element. これらの値は、[ 理由 ] フィールドのドロップダウンメニューに表示されます。These values appear in the drop-down menu of the Reason field.

  • 作業項目が変更されたとき、作業項目の状態が遷移したとき、またはユーザーが特定の理由を選択したときに適用される規則を定義できます。You can specify rules that will be applied when the work item changes state, when it transitions, or when a user selects a specific reason. これらの規則の多くは、定義の下のセクションでフィールドを定義するときに適用できる条件付き規則を補完し FIELDS WORKITEMTYPE ます。Many of these rules supplement the conditional rules that you can apply when you define the fields in the FIELDS section under the WORKITEMTYPE definition. 詳細については、このトピックで後述 する「ワークフロー変更時のフィールドの更新 」を参照してください。For more information, see Update fields during a workflow change later in this topic.

  • 状態と理由に割り当てる名前では、大文字と小文字は区別されません。The names that you assign to states and reasons are case insensitive.

    作業項目フォームまたはクエリエディター内の [状態] フィールドと [理由] フィールドのドロップダウンメニューには、 WORKFLOW 作業項目の種類のセクションに割り当てられた値が表示されます。The drop-down menus for the State and Reason fields within the work item form or query editor display the values assigned in the WORKFLOW section of the work item type.

ワークフロー図とコード例Workflow diagram and code example

次のコード例は、 WORKFLOW アジャイルプロセステンプレートのバグ WIT 定義のを示しています。The following code example shows the WORKFLOW for the Bug WIT definition for the Agile process template. この例は、3 つの状態と 5 つの遷移を定義しています。This example defines three states and five transitions. 要素は、 STATE アクティブ、解決済み、および終了状態を指定します。The STATE elements specify the Active, Resolved, and Closed states. 進行と回帰の遷移で適用可能な組み合わせは、これらの 3 つの状態に対して定義されますが、1 つの例外があります。All possible combinations for progression and regression transitions are defined for the three states, except one. つまり、[終了] から [解決済み] への遷移は定義されません。The transition from Closed to Resolved is not defined. そのため、作業項目が終了になった場合、チーム メンバーはこの種類の作業項目を解決できません。Therefore, team members cannot resolve a work item of this type if the work item is closed.

この例 DEFAULTREASON では、、、 REASON ACTION 、およびのすべての要素が一覧表示されるわけではありません FIELDThis example doesn't list all the elements for DEFAULTREASON, REASON, ACTION, and FIELD.

ワークフロー状態の例図 — アジャイルバグ WITExample Workflow State Diagram — Agile Bug WIT

バグ ワークフローの状態、Agile プロセス テンプレートBug workflow states, Agile process template

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

状態の数と種類の決定Determine the number and types of states

作業項目の種類を設定する論理的な異なる状態の数を基に、有効な状態の数と種類を決定します。You determine the number and types of valid states based on the number of distinct logical states in which you want the work items of that type to exist. また、別のチーム メンバーが異なるアクションを実行する場合、メンバーの役割に基づいて状態を定義することもできます。Also, if different team members perform different actions, then you can consider defining a state based on a member role. 各状態は、次の状態に移行させるためにチーム メンバーが作業項目で実行する必要があるアクションに対応します。Each state corresponds to an action that a team member must perform on the work item to move it to the next state. 各状態ごとに、特定のアクションと、それらのアクションを実行できるチーム メンバーを定義する必要があります。For each state, you should define the specific actions and the team members who are allowed to perform those actions.

次の表に、機能の進行を追跡するために定義された 4 つの状態、および指定されたアクションを実行する必要がある有効なユーザーの例を示します。The following table provides an example of four states that are defined to track the progress of a feature and the valid users who must perform the indicated actions:

StateState 有効なユーザーValid user 実行するアクションAction to perform
提案Proposed プロジェクト マネージャーProject manager 機能の作業項目はだれでも作成できます。Anyone can create a feature work item. ただし、作業項目を承認するかしないかを決定できるのはプロジェクト マネージャーだけです。However, only project managers can approve or disapprove the work item. プロジェクト マネージャーがフィーチャーを承認すると、プロジェクト マネージャー本人が作業項目の状態を [アクティブ] に変更します。それ以外の場合は、チーム メンバーが作業項目を終了します。If a project manager approves a feature, the project manager changes the status of the work item to Active; otherwise, a team member closes it.
アクティブActive 開発者リードDevelopment lead 開発者は、機能の開発を指揮し、監督します。The development lead oversees the development of the feature. 機能が完了したら、開発者が機能の作業項目の状態変更を指揮し、校閲します。When the feature is completed, the development lead changes the status of the feature work item to Review.
確認Review プロジェクト マネージャーProject manager プロジェクト マネージャーはチームが実装した機能をレビューして、実装に満足できれば、作業項目の状態を [終了] に変更します。The project manager reviews the feature that the team implemented and changes the status of the work item to Closed if the implementation is satisfactory.
解決済みClosed プロジェクト マネージャーProject manager 終了した作業項目で発生する予定のアクションはありません。No additional action is expected to occur on work items that are closed. これらの項目はアーカイブ用およびレポート用としてデータベース内に残ります。These items remain in the database for archival and reporting purposes.

注意

すべての状態は、特定の種類の作業項目ごとに、指定したシーケンスに関係なく作業項目のフォーム上の一覧にアルファベット順で表示されます。All states appear in alphabetical order in the list on the form for a work item of a particular type, regardless of the sequence in which you specify them.

遷移の定義Define transitions

有効な状態の進行と回帰を定義する場合は、チーム メンバーが状態から、または状態に対して作業項目を変更できるように状態を制御します。You control the states to and from which team members can change a work item if you define the valid state progressions and regressions. ある状態から別の状態への遷移を定義しない場合、チーム メンバーは特定の種類の作業項目をある状態から別の状態に変更することができません。If you do not define a transition from one state to another state, team members cannot change a work item of a particular type from a particular state to another particular state.

次の表では、このトピックで前述した 4 つの状態それぞれに有効な遷移と既定の理由を定義しています。The following table defines the valid transitions for each of the four states that were described earlier in this topic, together with the default reason for each.

StateState 状態への遷移Transition to state 既定の理由Default reason
提案Proposed アクティブ (進行)Active (progression) 開発承認済みApproved for development
終了 (進行)Closed (progression) 未承認Not approved
アクティブActive 校閲 (進行)Review (progression) 承認基準に一致Acceptance criteria met
確認Review 終了 (進行)Closed (progression) 機能の完成Feature complete
アクティブ (回帰)Active (regression) 要件を満たしていないDoes not meet requirements
解決済みClosed 提案済み (回帰)Proposed (regression) 承認を再検討Reconsider for approval
アクティブ (回帰)Active (regression) エラーによる終了Closed in error

要素の for 属性と not 属性を使用して、ある状態から別の状態への遷移を許可するユーザーを制限でき TRANSITION ます。You can restrict who is allowed to make a transition from one state to another by using the for and not attributes of the TRANSITION element. 次の例では、テスト担当者はバグを再び開けるようにし、開発者は開くことができないようにした例を示しています。As the following example shows, testers can reopen a bug but developers cannot.

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>  

理由の指定Specify the reasons

追加のオプションを定義している場合、チーム メンバーは状態フィールドを変更するときに、遷移に対する既定の理由をそのまま使用するか、別の理由を指定できます。When a team member changes the State field, that user can retain the default reason for that transition or specify a different reason if you define additional options. 要素を使用して、既定の理由を1つだけ指定する必要があり DEFAULTREASON ます。You must use the DEFAULTREASON element to specify one and only one default reason. チームでのデータの追跡またはレポート生成を支援する場合は、追加の理由を指定する必要があります。You should specify additional reasons only if they help the team track or report data.

たとえば、開発者はバグを解決したときに、[修正済み] (既定)、[延期]、[重複]、[仕様]、[再現不可能]、[廃止] のいずれかを理由として指定できます。For example, a developer can specify one of the following reasons when they resolve a bug: Fixed (Default), Deferred, Duplicate, As Designed, Cannot Reproduce, or Obsolete. 各理由では、テスト担当者がバグに関して実行する特定のアクションが指定されます。Each reason specifies a particular action for the tester to perform with regard to the bug.

注意

すべての理由は、要素を指定する順序に関係なく、特定の種類の作業項目について、作業用フォームのリスト内でアルファベット順に表示され REASON ます。All reasons appear in alphabetical order in the list on the work form for work items of a particular type, regardless of the sequence in which you specify the REASON elements.

次の例では、チーム メンバーがバグを解決する理由を定義する要素を示します。The following example shows the elements that define the reasons why a member of the team might resolve a bug:

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>  

アクションの指定Specify actions

一般に、チームメンバーは、[ 状態 ] フィールドに別の値を指定して作業項目を保存することによって、作業項目の状態を変更します。In general, team members change the state of a work item by specifying a different value for the State field and then saving the work item. ただし、 ACTION その遷移が発生したときに作業項目の状態を自動的に変更する要素を定義することもできます。However, you can also define an ACTION element that automatically changes the state of a work item when that transition occurs. 次の例で示しているように、開発者がバージョン管理にチェックインするファイルにバグ作業項目が関連付けられている場合に、それらのバグ作業項目が自動的に解決されるように指定できます。As the following example shows, you can specify that bug work items should be resolved automatically if they are associated with files that a developer checks into version control:

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>  

要素を使用すると、 ACTION Microsoft Visual Studio アプリケーションライフサイクル管理で、または Visual Studio アプリケーションライフサイクル管理の外部 (呼び出しを追跡するツールなど) でイベントが発生した場合に、特定の種類の作業項目の状態を自動的に変更できます。You can use the ACTION element to automatically change the state of work items of a particular type when events occur elsewhere in Microsoft Visual Studio Application Lifecycle Management or outside Visual Studio Application Lifecycle Management (for example, from a tool that tracks calls). 詳細については、「 ACTION」を参照してください。For more information, see ACTION.

ワークフローの変更中にフィールドを更新Update a field during a workflow change

次のイベントが発生するたびにフィールドを更新する規則を定義できます。You can define rules that update fields whenever the following events occur:

  • STATEへのすべての遷移に対して規則を適用する場合、およびその状態を入力する理由には、でフィールド規則を割り当てます。Assign a field rule under STATE when you want the rule to apply for all transitions to and reasons for entering that state.

  • この遷移に対してルールを適用する場合は、その移行を行うためのすべての理由で、にフィールドルールを割り当て TRANSITION ます。Assign a field rule under TRANSITION when you want the rule to apply for that transition and all reasons for making that transition.

  • DEFAULTREASON REASON 規則がその特定の理由にのみ適用されるようにする場合は、またはの下にフィールド規則を割り当てます。Assign a field rule under DEFAULTREASON or REASON when you want the rules to apply only for that specific reason.

    フィールドに常に同じ値を含める場合は、 FIELD そのフィールドを定義する要素の下に規則を定義します。If a field should always contain the same value, you define the rule under the FIELD element that defines that field. 規則の使用方法の詳細については、「 フィールド規則の適用」を参照してください。To learn more about rule usage, see Apply a field rule.

    作業項目の種類 1 つに対し、定義する条件の数はできるだけ少なくしてください。You should try to minimize the number of conditions that you define for any one type of work item. 条件付き規則を追加するに従って、チーム メンバーが作業項目を保存するたびに発生する検証プロセスが複雑になります。With each conditional rule that you add, you increase the complexity of the validation process that occurs every time that a team member saves a work item. 複雑な規則を設定すると、作業項目の保存に時間がかかることがあります。Complex rule sets might increase the time that is required to save the work item.

    次の表に、MSF Agile Software Development のプロセス テンプレートのシステム フィールドに適用される規則のいくつかを例として示します。The following examples show some of the rules that are applied to system fields in the process template for MSF Agile Software Development.

状態が変化したときにフィールド値を変更Change the value of a field when the state changes

作業項目の [ 状態 ] フィールドの値が [アクティブ] に設定されていて、作業項目が保存されている場合、[ アクティブ化 ] フィールドと [ 割り当て先ユーザー/グループ ] フィールドの値は、現在のユーザーの名前に自動的に設定されます。When the value of the State field for a work item is set to Active and the work item is saved, the values of the Activated By and Assigned To fields are automatically set to the name of the current user. そのユーザーは Team Foundation Server 有効なユーザーグループのメンバーである必要があります。That user must be a member of the Team Foundation Server Valid Users group. [ アクティブ化 された日付] フィールドの値も自動的に設定されます。The value of the Activated Date field is also set automatically. この規則を適用する要素を次の例に示します。The following example shows the elements that enforce this rule:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>  

別のフィールド値が変化したときにフィールド値をクリアClear the value of a field when the value of another field changes

作業項目の [ 状態 ] フィールドの値が [アクティブ] に設定されていて、作業項目が保存されている場合、 EMPTY 次の例に示すように、要素を使用すると、[終了日] フィールドと [終了者] フィールドが自動的に null に設定され、読み取り専用になります。When the value of the State field for a work item is set to Active and the work item is saved, the Closed Date and Closed By fields are automatically set to null and made read-only if you use the EMPTY element, as the following example shows.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>  

別のフィールドの内容に基づくフィールドの定義Define a field based on the contents of another field

作業項目の [ 状態 ] フィールドの値が [解決済み] に変更され、作業項目が保存されると、[解決された 理由 ] フィールドの値は、[ 理由 ] フィールドでユーザーが指定した値に設定されます。When the value of the State field for a work item changes to Resolved and the work item is saved, the value of the Resolved Reason field is set to the value that the user specified in the Reason field. この規則を適用する要素を次の例に示します。The following example shows the elements that enforce this rule:

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>  

ツールのサポートTool support

Visual Studio Marketplace から 状態モデルの視覚化拡張機能 をインストールすることによって、ユーザーがワークフローを視覚化できるようにすることができます。You can support your users to visualize the workflow by installing the State Model Visualization extension from the Visual Studio Marketplace.