ワークフロー・ステージ

ワークフロー・ステージは、ワークフロー・モデルごとに定義され、ワークフロー・モデル間で共有できません。

ステージのタイプ

ステージがワークフロー・モデルに割り当てられると、ステージ・タイプ属性は、ワークフローのそのステージにおけるユーザーに対して、参加のタイプを定義します。

表16-1 ワークフロー・ステージのタイプ

ワークフロー・ステージのタイプ	説明	アクション・タイプ
送信	送信ページは、要求に含める最初の要求アイテムの定義に使用されます。このステージ・タイプには、複数のワークフロー・タスクを関連付けられます。送信ステージ中に、少なくとも1つの要求アイテムを要求に追加する必要があります。「リーフの追加」または「リムの追加」タスクは、必要に応じて依存ワークフロー・タスクを使用して構成できます。システムで元のワークフロー・タスクに対する要求アイテムおよび各依存タスクに対する追加の要求アイテムが追加されます。プライマリ・タスクが依存タスクでもあることはできません。プライマリ・タスクで追加アイテムの名前を計算する場合、プライマリ・タスクおよび依存タスクは関連するグループと見なされます。名前の計算が保留中の間にプライマリ・タスクを削除すると、追加以外の依存タスクも削除されます。ノート: 各要求の送信ステージは1つのみです。このステージのワークフロー・ステージ基準は定義できません。	リムの追加リーフの追加更新非アクティブ化挿入移動除去削除
エンリッチ	エンリッチ・ステージは、送信ステージで追加された要求アイテムの更新、または要求アイテムの追加に使用されます。このステージのワークフロー・ステージ基準は定義できます。エンリッチ・ステージには、関連付けられた単一のワークフロー・タスクがあります。一般的なエンリッチ・ステージでは、既存の要求アイテムの更新アクションを含むワークフロー・タスクを使用します。ただし、エンリッチ・ステージでは、たとえば次のような追加のライン・アイテムを作成する必要がある場合があります: 複数の階層への単一ノードの挿入複数の階層での単一ノードのローカル・プロパティの更新このステージは、送信ステージとコミット・ステージの間で発生します。ノート: ワークフロー・モデルには、任意の数のエンリッチ・ステージを定義できます。	更新(既存の要求アイテム) 挿入(新規アイテムの追加) 移動(新規アイテムの追加) 送信ステージで使用できるすべてのアクション・タイプ
承認	承認ステージは、送信ステージで追加されたか、エンリッチ・ステージで追加または更新されたすべての要求アイテムを表示および承認するために使用されます。ユーザーは、承認ステージ中に要求アイテムを追加または編集できません。このステージのワークフロー・ステージ基準は定義できます。承認ステージでは単一のワークフロー・タスクを使用して、要求がステージにある間に、要求アイテムのプロパティを表示して検証を実行します。更新タスクは、承認ステージで読取り専用モードで使用できます。中間ステージにある要求アイテムのプロパティを更新するには、かわりにエンリッチ・ステージ・タイプを使用します。このステージは、送信ステージとコミット・ステージの間で発生します。ノート: ワークフロー・モデルには、任意の数の承認ステージを定義できます。	更新(既存の要求アイテム)
コミット	コミット・ステージは、ターゲット・バージョンへの要求で要求アイテムのコミットをトリガーする際に要求の最終承認を行うために使用されます。コミット・ユーザーは、要求でのすべての要求アイテムを承認する必要があります。このステージのワークフロー・ステージ基準を定義することはできますが、このステージで要求を分割することはできません。コミット・ステージには、関連付けられたワークフロー・タスクはありません。かわりに、コミット・ステージでは、プロパティのスーパーセットを表示し、前の送信ステージおよびエンリッチ・ステージの要求アイテムで使用できる検証のスーパーセットを実行します。コミット・ステージにおけるユーザーは、最終調整を許可するために要求アイテムに対して表示される、編集可能なプロパティへの更新を行うことができます。これは、最後のワークフロー・ステージです。ノート: 各要求のコミット・ステージは1つのみです。	N/A

ステージ条件

ステージ条件を使用して、要求内のアイテムについて評価された特定の条件に基づいて、特定の要求のワークフロー・パスを変更できます。ステージの条件を設定し、条件が満たされた場合に行うべきアクションを選択します(要求がステージに入ることができるかどうか、または一部の要求アイテムを別の要求に分割するかどうかなど)。ワークフロー・ステージの条件は、次の基準に基づいて評価できます。

プロパティ基準––プロパティの問合せ演算子とリテラル値を使用し、ステージのステージ基準として評価します。
選択した検証––ステージのステージ基準として実行する1つ以上の検証を選択します。このオプションは、承認、エンリッチまたはコミット・ステージで選択できます。
タスク検証––ワークフロー・タスクに割り当てられている検証の失敗。選択した場合、タスクに割り当てられている検証も、ステージのステージ基準として実行されます。このオプションは、承認またはエンリッチ・ステージで選択できます。このオプションは、ステージに割り当てられたタスクに検証が割り当てられていない場合は使用できません。

いずれかの要求アイテムがワークフロー・ステージのステージ条件を満たしている場合、次のいずれかのアクションが行われます。

ステージの入力––承認、エンリッチまたはコミット・ステージの場合、ステージでユーザーに要求が割り当てられます。要求がステージに入り、そのステージのワークフロー処理が続行されます。
要求アイテムの分割––承認またはエンリッチ・ステージの場合、ステージ条件を満たす要求アイテムは、同じワークフロー・モデルを使用する別の送信済要求に移動されます。新しい要求がワークフロー・ステージに入り、ステージでユーザーに割り当てられます。ステージ条件を満たさないアイテムは、元の要求にとどまり、ステージは元の要求でスキップされます。すべての要求アイテムがステージ基準を満たす場合、要求は分割されず、「分割」ステージに入ります。

要求アイテムがワークフロー・ステージのステージ条件を満たさない場合、そのステージはスキップされ、要求はワークフロー・モデルの次のステージに移動します。

承認方法

要求でステージを承認するユーザーを選択します。

任意のグループ--割り当てられたノード・アクセス・グループの任意のユーザーは、次のワークフロー・ステージに進めるために要求を承認できます。ノード・アクセス・グループを、現在のステージ・タイプまたはそれを超えるステージ・タイプへのアクセス権がある階層に割り当てる必要があります。ステージに割り当てられたいずれのアクセス・グループにも、要求内の要求アイテムへの適切なデータ・アクセス権がない場合、必要な値が指定され、すべての要求アイテムに対する検証が成功しているかぎり、ステージはスキップされます。
すべてのグループ--割り当てられたすべてのノード・アクセス・グループのうち少なくとも1つのユーザーが、次のステージに進む前に要求を承認する必要があります。ステージに割り当てられたいずれのアクセス・グループにも、要求内の要求アイテムへの適切なデータ・アクセス権がない場合、その要求はデータ・マネージャにエスカレートされて解決されます。

再承認

要求を前のステージに戻し、戻す間に要求アイテムが変更される場合、その要求への変更は、元の要求に対する最初の承認を行ったユーザーによって再承認される必要があります。このオプションによって、戻す間に各ステージで行われた変更が他のユーザーによって再承認される必要があるかどうかが決まります。次のいずれかのオプションを選択してください:

現在--このステージでの要求への変更は、現在のステージでのみ再承認される必要があります。承認後、要求は、前に要求を戻したユーザーに割り当てられます。
すべて--このステージでの要求への変更は、後続のステージで再承認される必要があります。

業務の分割

オプションで、要求の他のステージに対する送信または承認を行っていない、別の承認するユーザーを必要とするように、ワークフロー・ステージを構成できます。「業務の分割」オプションが有効な場合、他のワークフロー・ステージに対する送信または承認を行ったユーザーは、このオプションが有効なステージで要求を請求できないことがあります。次の例外に注意してください。

送信者は、送信ステージに戻された要求を請求できます。
ステージの前の承認者は、承認またはエンリッチ・ステージに戻された要求を請求できます。
データ・マネージャの役割を持つユーザーは、前の承認に関係なく、割り当てられた要求を請求できます。

通知

通知には、Webクライアント・アラートと電子メール通知の両方が含まれます。ワークフロー・ステージのワークフロー・ユーザーへのアラートおよび通知の送信の有無および時期を設定できます。通知は、ステージの通知設定および通知をトリガーしたワークフロー・イベントのタイプに基づいて、特定のユーザーにフィルタされます。

注:

ユーザーが実行したアクションに関する通知は送信されません。

ステージごとに、次の「通知」オプションの中から選択します:

なし--このワークフロー・ステージに対して実行されたアクションについて、ユーザーは通知されません。
担当者––要求に現在割り当てられているいずれかのワークフロー・ノード・アクセス・グループに属するユーザーは、割当て、承認、コミットまたは却下のアクションが発生したときに通知されます。

担当者は、通知設定が「担当者」または「担当者および参加者」のステージに割り当てられているワークフロー・アクセス・グループのメンバーである場合にのみ通知されます。
参加者
- コミットまたは却下アクションが発生した場合は、要求を送信または請求したユーザーに通知されます。
- 承認または上位へ移動アクションが発生した場合は、要求を送信したユーザーに通知されます。
参加者は、通知設定が「参加者」または「担当者および参加者」のステージに割り当てられているワークフロー・ノード・アクセス・グループのメンバーである場合にのみ通知されます。
担当者および参加者--担当者と参加者が通知されます。

次の表に、各ステージの通知設定に基づいて通知をトリガーするアクションおよび通知の受信者をリストします。

表16-2 ワークフロー・アラート

ワークフロー・アクション	通知の送信先
ワークフロー・アクション	担当者	送信者	参加者	通知ユーザー
割当て	X
承認	X	X		X
上位へ移動		X		X
エスカレート	X			X
却下	X		X	X
コミット	X		X	X

注:

通知ユーザーとは、要求アイテムへの通知アクセス権のみを持つ、ステージに割り当てられているワークフロー・ノード・アクセス・グループのメンバーであるユーザーです。これらのユーザーは、通知設定が「担当者」または「担当者および参加者」の場合のみ通知されます。通知オプションが「なし」または「参加者」の場合、これらのユーザーは通知されません

依存ワークフロー・タスク

依存ワークフロー・タスクを使用して、別のタスクの実行時にガバナンス要求でワークフロー・タスクを自動的に実行できます。たとえば、ノードを追加するとき、他の階層にもノードを挿入し、要求のコミット時にすべての階層で同期されるようにすることができます。「リーフの追加」および「リムの追加」アクション・タイプを使用してプライマリ・ワークフロー・タスク用に依存タスクを構成できます。

要求アイテムを要求に追加する際、アイテムに対して選択したタスクがプライマリ・タスクです。プライマリ・タスクが依存タスクを使用して構成されている場合、追加要求アイテムが各依存タスクの要求に自動的に追加されます。