Approval Policy Examples

The following examples illustrate approval policies at the application, dimension, node type, and hierarchy set levels and demonstrate how the approvals are processed using various policy settings.

Example 1: Application Level Approval Policy

First, let's look at a simple example to show how approvals work on a basic level. In this example, there is an approval policy at the application level that states that at least two people from the GL Govern group must approve all changes to the chart of accounts.

Table 25-1 Example 1: Application Level Policy Settings

Fusion GL Application	Dimension	Node Type	Hierarchy Set
Policy A Approval groups: GL Govern Method: Parallel Total Required: 2 approvers	Account dimension	Account node type	Account hierarchy set

The GL Govern group consists of Barry, Julie, and Jane. Tom is the owner of the Fusion GL application.

Approval workflow:

1. Mark submits a request to add an account and update a cost center description.
2. Because the approval method is parallel, a request is sent to all three members of the GL Govern group for approval.
3. Julie approves the request.
4. Barry approves the request.
5. The policy requirements are met, and the request is committed.

Example 2: Deadlock Escalation

Now, let's look at that same example again, but this time, Barry and Jane have been transferred out of the GL Govern group.

Table 25-2 Example 2: Deadlock Escalation Policy Settings

Fusion GL Application	Dimension	Node Type	Hierarchy Set
Policy A Approval groups: GL Govern Method: Parallel Total Required: 2 approvers	Account dimension	Account node type	Account hierarchy set

The GL Govern group consists only of Julie. Tom is the owner of the Fusion GL application.

Approval workflow:

1. Mark submits a request to add an account and update a cost center description.
2. An approval request is sent to Julie.
3. Julie approves the request.

   Although the policy requires two approvers from the GL Govern group, Julie is the only person in that group. Since there are no more approvers available to meet the policy requirements, this results in a deadlock. As a result, the request is escalated to users who have Data Manager permission on the application. Because Tom is the owner of the application, his Owner permission includes the Data Manager permission.

4. The request is escalated to Tom.
5. Tom approves the request.
6. The policy requirements are met, and the request is committed.

Example 3: Dimension Level Serial Approval Policy

Next, let's look at a serial-type policy at the dimension level. In this example, Josh must approve the request, then Frank, and finally someone from the Accounting group.

Table 25-3 Example 3: Dimension Level Serial Policy Settings

Application	Dimension	Node Type	Hierarchy Set
Planning application	Account dimension Policy A Approval groups: Josh, Frank, Accounting Method: Serial Total Required: 3 groups	Account node type	Account hierarchy set

The Accounting group consists of James and Heather.

Approval workflow:

1. Mark submits a request to move three accounts.
2. An approval request is sent to Josh.
3. Josh approves the request.
4. An approval request is sent to Frank.
5. Frank approves the request.
6. Approval requests are sent to the Accounting group (James and Heather).
7. Heather approves the request.
8. The policy requirements are met, and the request is committed.

Example 4: Node Type and Hierarchy Set Level Approval Policy

While approval polices at the application and dimension level are applied on all request actions, policies at the node type and hierarchy set level are applied only for specific request actions. Polices on a node type are applied only for requests that add or delete nodes, or that update node properties. Policies on a hierarchy set are applied only for requests that insert, remove, move, or re-order nodes in a hierarchy set, or that update node relationship properties.

To illustrate these principles, let's look at two requests for an example that has policies on both the node type and the hierarchy set. The first request updates a node property, so only the policy on the node set is applied. The second request adds accounts, which affects both the node type and the hierarchy set, and therefore both policies are applied.

Table 25-4 Example 4: Node Type and Hierarchy Set Level Policy Settings

Application	Dimension	Node Type	Hierarchy Set
Planning application	Account dimension	Account node type Policy A Approval groups: Accounting, TaxUsers Method: Parallel One Approval per Group: True	Account hierarchy set Policy B Approval groups: EssAdmins Method: Parallel One Approval per Group: False Total Required: 5 approvals

Some additional background about these requests:

• The Accounting group consists of James and Heather.
• The TaxUsers group consists of Brian, Jane, and Rachel.
• The EssAdmins group has seven administrators in it (EssAdmin1 through EssAdmin7).

First, let's look at a request to update node properties. Node property updates are affected by policies on the node type only.

Request 1 Approval workflow:

1. Mark submits a request to update three account descriptions (node property update).
2. Approval requests are sent to the Accounting and TaxUsers groups.

   Note:

   Because a node property update does not affect the hierarchy set, the EssAdmins group does not get an approval request.
3. James approves the request for the Accounting group.
4. Rachel approves the request for the TaxUsers group.
5. The policy requirements are met, and the request is committed.

Next, let's look at a second request, this time to add nodes. As before, the policy on the node type is applied because the request action adds nodes. But for this request the policy on the hierarchy set is applied as well, because add actions create insert actions in hierarchy-based viewpoints.

Request 2 Approval workflow:

1. Mark submits a request to add three new accounts.
2. Approval requests are sent to the Accounting and TaxUsers groups.
3. Because an add action in a hiearchy-based viewpoint also creates insert actions in the hierarchy set, approval requests are also sent to the EssAdmins group.
4. James approves the request for the Accounting group.

   Note:

   Because James has implicit Participant (Read) permission on the node type but not the hierarchy set, he must approve the request in the Request Inspector. See Policies and Permissions.
5. Rachel approves the request for the TaxUsers group.

   Note:

   Because Rachel has implicit Participant (Read) permission on the node type but not the hierarchy set, she must approve the request in the Request Inspector. See Policies and Permissions.
6. Five Essbase administrators approve the request.

   Note:

   Because the EssAdmins group has implicit Participant (Read) permission on the hierarchy set, they are also granted implicit Participant (Read) permission on the node type. They can open a view and browse the hierarchy set to approve the request. See Policies and Permissions.
7. The policy requirements are met, and the request is committed.

Example 5: Approval with Enrichment Enabled

If enrichment is enabled on an approval policy, approvers with Participant (Write) access on any data object in the view for the request can modify the request before approving.

In this example, a request is made in a maintenance view with viewpoints for three applications: General Ledger, Planning, and Consolidation. Each application has an approval policy at the application level, and the GL and Planning policies have enrichment enabled.

Table 25-5 Example 5: Approval with Enrichment

General Ledger Application	Planning Application	Consolidation Application
GL Approval Policy Approval Groups:Josh (General Ledger administrator) Note: Josh has Participant (Write) permission to the Planning application. Method: Serial Total Required: 1 Enrichment Enabled? Yes	Planning Approval Policy Approval Groups: Julie (Planning administrator) Note: Julie has Participant (Write) permission to the Consolidation application. Method: Serial Total Required: 1 Enrichment Enabled? Yes	Consolidation Approval Policy Approval Groups: Accounting Method: Serial Total Required: 1 Enrichment Enabled? No

Approval Workflow:

1. Mark submits a request to add a cost center in the General Ledger application.
2. An approval request is sent to Josh, the GL administrator.
3. Josh enriches the request by adding the cost center to the Planning application and then approves the request for the GL application.
4. Because Josh added a node to the Planning application, the Planning approval policy is activated and an approval request is sent to Julie, the Planning administrator.
5. Julie further enriches the request by adding the cost center to the Consolidation application, and then approves the request for the Planning application.
6. The Consolidation approval policy is activated, and an approval request is sent to the Accounting group.
7. Barry, a member of the Accounting group, approves the request for the Consolidation application. Because enrichment is not enabled in the Consolidation policy, Barry cannot enrich the request further.
8. With the policy requirements of all of the approval policies met, the request is committed and the cost center is added to all three applications.