プロセスワークフローの定義

Altium Designer のコラボレーティブ設計環境を支える基盤の1つが、Workflowsのサポートです。これにより、Workspace の新しいライブラリ部品のリクエスト、デザインレビューの実施、新しい Workspace プロジェクトの作成といった、典型的で日常的な設計プロセスを社内の設計者が進められるようになります。

特定の設計プロセスを実装するために使用される各 Workflow は、Process Definitionの一部として作成されます。そのため、そのプロセスの基盤となる Workflow、あるいは単にProcess Workflowと呼ぶことができます。新しいプロセスの作成や既存プロセスの編集は、専用のProcess Workflow Editorを使用して行えます。本ドキュメントでは、エディタへのアクセス方法と、必要なプロセスワークフローを作り込むための操作方法を説明します。

プロセスワークフローエディタへのアクセス

プロセスは、Workspace のブラウザインターフェースのProcesses領域（Admin – Processes）から作成・管理します。

Process Workflow Editorにアクセスするには、新しいプロセスを作成したいプロセステーマのタブ（Part Requests、Project Activities、またはProject Creations）をアクティブにしてから、ページ右上のボタンをクリックします。

Process Workflow Editorへのアクセス。アクセス前に目的のプロセステーマをアクティブにしておくことで、新しいプロセス定義が正しいテーマタイプに設定されます。

Process Workflow Editorは、目的のワークフローを図式的に作成するためのキャンバスを提供します。エディタのメイン領域でワークフロー図を作成し、右側のPropertiesペインには、現在選択されている図要素に関連するプロパティが表示されます。

図内で配置済み要素が何も選択されていない場合、Propertiesペインには、プロセス定義のNameおよびType（どのプロセステーマに属するか）が反映されます。プロセスには分かりやすい名前を付けてください。これは Workspace のブラウザインターフェース、および Altium Designer GUI の該当するアクセス箇所に表示され、設計者が（使用のために有効化されていれば）そのプロセスのインスタンスを開始できるようになります。

ワークフロー図

プロセスワークフロー図は、領域上部のパレットから利用できる各種要素を使って構築します。

ワークフロー図は、利用可能なパレットの要素を使って構築します。

次の表に、使用可能な図要素をすべて示します。

Icon	Type	Description
	Connection	この要素は、ワークフロー内のイベントポイント要素同士を相互接続するためのものです。形状はグラフィカルに変更できます。既定ではNameは空欄ですが、フロー内の分岐要素から伸びる各パスを示したり説明したりするのに役立ちます。
	Start	これはワークフローの開始点です。Nameはテーマに応じて既定で事前入力されます（Submit Request（Part Requests）、Start Activity（Project Activities）、Create Project（Project Creations））。必要に応じて変更できます。この要素に関連付けられたフォームに追加される既定フィールドについては、Built-in FieldsおよびDefault Fieldsを参照してください。 Project Activities のプロセステーマでは、この要素は2つ目のType（Start Release）をサポートします。これは、リリース済みプロジェクトを統合 PLM インスタンスへ公開するワークフローで使用され、すべて Altium Designer のProject Releaserの一部として実行されます。 Project Creations のプロセステーマでは、追加のDefault server folderプロパティにより、新規プロジェクトの保存先となるベースフォルダパスを指定できます。定義すると、このワークフローのthe default locationとなり、ユーザーはNew ProjectフォームのServer Folderフィールド（Advancedタブ）で上書きできます。 この要素のタイプ切り替えについて詳しくは、Changing the Type for a Workflow Elementを参照してください。
	Event	この要素は、統合 PLM インスタンス内のアクション結果を取得するために使用できます（OKまたはFAILの出力に加え、メッセージとログを出力します）。そのためには、テーマに応じてType を設定します（PLM Part Completed（Part Requests）、PLM Publish Completed（Project Activities）、PLM Initialise Completed（Project Creations））。既定ではNameはType エントリで事前入力されていますが、必要に応じて変更できます。 この要素は、Enterprise Server EDS を使用してサードパーティシステムへ通知を送受信する用途にも使用できます（Enterprise Server SDK へのアクセスが必要）。Type をSendまたはReceiveに設定します（ワークフローの一部として Send と Receive の両イベント定義が必要です）。通知は一意の識別子Codeとメッセージで構成されます。なお、Codeは Send と Receive の両イベントで同一である必要があります。 Project Activities では、この要素の Type をRelated Tasks Completedに設定することもできます。これは、コメントが追加され、特定の人にタスクとして割り当てられている場合（プロジェクト自体のアクティビティに関連付け）に使用します。つまり、関連タスク（割り当てられたコメント）がすべて解決されるまで、そのアクティビティのプロセスワークフローを完了できません。
	End	これはワークフロー（またはその分岐）の終端点です。この要素のNameは、Completed、Rejected、またはCancelledのいずれかに設定できます。
	Task	この要素は、実行すべきタスク（1人以上のユーザーが実施する必要がある作業）を表します。レビューをベースにした Project Activity ワークフローでは、レビューの一部としてフィードバックを提供することが該当します。Part Request ワークフローでは、リクエストされた特定コンポーネント、あるいはそのシンボルやフットプリントのみを作成・対応することが該当します。 各タスクは、専用のFormを通じてユーザーにデータを提供したり、ユーザーからデータを取得したりします。フォームは、タスクの目的を達成するために必要なフィールド、変数、情報をすべて含めて構築します。詳しくはBuilding a Formを参照してください。 標準のUser Task（フォームで必要に応じて定義）に加えて、各プロセステーマは1つ以上の追加タイプをサポートします（Create Part in PLM（Part Requests）、Collect Project DataおよびPublish to PLM（Project Activities）、Initialise in PLM（Project Creations））。いずれの場合も、Nameは既定でタスクのタイプに設定されますが、必要に応じて変更できます。追加設定はタイプごとに定義する必要があり、Assignee やTask Ownershipなど、タイプに応じて内容が異なります。PLM 関連タイプのタスクでは、PLM インスタンスでのアクション結果を取得するために使用されます（OKまたはFAILの出力に加え、メッセージと（Project Activities および Project Creations テーマでは）プロパティを出力します）。 Project Creations のプロセステーマでは、追加のDefault server folderプロパティにより、新規プロジェクトの保存先となるベースフォルダパスを指定できます。定義すると、このワークフローのthe default locationとなり、ユーザーはNew ProjectフォームのServer Folderフィールド（Advancedタブ）で上書きできます。 この要素のタイプ切り替えについて詳しくは、Changing the Type for a Workflow Elementを参照してください。
	Branch	この要素は、フローの前段で取得した結果（例：ユーザーの選択や判断の取得）に応じてワークフローを分岐させるためのものです。既定ではNameは空欄です。
	Comment	この要素を使うとワークフローにコメントを付けられます。通常はフローの各ポイントにコメントを追加し、その地点で何が起こるべきかを記述します。既定ではNameは空欄です。

ワークフロー要素の配置

パレットから要素を配置するには、次の手順を行います。

1. パレット上の要素エントリをクリックします。要素のインスタンスが青色でハイライトされ、カーソルに追従して表示されます。
2. ワークフローキャンバス上の所定位置に要素を移動し、クリック（または右クリック）して配置します。キャンバス上で要素を移動すると、既に配置されている要素の水平・垂直中心に対して整列ガイドが表示されます。
3. 配置をキャンセルするには、Escを押します。

ワークフローキャンバスへの要素配置例（Start、End、User Task）。配置時に役立つ動的な整列ガイドに注目してください。

ワークフロー要素の接続

2つのワークフロー要素を接続するには、次の手順を行います。

1. パレットのエントリをクリックします。
2. 接続する最初の（ソース）要素の上にカーソルを合わせてクリックします。
3. カーソルを動かすと、要素から接続線が伸び始めます。接続する2つ目の（ターゲット）要素の上にカーソルを合わせてクリックします。

4. さらに接続を配置し続けるか、右クリックするか、Escを押して終了します。

ワークフローにおける要素接続の例。

ワークフロー要素の移動

要素を移動するには、クリックして目的の新しい位置までドラッグします。要素が1つ以上の他の要素と接続によって結ばれている場合、それらの接続は維持され、接続線の経路はそれに合わせて変更されます。表示される動的な整列ガイドを使って位置合わせを行ってください。

1つ、次に複数の配置済み要素を移動する例。接続は、選択範囲に含まれていない限り、要素同士の接続を維持するために適宜変更される点に注意してください。

接続の変更

接続の上にカーソルを置くと、さまざまな編集コントロール（「ハンドル」）が利用可能になります。これらにより、接続に対して次の変更をグラフィカルに行えます。

• ハンドルをクリックしてドラッグすると、接続を垂直方向にのみ移動できます。
• ハンドルをクリックしてドラッグすると、接続を水平方向にのみ移動できます。
• 接続に沿ってカーソルを移動すると、 ハンドルがカーソルに追従します。このハンドルをクリックしてドラッグすると、接続に新しい頂点（折れ点）を作成できます。
• ハンドルをクリックしてドラッグすると、接続の始点を移動できます。この点は別の既存要素の上へドラッグする必要があります。
• ハンドルをクリックしてドラッグすると、接続の終点を移動できます。この点は別の既存要素の上へドラッグする必要があります。

接続上にカーソルを置いたときに表示される各種編集ハンドルを使用して、既存の接続を変更する例。

要素プロパティの変更

前述のとおり、Process Workflow Editor の右側には Properties ペインがあり、現在選択されているワークフロー要素のプロパティが表示されます。Connection、Branch、End、Comment など一部の要素では、編集可能なプロパティは Name のみです。一方、Start や Task などでは、定義可能な設定に加えて、必要に応じて作成できる関連 Form があります。また、ワークフロー要素のプロパティは、プロセスを定義しているプロセステーマ（および、1つの要素で複数タイプがサポートされる場合は、その要素に選択したタイプ）によって変わることも覚えておいてください。

Start ワークフロー要素のデフォルトプロパティを表示しているプロパティペイン（Project Activities テーマ内でプロセスを定義し、要素の Type を Start Activity に設定した場合）。画像にカーソルを合わせると、Task 要素（User Task として構成）を選択したときのデフォルトプロパティが表示されます。

選択したワークフロー要素のプロパティは、必要に応じて Properties ペインから変更します。Form を定義できる要素の場合は、フォームを作成（ペインの Form セクションにある ボタンをクリック）するか、編集（ペインの Form セクションにある エントリをクリック）する必要があります。詳細は Building a Form を参照してください。

ワークフロー要素のタイプ変更

次のプロセステーマには、複数タイプをサポートするワークフロー要素があります。

• Part Requests テーマ:
  • Task – サポートするタイプ: User Task, Change State, Create Part in PLM.
  • Event – サポートするタイプ: Send, Receive, Notify User, PLM Part Completed.
• Project Activities テーマ:
  • Start – サポートするタイプ: Start Activity, Start Release.
  • Task – サポートするタイプ: User Task, Change State, Collect Project Data, Publish to PLM.
  • Event – サポートするタイプ: Send, Receive, Notify User, PLM Publish Completed, Related Tasks Completed.
• Project Creations テーマ:
  • Task – サポートするタイプ: User Task, Create Project, Change State, Initialise in PLM.
  • Event – サポートするタイプ: Send, Receive, Notify User, PLM Initialise Completed.

要素をワークフロー図のキャンバスに配置した後、選択すると要素の内側／隣に表示される ボタンに関連付けられたメニューを使って、利用可能なタイプ間で切り替えられます。

Project Activities プロセステーマに属するプロセスのワークフローを定義する際に、Start、Task、Event 要素でサポートされるタイプを順に切り替えている例。

タスクの割り当て

ワークフロー内のタスクがどのように割り当てられるかは、Assignee、Except、Task ownership に定義された設定に依存します。

• Assignee – Workspace の単一ユーザー、複数ユーザー、または特定のグループを指定できます。ここでも変数を使用できます。例えば $Initiator（プロセスインスタンスを開始した人）や、$Review Coordinator（前のタスクでレビューコーディネーターとして選択されたユーザー）などです。

• Except – 割り当て対象の範囲に含まれていても、そのタスクを実行できないユーザーを指定します。例えば、部品のリクエストを行った人が自分の部品リクエストを承認すべきではありません。別の例として、マイルストーンレビューのプロセスにおける Verify rework タスクの Except フィールドで $Rework executed by 変数を使用し、直前のタスク（Rework）を実行したユーザーが自分の作業を検証できないようにする、といった使い方があります。
• Task ownership – Assignee フィールドで指定したユーザーに対して、誰がタスクを実行できるかを決定します。次のオプションがあります:
  • One of assigned users – Assignee フィールドに単一ユーザーしかいない場合、リクエストに取り掛かる最初のタスクはそのユーザーに直接割り当てられます。複数の割り当て先がある場合、全ユーザーのタスクリストにタスクが表示され、そのうちの1人がタスクを自分に割り当てます。
  • All assigned users – すべての割り当て先がタスクを受け取ります。

下の画像は、Part Request プロセス定義の割り当て設定を示しています。Assignee は Workspace の管理者（Administrators グループのメンバー）として定義されています。Task ownership は One of assigned users に設定されており、これら管理ユーザーのうち1人がリクエストを引き受ける必要があることを意味します。

新しい部品リクエストに取り掛かるタスクを最初に受け取るユーザーは、該当するプロセス定義の基盤となるワークフロー内で、初期ユーザータスクに対して Assignee、Except、Task ownership の設定がどのように定義されているかによって決まります。上の画像は、デフォルトの New Part Request プロセス定義の設定を示しています。

標準ユーザー向けデータ可視性の設定

アクティブなプロセスインスタンスの進捗を表示する際、プロセスワークフローの Data tab で標準ユーザーに表示されるパラメトリックデータを設定できます。プロセスのワークフローを編集していて、要素が何も選択されていない場合、Data tab に表示できるデータが Properties ペインに一覧表示されます。 コントロールをクリックして、関連フォーム（<ProcessName> Data）にアクセスします。

このフォームから、パラメータを Data tab に表示するかどうかを決定できます。デフォルトではパラメータは表示（）されます。このコントロールをクリックすると非表示（）になります。さらに、データの表示順も制御できます。パラメータのエントリにカーソルを合わせると、左側に コントロールが表示されます。これをクリックしたまま保持し、パラメータを新しい位置へドラッグします。

次の画像は、フォームと、管理者および標準（非管理者）ユーザーがプロセスの Data tab で見る内容の関係を示しています。この例では、Description と Datasheets パラメータは標準ユーザーには非表示です。

ワークフロー要素の削除

ワークフロー要素を削除するには、それを選択してから Delete キーボードショートカットを使用します。複数要素を削除するには、それらを囲むように選択ボックスをクリック＆ドラッグするか、Ctrl+クリックで個別に選択を追加してから、Delete ショートカットを使用します。

フォームの作成

2つのワークフロー要素（Start と Task）は、ユーザーに何らかの作業を依頼するものです。これは、初期化情報（プロジェクト名とタイプ、レビュー用の初期データセット、要求部品番号、メーカー、データシート）の要求であったり、フローの途中で追加のユーザー入力が何らかの形で必要となる別のタスク（レビュー判断、追加データ、コメント、リクエストの完了部品など）であったりします。これら2つの要素はいずれも task-oriented と考えることができます。

必要なフィールドと変数を提示してこのようなユーザー操作を促進するために、Form が作成されます。場合によっては、削除できない組み込みフィールドを備えた Form がすでに存在することもあれば、Form は用意されていて既定フィールドを持つものの、それらを用途に合わせて変更できることもあります。さらに別のケースでは Form 自体が存在せず、その場合は自社の要件に応じて、必要なだけシンプルにも複雑にも Form を比較的自由に作成できます。

以下のリストは、Form を使用／必要とするこれら 2 つのタスクのすべてのバリエーションを示します。

• Start（Part Requests テーマ）– 既定フィールドを持つ既存 Form。これらは編集または削除でき、該当する場合は既定値を定義できます。必要に応じて追加フィールドを追加できます。
• StartStart ActivityタイプStart Activity（Project Activities テーマ）– 組み込みフィールドを持つ既存 Form。これは削除できません。必要に応じて追加フィールドを追加できます。
• Start（Project Creations テーマ）– 組み込みフィールドを持つ既存 Form。これらは削除できません。該当する場合は既定値を定義できます。必要に応じて追加フィールドを追加できます。
• TaskUser TaskタイプUser Task（すべてのプロセステーマ）– 既存 Form なし。必要に応じて作成します。
• TaskCollect Project DataタイプCollect Project Data（Project Activities テーマのみ）– 組み込みフィールドを持つ既存 Form。これは削除できません。必要に応じて追加フィールドを追加できます。
• TaskCreate ProjectタイプCreate Project（Project Creations テーマ）– 組み込みフィールドを持つ既存 Form。これらは削除できません。該当する場合は既定値を定義できます。必要に応じて追加フィールドを追加できます。

User Form Editor

Form は User Form Editor を使用して作成します。Form を定義できる要素については、Form がまだ存在しない場合は作成する必要があります（ワークフロー内で要素を選択し、Properties ペインの Form セクションにある ボタンをクリック）。すでに存在する場合は編集します（ワークフロー内で要素を選択し、Properties ペインの Form セクションにある エントリをクリック）。

Form は、必要な型のフィールド（名前付き変数を表す）を追加し、さらに（該当する場合）それらのフィールドをどのように使用するかのフラグを設定して構築します。つまり、タスクを実行する対象ユーザーに情報を渡し、また対象ユーザーから情報を取得するためのインターフェースを作り込むことになります。

Form を保存すると（Form 下部の ボタンをクリック）、そこに定義されたすべてのフィールドの概要と、それぞれの変数型が、選択したワークフロー要素の Properties ペインに表示されます。

User Form Editor に、Provide review feedback User Task（Project Activities テーマ内の Milestone Review プロセス定義の一部）の Form が設定されている例。Properties ペインには、Form 上で定義されたすべてのフィールドとその型が、便利な概要リストとして表示されていることが分かります。

以降のセクションでは、User Form Editor の仕組み（変数とフィールドのサポート、各フィールド／変数に関連付けられたフラグ、Form 内での作業、組み込み／既定のフィールドと変数）について説明します。

変数とフィールド

変数とフィールドに関して注意すべき点は次のとおりです。

• Variable は、プロセスのワークフローの一部として追跡される、名前付きのデータ要素です。
• Field は、プロセスのワークフロー内にある特定のユーザー Form の文脈における、変数の表現です。
• プロセスの変数を管理するための専用機能はありません。
  • 管理者がそのプロセスのワークフロー内の Form に初めて追加した時点で、ユーザー定義変数がプロセスに追加されます。
  • ユーザー定義変数は、そのプロセスのワークフロー内で使用されるすべての Form から削除された時点で、プロセスから削除されます。
• 変数の大半は、プロセス定義のワークフロー内で Form を作成する際に、管理者によって定義されます。特定のワークフロー要素について、プロセス定義に組み込まれている 事前定義変数 がいくつかあります。これらは他のユーザー定義 Form でも使用できますが、ワークフロー内のすべての Form から削除しても、プロセスに対しては定義されたまま残ります。
• プロセス内の変数定義は 1 つだけです。つまり、この変数がどこ（どの Form）で編集されても、その変更は同じワークフローで使用されている他のすべての Form、およびその変数が使用されている箇所に自動的に反映されます。
• 変数名は大文字／小文字を区別しません（つまり、大文字／小文字だけが異なる 2 つの変数は作成できません）。

Supported Variable Types

以下の表は、Form で使用できる変数型を示します。

Variable Type	Icon	Editable Flag?	Required Flag?	Reset Value Flag?	Keep Value Per User Option?	Can be Added by User as a New Variable?	Support for Default Value(s)	Has a Value Field?	Representation on Form when Editable	Representation on Form when Read-Only	Applicable Process Themes
Data Set									事前に指定したプロジェクトのリリースを 1 つ選択するためのドロップダウンフィールド。 Explorer ウィンドウを指定できる（3 点ボタン） 選択したリリース内のデータセットがクリック可能なリンクとして一覧表示される	リンクのリスト	Project Activities
Date									日付選択付きのテキストフィールド。 日付を手入力（dd/mm/yyyy 形式）するか、フィールドをクリックしてカレンダーを開く	単一行ラベル	All
Dropdown								複数値をサポートする単一行テキストフィールド（ドロップダウンの選択肢を指定）	定義済みのドロップダウン選択肢を一覧表示するドロップダウン・コンボボックスから選択	単一行ラベル	All
File Upload									ドロップダウン領域（ドラッグ＆ドロップ） Choose Filesボタン 削除可能なリンクのリスト	リンクのリスト	All
Item/Revision									入力検索付きテキストフィールド 複数値をサポート Explorer ウィンドウを指定できる（3 点ボタン）	リンクのリスト	All
Label								複数行テキストフィールド	N/A	複数行ラベル	All
Managed Project									入力検索付きテキストフィールド 複数値をサポート	リンクのリスト	All
Multi Line Text									テキストフィールド。複数行。	複数行ラベル	All
Number									テキストフィールド。数値検証付き単一行	単一行ラベル	All
PLM Publish Template									フォームに表示される、現在定義されているすべての PLM Template を一覧表示するドロップダウンフィールド <PLMInstance>:<PublishingTemplate>)	N/A	Project Activities
Project Template									TC2 が導入されている場合のドロップダウン ... で検索して explorer に移動	単一行ラベル	Project Creations
Properties									N/A	プロパティのキー／値ペアのテーブル ラベル名としてテーブル名を表示 空の場合、フォーム上に表示されない	All
Run Web Review									Web Review 指定したプロジェクトの Web Review インターフェースを起動するボタン	-	Project Activities
Single Line Text									テキストフィールド。単一行	単一行ラベル	All
User/Group									入力検索付きテキストフィールド 複数値をサポート	単一行ラベル 値は ',' で区切る	All

Built-in Fields

特定のタスクタイプには「組み込み」のフィールドがいくつか存在します。これらのフィールドは、元の Form から削除できず、名前の変更もできず、型も変更できません。該当する場合は既定値を定義できます。これらは他の User Form でも使用できますが、次の制約があります。

• フラグは表示されません。フィールドは読み取り専用で、必須にもなりません。
• （該当する場合）値は変更できませんが、（該当する場合）既定値は変更できます。

以下は、組み込みフィールドを持つタスクタイプの一覧です。各項目では、フィールド名の後ろの括弧内に変数／データ型を示しています。

• Start

Default Fields

タスクベースのワークフロー要素には、デフォルトで追加されるフィールドがいくつかあります。これらは他のユーザー定義フィールドと同様に動作するため、必要に応じて変更および／または削除できます。追加先のフォームに対して、単に出発点を提供するものです。

たとえば、次のタスクタイプにはデフォルトフィールドがあります。各フィールドについて、フィールド名の後ろの括弧内に変数／データ型が示されています。

• Start 要素（Part Requests テーマ）：
  • Part number（Single Line Text）– Editable フラグが有効（変更不可）、Required フラグが有効（ただし必要に応じて変更可能）。デフォルト値は未設定（編集可能）。
  • Manufacturer（Single Line Text）– Editable フラグが有効（変更不可）、Required フラグが有効（ただし必要に応じて変更可能）。デフォルト値は未設定（編集可能）。
  • Description（Single Line Text）– Editable フラグが有効（変更不可）、Required フラグは無効（ただし必要に応じて変更可能）。デフォルト値は未設定（編集可能）。
  • Datasheets（File Upload）– Editable フラグが有効（変更不可）、Required フラグは無効（ただし必要に応じて変更可能）。

Built-in Variables

これらは、プロセスまたはタスクに組み込み（Built-in）されている変数です。次の制約のもとで、他のユーザーフォームでも使用できます。

• フラグは表示されません。既定で読み取り専用（Read-only）かつ必須ではありません。
• 型は変更できません。
• 名前は変更できません。
• ワークフロー内のすべてのフォームから削除しても、（標準のユーザー定義フィールド／変数とは異なり）プロセス定義からは削除されません。

一部の組み込み変数（例：Initiator、<TaskName> executed by）は、他のユーザーフォームで情報として含めるなどして使用できますが、フォーム自体の中ではなく、タスク設定の一部である条件付きフィールドでも使用できます。下の画像は、タスク Prepare review data の完了時に出力として生成される組み込み変数 Prepare review data executed by を示しています。タスクの作業者として許可される人物は、Assignee フィールド内の $Initiator エントリを使用して、プロセスを開始した人物と同一になるよう定義されています。

組み込み変数の例 – Initiator 変数はタスクの担当者（assignee）を定義するために使用され、Prepare review data executed by 変数はタスク完了時に生成されます。

別の例としては、この種の変数を使用してユーザーがタスクに割り当てられるのを防ぐことが挙げられます。下の画像では、マイルストーンレビュー（Milestone Review）プロセスの Verify rework タスクに対する Except フィールドで $Rework executed by 変数が使用されており、直前のタスク（Rework）を実行したユーザーが自分の作業を検証できないようにしています。

組み込み変数を使用して、ユーザーが自分の作業を検証できないようにする例。

以下は、プロセステーマ別の組み込み変数の一覧です。各変数について、名前の後ろの括弧内に型が示されています。

Part Requests

• Initiator（Single Line Text）– 主に Start 要素に関連付けられます。値は、この有効化されたプロセス定義の特定インスタンスを開始したユーザー名です。
• <TaskName> executed by（Single Line Text）– 主に Task 要素（タイプ User Task）に関連付けられます。値は、タスクを実行したユーザー名です。
• Create Part in PLM Status（Dropdown）– 主に Task 要素（タイプ Create Part in PLM）に関連付けられます。PLM 部品作成プロセスの結果です。値は OK または FAIL になります。
• Create Part in PLM Message（Single Line Text）– 主に Task 要素（タイプ Create Part in PLM）に関連付けられます。PLM 部品作成プロセスの結果です。値は単一行のテキストメッセージです。

• Change State Status（Dropdown）– 主に Task 要素（タイプ Change State）に関連付けられます。Change Lifecycle State プロセスの結果です。値は OK または FAIL になります。

• Change State Success（Item/Revision）– 主に Task 要素（タイプ Change State）に関連付けられます。Change Lifecycle State プロセスの結果です。値は、ライフサイクル状態の変更に成功したアイテムリビジョンのリストです。

• Change State Failure（Item/Revision）– 主に Task 要素（タイプ Change State）に関連付けられます。Change Lifecycle State プロセスの結果です。値は、ライフサイクル状態を変更できなかったアイテムリビジョンのリストです。

• Receive <Code> Status（Single Line Text）– 主に Event 要素（タイプ Receive）に関連付けられます。値は、サードパーティシステムの通知レシーバー（例：OK）から提供されるステータスです。
• Receive <Code> Message（Multi Line Text）– 主に Event 要素（タイプ Receive）に関連付けられます。値は、サードパーティシステムの通知レシーバーから提供されるメッセージ（例：エラーメッセージ）です。
• PLM Part Completed Status（Dropdown）– 主に Event 要素（タイプ PLM Part Completed）に関連付けられます。PLM インスタンスから返送される PLM 部品作成プロセスの結果です。値は OK または FAIL になります。
• PLM Part Completed Message（Multi Line Text）– 主に Event 要素（タイプ PLM Part Completed）に関連付けられます。PLM インスタンスから返送される PLM 部品作成プロセスの結果です。値は複数行のテキストメッセージです。
• PLM Part Completed Log（File Upload）– 主に Event 要素（タイプ PLM Part Completed）に関連付けられます。PLM インスタンスから返送される PLM 部品作成プロセスの結果です。値はログファイルへのリンクです。

Project Activities

• Initiator（Single Line Text）– 主に Start 要素に関連付けられます。値は、この有効化されたプロセス定義の特定インスタンスを開始したユーザー名です。
• Start Release Data（Data Set）– 主に Start 要素（タイプ Start Release）に関連付けられます。値は Project Releaser によって生成されたリビジョンのリストです。
• <TaskName> executed by（Single Line Text）– 主に Task 要素（タイプ User Task または Collect Project Data）に関連付けられます。値は、タスクを実行したユーザー名です。
• Publish to PLM Status（Dropdown）– 主に Task 要素（タイプ Publish to PLM）に関連付けられます。PLM 公開初期化プロセスの結果です。値は OK または FAIL になります。
• Publish to PLM Message（Single Line Text）– 主に Task 要素（タイプ Publish to PLM）に関連付けられます。PLM 公開初期化プロセスの結果です。値は単一行のテキストメッセージです。
• Publish to PLM Properties（Properties）– 主に Task 要素（タイプ Publish to PLM）に関連付けられます。PLM 公開初期化プロセスの結果です。値はプロパティのキー／値ペアのテーブルです。

• Change State Status（Dropdown）– 主に Task 要素（タイプ Change State）に関連付けられます。Change Lifecycle State プロセスの結果です。値は OK または FAIL になります。

• Change State Success（Item/Revision）– 主に Task 要素（タイプ Change State）に関連付けられます。Change Lifecycle State プロセスの結果です。値は、ライフサイクル状態の変更に成功したアイテムリビジョンのリストです。

• Change State Failure（Item/Revision）– 主に Task 要素（タイプ Change State）に関連付けられます。Change Lifecycle State プロセスの結果です。値は、ライフサイクル状態を変更できなかったアイテムリビジョンのリストです。

• Receive <Code> Status（Single Line Text）– 主に Event 要素（タイプ Receive）に関連付けられます。値は、サードパーティシステムの通知レシーバー（例：OK）から提供されるステータスです。
• Receive <Code> Message(Multi Line Text) – 主に Event 要素（タイプ：Receive）に関連付けられます。値は、サードパーティシステムの通知レシーバーから提供されるメッセージ（例：エラーメッセージ）です。
• PLM Publish Completed Status (Dropdown) – 主に Event 要素（タイプ：PLM Publish Completed）に関連付けられます。PLM公開（publish）プロセスの結果で、PLMインスタンスから返送されます。値は OK または FAIL になります。
• PLM Publish Completed Message (Multi Line Text) – 主に Event 要素（タイプ：PLM Publish Completed）に関連付けられます。PLM公開（publish）プロセスの結果で、PLMインスタンスから返送されます。値は複数行のテキストメッセージです。
• PLM Publish Completed Log (File Upload) – 主に Event 要素（タイプ：PLM Publish Completed）に関連付けられます。PLM公開（publish）プロセスの結果で、PLMインスタンスから返送されます。値はログファイルへのリンクです。

Project Creations

• Initiator (Single Line Text) – 主に Start 要素に関連付けられます。値は、この有効化されたプロセス定義の特定インスタンスを開始したユーザー名です。
• <TaskName> executed by (Single Line Text) – 主に Task 要素（タイプ：User Task）に関連付けられます。値はタスクを実行したユーザー名です。

• Create Project executed by (Single Line Text) – 主に Task 要素（タイプ：Create Project）に関連付けられます。値は「Create Project」タスクを実行したユーザー名です。

• Create Project Status (Dropdown) – 主に Task 要素（タイプ：Create Project）に関連付けられます。「Create Project」プロセスの結果です。値は OK または FAIL になります。

• Initialise in PLM Status (Dropdown) – 主に Task 要素（タイプ：Initialise in PLM）に関連付けられます。PLMプロジェクト初期化プロセスの結果です。値は OK または FAIL になります。
• Initialise in PLM Message (Single Line Text) – 主に Task 要素（タイプ：Initialise in PLM）に関連付けられます。PLMプロジェクト初期化プロセスの結果です。値は1行のテキストメッセージです。
• Initialise in PLM Properties (Properties) – 主に Task 要素（タイプ：Initialise in PLM）に関連付けられます。PLMプロジェクト初期化プロセスの結果です。値はプロパティのキー・バリューのペアからなる表です。

• Change State Status (Dropdown) – 主に Task 要素（タイプ：Change State）に関連付けられます。「Change Lifecycle State」プロセスの結果です。値は OK または FAIL になります。

• Change State Success (Item/Revision) – 主に Task 要素（タイプ：Change State）に関連付けられます。「Change Lifecycle State」プロセスの結果です。値は、ライフサイクル状態の変更に成功したアイテムリビジョンのリストです。

• Change State Failure (Item/Revision) – 主に Task 要素（タイプ：Change State）に関連付けられます。「Change Lifecycle State」プロセスの結果です。値は、ライフサイクル状態を変更できなかったアイテムリビジョンのリストです。

• Receive <Code> Status (Single Line Text) – 主に Event 要素（タイプ：Receive）に関連付けられます。値は、サードパーティシステムの通知レシーバーから提供されるステータス（例：OK）です。
• Receive <Code> Message (Multi Line Text) – 主に Event 要素（タイプ：Receive）に関連付けられます。値は、サードパーティシステムの通知レシーバーから提供されるメッセージ（例：エラーメッセージ）です。
• PLM Initialise Completed Status (Dropdown) – 主に Event 要素（タイプ：PLM Initialise Completed）に関連付けられます。PLMプロジェクト初期化プロセスの結果で、PLMインスタンスから返送されます。値は OK または FAIL になります。
• PLM Initialise Completed Message (Multi Line Text) – 主に Event 要素（タイプ：PLM Initialise Completed）に関連付けられます。PLMプロジェクト初期化プロセスの結果で、PLMインスタンスから返送されます。値は複数行のテキストメッセージです。
• PLM Initialise Completed Message (File Upload) – 主に Event 要素（タイプ：PLM Initialise Completed）に関連付けられます。PLMプロジェクト初期化プロセスの結果で、PLMインスタンスから返送されます。値はログファイルへのリンクです。

フラグ

フォーム上で定義されたフィールドは、その変数タイプに応じて最大3つのフラグを持てます。

• Editable – このフラグを有効にすると、フィールドを編集可能にできます。たとえば、プロジェクト名の入力、日付の入力、データの追加などが可能になります。
• Required – このフラグを有効にすると、フィールドを必須項目にできます。つまり、タスクを送信するには、ユーザーが選択肢を選ぶかデータを入力する必要があります。
• Reset value – このフラグを有効にすると、フォームに入った時点でフィールド値がリセットされます。既定値が適用可能で、かつ設定されている場合はそれが読み込まれ、そうでない場合はフィールドは空（またはドロップダウンフィールドの場合は Choose option を表示）になります。

フォーム上で定義されたフィールドの例と、それらのフラグ。

表示上、フラグは次のように見える場合があります。

• 青 – フラグは変更可能で、現在有効です。
• 灰 – フラグは変更可能で、現在無効です。
• くすんだ青 – フラグは有効ですが変更できません。
• 非表示 – フラグは適用されません。

フラグを変更できる場合は、クリックして有効/無効を切り替えます。

詳細オプション

変数タイプが追加オプションをサポートしている場合、関連する Advanced options コントロールが表示されます。これをクリックして展開し、内容を確認します。

フォーム上で定義された各種フィールドに対する Advanced options の例。

変数タイプに応じて、ここには次のオプションがあります。

• Keep value provided by each user separately – たとえば設計レビューのように、タスクに関与する複数ユーザーが提出したフォームで入力された値を「プール」するために、そのフィールドを使用できます。
• Dropdown options – タイプが Dropdown の変数について、フィールドに関連付けられたドロップダウンメニューにユーザー選択肢として表示できるエントリをここで定義します。
• Default value – タスクに関連付けられたフォームにユーザーがアクセスした際、フィールド値として「事前入力」表示される既定値を指定します。フィールドが Dropdown タイプの場合、既定値は定義済みの Dropdown options のいずれか、または None に設定できます。
• Value – 通常はタイプが Label の変数向けで、作業中のタスクに関連付けられたフォーム上でユーザーに提示されるラベルテキスト（何をすべきかを説明する文言）を定義します。

フィールドの追加

フォームに新しいフィールドを追加するには、フォーム右下の Add コントロールをクリックします。新しいフィールドはフォームの最下部に追加され、Name ドロップダウンが展開された状態になります。これにより、プロセス定義内の別の場所ですでに定義されている既存変数を選ぶか、新規作成できます。

フォームへの新規フィールド追加例。親プロセス定義で定義済みの既存変数を参照するか、新しい名前を入力して（フォーム保存時に）その定義用の新しい変数を作成できます。

既存の変数を選択した場合:

• その変数への別参照としてフォームに追加されます。
• Name フィールドは標準のテキストフィールドに変わり、名前の編集はできますが、別の変数を選択することはできません。
• フラグは、元の変数の定義内容に従って設定されます。

新しい変数名を入力した場合:

• Name フィールドは標準のテキストフィールドになります。
• 変数の Type を選択できます（既定は Single Line Text）。
• フラグは既定状態に設定されます – 編集可能（有効）、必須（無効）、値のリセット（無効）。
• フォーム保存時に、新しい変数がプロセス定義に追加されます。

フィールドの削除

ユーザー定義フィールドを削除するには、右端の コントロールをクリックします。削除は確認なしで即時に行われます。

フィールドの並べ替え

任意のフィールドは、フィールドにカーソルを合わせたとき左側に表示される コントロールをクリックしてドラッグすることで、フォーム上の任意の位置へ移動できます。これにより、まずフィールドを素早くフォームへ追加し、その後で見た目（フィールド順）を整えることができます。

保存 & デプロイ

必要なプロセスとして定義したら、エディター右上の ボタンをクリックして、そのプロセステーマで利用可能なプロセスの一覧に追加します。新しいプロセス定義は有効化され、すぐに使用できる状態になります。