25 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 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
Use the Included Actions filters on your policies (see Creating and Enabling Approval Policies, Creating and Enabling Commit Policies, and Creating and Enabling Notification Policies) to specify if a policy should triggered only for specific request actions. The type of action that you specify is not affected by the data chain object that the policy is on. For example, you can specify a Move action on a policy for a node type, even though the Move action is a hierarchy set action. When you do so, the policy will be triggered for all Moves in all hierarchy sets for that node type.
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.
Policies and Permissions
You must have Owner or Metadata Manager 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.