Approval policies can be setup for review of metadata updates made in a Viewpoint. A metadata update made in a viewpoint may be made to go through an approval cycle involving multiple levels and multiple Users or User Groups. In one of my engagements, there was a scenario in which the ‘Accounts’ were classified under 2 separate rollups – Tax and Non-Tax. The Client Admins wanted that updates made in each of the rollups should go to only the relevant Users for review. Having a single policy with users from both the departments was not something that they particularly wanted. In this blog, I am going to explain how separate policies can be set up for different rollups of the same Viewpoint.
Scenario:
Let us assume that we have an Account Maintenance View with viewpoints for the below applications:
· Fusion Cloud GL (Account – CoA)… *CoA stands for ‘Chart of Accounts’
· Planning Cloud (Account – Planning)
· Financial Consolidation Close (Account – Consolidation Close)
The GL system is the primary application, and the other applications will be the subscribing applications. The ‘Account – CoA’ viewpoint has multiple rollups such as ‘100000 – Statistical Accounts’, ‘200000 – Expenses’, ‘300000 – Bookings and Gross Margins’ and ‘400000 – Total Expenses’. Refer to Snapshot 1 below.
The requirement is to have updates made in the ‘Statistical Accounts’ rollup to go to ‘User 1’ for review. All other updates should go to User 2.
Solution Approach:
Step 1: Create a policy and name it as ‘Statistical Accounts’. In the ‘Definition’ tab of the policy, select ‘User1’ as approver. Refer to Snapshot 2 below.
In the ‘Filter’ tab, we write a logic which is meeting the below condition:
If an Ancestor node is 100000, the policy returns ‘True’
Else
False
Refer to Snapshot 3 below.
The policy will simply track whether the update being made is in a rollup that has an ancestor node ‘100000’. This policy will get triggered when this condition is met, and the metadata update will go to ‘User1’ for review and approval.
Step 2: Create a policy and name it as ‘Other Accounts’. In the ‘Definition’ tab of the policy, select ‘User2’ as approver. Refer to Snapshot 4 below.
In the ‘Filter’ tab, we write a logic which is meeting the below condition:
If an Ancestor node is 100000, the policy returns ‘False’
Else
True
Refer to Snapshot 5 below.
Essentially, this policy is the opposite of the policy created in step 1. This policy will get triggered when the metadata update is made in a rollup that does not has 100000 as one of the ancestor nodes. The metadata update will go to ‘User2’ for review and approval.
Make sure that both the policies are ‘Enabled’ as shown in snapshot 6 below.
Logic in Action:
I have logged into EDM with my ID ‘arjun.mathur’. I will now add a new account in the ‘Statistical Accounts’ rollup. I am going to add a new base node ‘100024’ as a sibling of ‘100023’. Refer to Snapshot 7 below.
On submitting this request:
a. The addition of the new node ‘100024’ will not get committed to the EDM system. The node will be visible as ‘Pending for approval’ as part of Request number 1903. Refer to Snapshot 8 below.
a. The request 1903 should go to User1’s queue for approval as the policy ‘Statistical Accounts’ has got triggered. Refer to Snapshot 9 and 10 below.
a. Once User1 approves the addition of this new node, the node should get added to EDM. Refer to Snapshot 11 below.
The node gets added to EDM. Refer to Snapshot 12 below.
Similarly, any update made to a rollup other than the ‘Statistical Account’ rollup will trigger the ‘Other Accounts’ policy.
