Understanding Management Hierarchy Approvals

The Management Hierarchy approval method enables you to invite approvers based on the management hierarchy of the request submitter.

When creating the approval policy you select a hierarchy node set from a Users application that contains your management hierarchy. Then, after a request is submitted the request submitter's parent is invited to approve the request. When that user approves the request, the policy continues up the management hierarchy until the policy is fulfilled.

Considerations

  • You can configure the Management Hierarchy method on Approval policies only. You cannot configure it on Commit or Notification policies.
  • The node set that you select for the management hierarchy must meet the following conditions:
    • It must be from a Users application. (See Working with Users Applications)
    • It must be a hierarchy node set and not a list node set (that is, the node set must have an associated hierarchy set).
    • It cannot support shared nodes.
  • The users in your management hierarchy must be assigned at least Participant (Read) permission on the viewpoint associated with the policy in order to be able to approve the request. See Security for Views and Viewpoints.

    Note:

    Unlike node owners in a policy using the Ownership approval method, users that do not have at least Participant (Read) permission on the viewpoint cannot approve requests via the request inspector. Instead, if a user in the management hierarchy does not have the appropriate permission, the request is escalated. See Policy Reminders and Escalations.
  • Use the Fulfillment Type setting to determine how the management hierarchy policy is fulfilled:

    • Fixed: The policy is fulfilled after a specified number of approval levels has been met.
    • Variable: The policy is fulfilled when a specified fulfillment expression returns a value of True. The node context of the expression is of User type.

    For example, you could use a Fixed setting of 2 to specify that the policy is fulfilled when the request submitter's parent and the next higher ancestor in the hierarchy approves the request, or you could use the Variable setting to specify that the policy is fulfilled when an approval is received where the CoreStats.Level property on the hierarchy node is greater than 2.

Request Processing

For Management Hierarchy policies, invitees and policy fulfillment are calculated based on the node structure of the management hierarchy node set. When a request with a Management Hierarchy policy reaches the Approve stage:

  1. The Management Hierarchy node set is evaluated and the node associated with the request owner is located.
  2. The user associated with the parent node of the request owner node is invited to approve the request.
  3. When each invitee approves the request, the policy is evaluated for fulfillment:
    • If Fulfillment Type is Fixed, the policy is fulfilled if the number of approvals specified by the Fulfillment Levels setting has been met.
    • If Fulfillment Type is Variable, the Fulfillment Expression is evaluated and the policy is fulfilled if the expression returns True.
  4. If the policy is fulfilled, the request advances to the next stage. If the policy is not fulfilled, the next higher ancestor in the node set is invited to approve the request.

Request Escalation

Requests are escalated if any of these conditions are true:

  • There is no valid User type hierarchy node set associated with the policy.
  • The request owner is not found in the management hierarchy.
  • The invitee is not a valid user in Oracle Enterprise Data Management Cloud (that is, the EDM User property on the user does not equal True. See Predefined Properties for Users Applications).
  • The invitee does not have at least Participant (Read) permission on the viewpoint associated with the policy.
  • The top node invitee has approved the request but the policy is not fulfilled. For example, the policy requires five approval levels but there are only four levels in the hierarchy chain.
  • The invitee is out of office or does not have an email address configured.