21 Configuring Policies

You can set up policies at the application, dimension, node type, or hierarchy set level. Approval policies are applied during the Approve workflow stage, and they enable approvers to review requests and approve or reject their contents. Commit policies are applied during the Commit workflow stage, and they enable a user on the commit policy to do a final review and commit of all changes in a request. Notification policies are applied at the Closed workflow stage when a request is committed, and they enable users to receive email notifications when a completed request is submitted by other users.

For more information, see

Policies and Data Objects

Policies are enabled at the application, dimension, hierarchy set, or node type level. As with permissions, policies propagate from applications to dimensions, and then to hierarchy sets and node types. That is, a policy that is configured on an application will be applied to all of the dimensions in that application, and policies configured on dimensions will apply to the node types and hierarchy sets in that dimension. See Permission Inclusion and Cascading for more information.

Note:

You can run a report to determine the polices that have been assigned across all applications. For more information, see Working with Reports.

Policies and Request Actions on Data Objects

The data object that you enable a policy on determines the request actions that will require approvals or generate notifications:

  • If you enable a policy on an application or a dimension, approvals will be required or notifications will be generated for any request action.
  • If you enable a policy on a node type, approvals will be required or notifications will be generated for requests in which nodes are added or deleted, or in which the node properties are updated.
  • If you enable a policy on a hierarchy set, approvals will be required or notifications will be generated for requests in which nodes are inserted, moved, removed, or reordered in a hierarchy set, or in which node relationship properties (such as Parent) are updated.

The following diagram shows policies on data objects and the actions that will require approvals or generate notifications for each policy.


diagram shows application, dimension, node type, and hierarchy set policies with the actions listed above

Propagating Policies on Data Objects

Policies propagate from higher level objects (such as applications) to lower objects in a data chain (such as dimensions, node types or hierarchy sets). A data chain object may be affected by policies directly enabled for it as well as propagating policies from objects above it in the data chain. In this case, each policy is evaluated independently.

To illustrate this, suppose you have the following approval policies enabled:

  • An approval policy at the application level requires three approvers from Accounting.
  • An approval policy at the dimension level requires four approvers from Accounting.

These policies do not get combined, so a total of seven approvers from Accounting are required. Instead, each policy is evaluated separately, and since both policies require approval from the same Accounting group, the first three approvals from Accounting are applied to both policies, as follows:

  • The application-level policy is satisfied when three approvers from Accounting approve the request.
  • The dimension-level policy is satisfied when one additional approver from Accounting approves the request.

Note:

If an approver is in multiple approval groups, they approve a request only once. That approval will count for all approval policies that the user is a member of. For example, if Barry is a member of both the Accounting group and the Cost Center group, and an approval policy states that two approvals from each group are required, Barry's approval counts as one approval from each group.

Multiple Policies for the Same Data Object

You can define multiple policies for the same data chain object to allow different users to approve or be notified for different types of requests. Additional policies can be created with different filters to handle conditional approvals or notifications of specific data sets by different users. For example, the following diagram illustrates a dimension with two policies:

  • An accounting policy sends approval requests or notifications to the Accounting group if bottom level nodes are added, updated, or deleted
  • A budgeting policy sends approval requests or notifications to the Finance group if nodes are inserted, moved, or updated.

diagram shows the policies described in the previous list

Policies and Permissions

You must have Owner permission on a data object in order to configure a policy for that object.

When you add an user or group to a policy for a data object, that user or group is granted implicit Participant (Read) permission on that data object. Because permissions propagate, if you add a user or group to a policy for an application or a dimension, that user or group is also granted implicit Participant (Read) permission to the data chain objects that the application or dimension contains (dimensions, node types, and hierarchy sets).

When a user or group is added to a policy and granted implicit Participant (Read) permission on a hierarchy set, they are also granted implicit Participant (Read) permission on the node type used in that hierarchy set. This enables them to open a view and browse the hierarchy set when approving or viewing completed requests. However, granting users implicit Participant (Read) permission on a node type by adding them to a policy does not grant them implicit Participant (Read) permission on any hierarchy sets that use that node type. If a user has Participant (Read) permission on a node type but not a hierarchy set, they are unable to open the view and browse the hierarchy set in the viewpoint to approve or view the request. Instead, they must approve the request in the Request Inspector.

If you remove a user from a policy, that user's implicit Participant (Read) permission on the data object in that policy is revoked, but they retain any permissions that were explicitly granted to that data object. See Working with Permissions.

Note:

If a user’s name is changed in Access Control, that user becomes invalid and can no longer participate in any policies that they were assigned to.