ワークフロー › ポリシーベース ワークフロー › ポリシー順序 › ポリシー順序の例

ポリシー順序の例

この簡単な例では、ポリシーの順番付けがどのように機能するかを示しています。 この例では、ポリシールールが常に評価されていることを前提としてます。

あるイベントに、常に評価される複数のポリシーがある場合に、そのイベントそのものを承認するためには、すべてのポリシーを承認する必要があります。 ただし、イベントに関連付けられているポリシー評価タイプ「ALWAYS」のポリシーが 1 つ拒否されると、イベント自体も拒否されます。

注: イベントに関連付けられているポリシーの評価タイプが「Onchange」の場合、そのポリシーに含まれる属性に関連付けられた変更のみが拒否されます。 イベント自体は拒否されず、次のポリシーが評価されます。

この例では、Policy1、Policy2、および Policy3 すべてのポリシー評価タイプは「ALWAYS」です。 Policy1 は False と評価され、Process1 と名付けられたワークフロー プロセスは実行されず、User1 の作業アイテムは生成されません。 イベント制御は、即座に Policy2 に渡されます。 Policy2 および Policy3 は、両方とも True と評価されました。 優先度が高いため、ワークフロー Process2 が最初に実行され、User2 の作業アイテムが生成されます。

User2 がその作業アイテムを承認すれば、ワークフロー Process3 が実行され、User3 の作業アイテムが生成されます。次に、User3 がその作業アイテムを承認することで、イベントそのものが承認されます。 これらのアクションを、以下のテーブルに示します。

しかし、User2 がその作業アイテムを拒否する場合には、イベントそのものが拒否され、次の表に示すように、User3 には作業アイテムは生成されません。

次に、Policy1、Policy2、および Policy3 すべてのポリシー評価タイプは「ONCHANGE」です。 User2 が作業アイテムを拒否した場合、Policy2 に含まれる属性に関連した変更のみが拒否されます。 次に Policy3 が評価され、Workflow Process3 の実行および作業アイテムまたは User3 の生成が行われます。 User3 が作業アイテムを拒否した場合、このイベントへのすべての変更が拒否されるため、イベントは拒否されます。 User3 が作業アイテムを承認した場合、イベントは承認され、Policy3 に含まれる属性の変更は永続化されます。