Understanding Policy Order

You can assign priorities to approval and commit policies by specifying the order in which the policies are executed. When a request is approved or committed, policies with the same order are fulfilled as a group before moving on to the next group.

For example, you can assign policy orders so that enrichment policies take place before approval policies, or node type policies are enforced before dimension policies.

You specify the policy order on the Definition tab of an approval or commit policy. (See Creating and Enabling Approval Policies).

Policy Order Processing

When a request with multiple policies enters the approval or commit stages, the following processing takes place:

1. Approvals (or commits, in the Commit stage) for all policies with a policy order with the lowest order (for example, 1) are processed as a group. Invites to approve (or commit) are sent to all invitees in all of the policies that group.
2. When all of the policies with the lowest policy order have been fulfilled, policies with the next highest sequential policy order (for example, 2) are processed as a group. Invites are sent to all invitees in the current group, as well as any unfulfilled policies in any earlier groups (to account for an unfulfilled policy being modified to a lower number while the request is being processed).

   Note:

   If a current invitee has already provided an approval or commit earlier in the policy order, that user auto-approves for each of their policies in the current group.
3. Policies are processed in groups by policy order number until no policies remain unfulfilled.
4. The request moves to the next stage (for example, if the request was in the Approval stage and there are Commit policies, the request is moved to the Commit stage).
5. Policies with the lowest number policy order in the Commit stage are processed as a group, and so on.
6. When there are no stages remaining, the request is attempted to be completed and closed.

Request Enrichment and Policy Order

If a request is enriched in a way that activates a policy, the new policy will be included in the next workflow cycle according to its policy order. In other words, if a request is enriched with data that is affected by policies in a group earlier than the current group (for example, policies that were not initially activated or policies that have already been approved), invitees for all of the policies in that earlier group are invited to approve the request along with the invitees in the current group.

As an example, suppose you had three groups of policies ordered 1, 2 ,and 3:

1. A request is submitted with data that is affected by the policies in groups 1 and 3, but not 2.
2. The policies in group 1 are fulfilled, but during the processing of group 3, the request is enriched to include data that is affected by the policies in group 2.
3. Invitees in group 2 are included along with the current invitees in group 3. All policies from groups 2 and 3 must now be fulfilled before the request can transition to the next stage.

Request Pushback, Recall, and Withdrawing Approvals

The request stage changes resulting from pushback, recall, and withdrawing approvals is handled as follows:

• For request pushback or recall, all approvals are cleared. When the request enters the approval or commit stage again, the policy order begins again at the lowest order.
• When approvals are withdrawn from a request, approvals that occurred before the withdrawn approval are retained, and approvals that occurred after the withdrawn approval are cleared. For example, if an approval was withdrawn in policy group order 2, approvals from policy group order 1 are retained and approvals from policy group order 3 are cleared.

  For approvals in the same policy group as the withdrawn approval:

  • If the withdrawn approval is in a serial policy, approvals after the withdrawn approval are cleared.
  • Approvals before the withdrawn approval in a serial policy and all approvals in parallel policies are retained.

Viewing the Policy Execution Plan

The Policy tab of the request inspector displays an execution plan of the policies on a request. See Policy Execution Plan.