Search In: Doc:Documentation: Altium On-Prem Enterprise Server
Altium DesignerAltium 365Altium MCAD CoDesignerAltium On-Prem Enterprise ServerCompany DashboardAltium Infrastructure Server
Ver: Version: 5.5
8.07.27.17.06.05.5
Close
検索 Search on Documentation

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

Created: 8月 10, 2022 | Updated: 8月 12, 2022 | Applies to version: 5.5
現在、バージョン 5.5. をご覧頂いています。最新情報については、バージョン プロセスワークフローの定義 の 8.0 をご覧ください。
 

Parent page: プロセス＆ワークフロー

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

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

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

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

インターフェースのProcesses領域を表示するには、Workspace の管理者としてサインインしている必要があります。

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

先にテーマをアクティブにしておくことが重要です。これにより、プロセスが正しいTypeで作成されます。

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

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

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

ワークフロー図

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

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

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

アイコン タイプ 説明
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プロパティにより、新規プロジェクトを保存するベースフォルダパスを指定できます。定義すると、このワークフローの既定の場所となり、ユーザーは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プロパティにより、新規プロジェクトを保存するベースフォルダパスを指定できます。定義すると、このワークフローの既定の場所となり、ユーザーはNew ProjectフォームのServer Folderフィールド（Advancedタブ）で上書きできます。
この要素のタイプ切り替えについて詳しくは、Changing the Type for a Workflow Elementを参照してください。
Branch この要素は、フローの前段で取得した結果（例：ユーザーの選択や判断の取得）に応じてワークフローを分岐させます。既定ではNameは空欄です。
Comment この要素を使うとワークフローにコメントを付けられます。通常はフローの各ポイントにコメントを追加し、その地点で何が起こるべきかを詳細に記述します。既定ではNameは空欄です。

ワークフロー要素の配置

パレットから要素を配置するには：

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

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

ワークフロー要素の接続

2つのワークフロー要素を接続するには：

  1. パレットのエントリをクリックします。
  2. 接続する最初の（ソース）要素の上にカーソルを合わせてクリックします。
  3. カーソルを動かすと、要素から接続線が伸び始めます。接続する2つ目の（ターゲット）要素の上にカーソルを合わせてクリックします。
要素間の接続は、論理的なフローに従い左から右へ流れるようにする必要があります。無効と判断される接続先要素は選択できません（例：End要素をStart要素に接続しようとする場合）。その場合、ターゲット要素は赤く塗りつぶされ、接続線の端には「禁止」アイコン（）が表示されたままになります。
  1. さらに接続を配置し続けるか、右クリックするか、Escを押して終了します。

ワークフロー内での要素接続例。
ワークフロー内での要素接続例。

ワークフロー要素の移動

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

複数の要素を移動するには、まずそれらを選択します。Ctrl+クリックで必要な要素を1つずつ選択するか、クリックしてドラッグし、選択ボックスでそれらの要素を囲みます。

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

接続の変更

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

  • ハンドルをクリックしてドラッグすると、接続を垂直方向にのみ移動します。
  • ハンドルをクリックしてドラッグすると、接続を水平方向にのみ移動します。
  • 接続に沿ってカーソルを移動すると、 ハンドルがカーソルに追従します。このハンドルをクリックしてドラッグすると、接続に新しい頂点（折れ点）を作成します。
  • ハンドルをクリックしてドラッグすると、接続の始点を移動します。この点は別の既存要素の上へドラッグする必要があります。
  • ハンドルをクリックしてドラッグすると、接続の終点を移動します。この点は別の既存要素の上へドラッグする必要があります。
接続の始点または終点を移動する際、無効なドロップ先は、要素が赤く塗りつぶされ（さらに接続端に アイコンが表示される）ことで強調表示されます。これは例えば、接続の始点を、その接続の終点がすでに接続されている同一要素へ移動しようとした場合に起こり得ます。この場合は、先に終点を移動してから、始点を移動してください。
さらに、接続は、現在接続されている要素が移動された場合、その要素との接続を維持するために経路が自動的に調整されます。

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

要素プロパティの変更

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

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

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

なお、ワークフロー要素が何も選択されていない場合、Properties ペインには親となるプロセス定義自体のプロパティが表示されます。また、ワークフロー要素が未選択の状態では、プロセスワークフローの Data タブで標準ユーザーに表示されるパラメトリックデータを設定できます。詳細は Configuring Data Visibility for a Standard User を参照してください。
Comment は、選択して編集ハンドルをクリック＆ドラッグすることで、サイズに関してもグラフィカルに変更できます。

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

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

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

もちろん、要素を選択した状態で Properties ペイン内の Type フィールドに関連付けられたドロップダウンからタイプを変更することもできます。

タスクの割り当て

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

  • Assignee – Workspace の単一ユーザー、複数ユーザー、または特定のロール（ユーザーのグルーピング）を指定できます。ここでも変数を使用できます。例えば $Initiator（プロセスインスタンスを開始した人）や、$Review Coordinator（前のタスクで Review Coordinator として選択されたユーザー）などです。
変数はテキストとして直接入力するのではなく、動的に提示される候補リストから検索して選択します。例えば $Initiator 変数を追加するには、フィールドに In と入力し始め、リストから該当エントリを選択します。
  • Except – 割り当て対象の範囲に含まれていても、そのタスクを実行できないユーザーを指定します。例えば、部品のリクエスト者が自分の部品リクエストを承認してはいけません。別の例として、マイルストーンレビューの Verify rework タスクに対して Except フィールドで $Rework executed by 変数を使用し、直前のタスク（Rework）を実行したユーザーが自分の作業を検証できないようにする、といった使い方があります。
  • Task ownership – Assignee フィールドで指定されたユーザーに対して、誰がタスクを実行できるかを決定します。次のオプションがあります:
    • One of assigned users – Assignee フィールドにユーザーが1人だけの場合、リクエスト対応の最初のタスクはそのユーザーに直接割り当てられます。割り当て先が複数の場合、全員のタスクリストにタスクが表示され、そのうちの1人がタスクを自分に割り当てます。
    • All assigned users – すべての割り当て先がタスクを受け取ります。

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

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

部品リクエストの元の提出者がリクエスト作業をできないようにしたい場合は、Except フィールドに変数 $Initiator を入力します。

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

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

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

この機能は、標準（非管理者）ユーザーが見える内容にのみ影響します。管理者として Workspace にサインインしている場合は、設定に関係なくすべてのデータが表示されます。

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

ワークフロー要素の削除

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

フォームの作成

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

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

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

  • Start（Part Requests テーマ）– 既存のフォームに デフォルトフィールド が用意されています。これらは編集または削除でき、該当する場合はデフォルト値を定義できます。必要に応じて追加フィールドを追加できます。
  • Start タイプ Start Activity（Project Activities テーマ）– 既存のフォームに 組み込みフィールド が用意されています。これは削除できません。必要に応じて追加フィールドを追加できます。
  • Start（Project Creations テーマ）– 既存のフォームに 組み込みフィールド が用意されています。これらは削除できません。該当する場合はデフォルト値を定義できます。必要に応じて追加フィールドを追加できます。
  • Task タイプ User Task（すべてのプロセステーマ）– 既存のフォームはありません。必要に応じて作成してください。
  • Task タイプ Collect Project Data（Project Activities テーマのみ）– 既存のフォームに 組み込みフィールド が用意されています。これは削除できません。必要に応じて追加フィールドを追加できます。
  • Task タイプ Create Project（Project Creations テーマ）– 既存のフォームに 組み込みフィールド が用意されています。これらは削除できません。該当する場合はデフォルト値を定義できます。必要に応じて追加フィールドを追加できます。

ユーザーフォームエディタ

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

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

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

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

以降のセクションでは、変数とフィールドのサポート、各フィールド／変数に関連付けられたフラグ、フォーム内での作業、組み込み／デフォルトのフィールドおよび変数など、User Form Editor の仕組みを見ていきます。

変数とフィールド

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

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

フラグ

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

  • Editable – このフラグを有効にすると、フィールドを編集可能にします。たとえば、プロジェクト名の入力、日付の入力、データの追加などができるようになります。
  • Required – このフラグを有効にすると、フィールドを必須項目にします。つまり、タスクを送信するために、ユーザーは選択肢を選ぶかデータを入力する必要があります。
  • Reset value – このフラグを有効にすると、フォームに入った時点でフィールドの値がリセットされます。既定値が適用可能で設定されている場合はそれが読み込まれ、そうでない場合はフィールドは空（またはドロップダウンフィールドの場合は Choose option を表示）になります。
これは「ループ」を含むワークフローで非常に有用です。例として、部品リクエストのプロセスワークフローで、ユーザーがリクエストを検証し、Next step フィールドを Needs more info に設定するケースが挙げられます。申請者が情報を追加すると、それが（ここがループ）検証のために戻ってきます。Next step フィールドで Reset value フラグが有効になっている場合、フィールドはリセットされ、Needs more info が事前入力された状態ではなくなります。そのため、検証者は意識的にそのフィールドの値を選択する必要があります。
Supported Variable Types の表に戻り、各変数タイプに対してこれら 3 つのフラグが適用可能かどうかを確認してください。

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

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

  • Blue – フラグは変更可能で、現在アクティブです。
  • Grey – フラグは変更可能で、現在非アクティブです。
  • Dimmed Blue – フラグはアクティブですが変更できません。
  • Not Displayed – フラグは適用されません。

フラグを変更できる場合は、クリックしてアクティブ状態を切り替えます。

フィールドは、先に Editable にしない限り Required にすることはできません。

詳細オプション

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

Form 上のさまざまな定義済みフィールドに対する Advanced options の例。Form 上のさまざまな定義済みフィールドに対する Advanced options の例。

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

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

フィールドの追加

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

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

現在の Form ですでに使用されている変数はドロップダウンメニューに含まれません。ユーザー Form 上では 1 つの変数につき 1 インスタンスしか置けないためです。入力に応じて変数リストはフィルタリングされるため、必要に応じて既存変数へ素早く到達できます。

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

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

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

  • Name フィールドは標準のテキストフィールドになります。
  • 変数 Type を選択できます（既定は Single Line Text）。
  • フラグは既定状態として設定されます – Editable（アクティブ）、Required（非アクティブ）、Reset value（非アクティブ）。
  • 新しい変数は Form の保存時にプロセス定義へ追加されます。
フィールド名を変更するには、Name フィールド内をクリックして必要に応じて修正します。フィールド名を変更できない場合、Name はグレー表示になり、フィールドにカーソルを合わせると アイコンが表示されます。

フィールドの削除

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

ユーザー定義フィールドは現在の Form からのみ削除されます。ワークフロー内の別の Form でそのフィールド／変数が使用されている場合、プロセス定義としては引き続き定義されたままです。すべての Form から削除されたときにのみ、そのプロセス定義の定義済み変数リストからも削除されます。

フィールドの並べ替え

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

保存 & デプロイ

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

エディタは、保存およびデプロイを妨げているワークフロー図の問題を通知します。たとえば、図には Start イベントが必要で、少なくとも 1 つの End イベントが定義されていなければなりません。また、User Task には少なくとも 1 つの Form フィールドと Assignee が必要です。
AI-LocalizedAI で翻訳
問題が見つかった場合、文字/画像を選択し、Ctrl + Enter キーを押してフィードバックをお送りください。
Content