{"id":1492,"date":"2022-12-19T09:42:41","date_gmt":"2022-12-19T04:12:41","guid":{"rendered":"https:\/\/blogs.infosys.com\/infosys-cobalt\/?p=1492"},"modified":"2022-12-19T09:42:41","modified_gmt":"2022-12-19T04:12:41","slug":"dedicated-approval-policies-for-different-rollups-within-same-viewpoint","status":"publish","type":"post","link":"https:\/\/blogs.infosys.com\/infosys-cobalt\/cloud-applications\/oracle\/dedicated-approval-policies-for-different-rollups-within-same-viewpoint.html","title":{"rendered":"Dedicated Approval Policies for different rollups within same Viewpoint"},"content":{"rendered":"<p>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 \u2018Accounts\u2019 were classified under 2 separate rollups \u2013 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.<\/p>\n<p>&nbsp;<\/p>\n<p>Scenario:<\/p>\n<p>Let us assume that we have an Account Maintenance View with viewpoints for the below applications:<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Fusion Cloud GL (Account \u2013 CoA)&#8230; *CoA stands for &#8216;Chart of Accounts&#8217;<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Planning Cloud (Account \u2013 Planning)<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Financial Consolidation Close (Account \u2013 Consolidation Close)<\/p>\n<p>The GL system is the primary application, and the other applications will be the subscribing applications. The \u2018Account \u2013 CoA\u2019 viewpoint has multiple rollups such as \u2018100000 \u2013 Statistical Accounts\u2019, \u2018200000 \u2013 Expenses\u2019, \u2018300000 \u2013 Bookings and Gross Margins\u2019 and \u2018400000 \u2013 Total Expenses\u2019. Refer to Snapshot 1 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1463\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapsho-1.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>The requirement is to have updates made in the \u2018Statistical Accounts\u2019 rollup to go to \u2018User 1\u2019 for review. All other updates should go to User 2.<\/p>\n<p>Solution Approach:<\/p>\n<p>Step 1: Create a policy and name it as \u2018Statistical Accounts\u2019. In the \u2018Definition\u2019 tab of the policy, select \u2018User1\u2019 as approver. Refer to Snapshot 2 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1464\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-2.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>In the \u2018Filter\u2019 tab, we write a logic which is meeting the below condition:<\/p>\n<p>If an Ancestor node is 100000, the policy returns \u2018True\u2019<\/p>\n<p>Else<\/p>\n<p>False<\/p>\n<p>Refer to Snapshot 3 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1465\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-3.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>The policy will simply track whether the update being made is in a rollup that has an ancestor node \u2018100000\u2019. This policy will get triggered when this condition is met, and the metadata update will go to \u2018User1\u2019 for review and approval.<\/p>\n<p>Step 2: Create a policy and name it as \u2018Other Accounts\u2019. In the \u2018Definition\u2019 tab of the policy, select \u2018User2\u2019 as approver. Refer to Snapshot 4 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1466\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-4.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>In the \u2018Filter\u2019 tab, we write a logic which is meeting the below condition:<\/p>\n<p>If an Ancestor node is 100000, the policy returns \u2018False\u2019<\/p>\n<p>Else<\/p>\n<p>True<\/p>\n<p>Refer to Snapshot 5 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1455\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-5.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>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 \u2018User2\u2019 for review and approval.<\/p>\n<p>Make sure that both the policies are \u2018Enabled\u2019 as shown in snapshot 6 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1456\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-6.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>Logic in Action:<\/p>\n<p>I have logged into EDM with my ID \u2018arjun.mathur\u2019. I will now add a new account in the \u2018Statistical Accounts\u2019 rollup. I am going to add a new base node \u2018100024\u2019 as a sibling of \u2018100023\u2019. Refer to Snapshot 7 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1457\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-7.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>On submitting this request:<\/p>\n<p>a.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 The addition of the new node \u2018100024\u2019 will not get committed to the EDM system. The node will be visible as \u2018Pending for approval\u2019 as part of Request number 1903. Refer to Snapshot 8 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1458\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-8.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>a.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 The request 1903 should go to User1\u2019s queue for approval as the policy \u2018Statistical Accounts\u2019 has got triggered. Refer to Snapshot 9 and 10 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1459\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-9.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1460\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-10.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>a.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Once User1 approves the addition of this new node, the node should get added to EDM. Refer to Snapshot 11 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1461\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-11.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>The node gets added to EDM. Refer to Snapshot 12 below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1462\" src=\"https:\/\/blogs.infosys.com\/infosys-cobalt\/storage\/2022\/11\/Snapshot-12.jpg\" alt=\"\" width=\"1152\" height=\"648\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>Similarly, any update made to a rollup other than the \u2018Statistical Account\u2019 rollup will trigger the \u2018Other Accounts\u2019 policy.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Approval policies can be setup for review of metadata updates made in a Viewpoint. [&hellip;]<\/p>\n","protected":false},"author":312,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[69,72],"tags":[158,165,159,163],"coauthors":[155],"class_list":["post-1492","post","type-post","status-publish","format-standard","hentry","category-oracle","category-oracle-cloud-infrastructure","tag-edm","tag-edmworkflows","tag-metadatamaintenance","tag-policies"],"acf":[],"_links":{"self":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts\/1492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/users\/312"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/comments?post=1492"}],"version-history":[{"count":4,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts\/1492\/revisions"}],"predecessor-version":[{"id":1591,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts\/1492\/revisions\/1591"}],"wp:attachment":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/media?parent=1492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/categories?post=1492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/tags?post=1492"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/coauthors?post=1492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}