Hi there – I’ve been putting off this post (the procrastination is real!) about the newly released Approval Policies feature in EDMCS from the 19.02 update. This is the first foray into expanding the Request features into a real workflow/governance process that can be configured within EDMCS.
Approval Policies allow for adding layers of approval to changes to master data within EDMCS – so changes such as adding a new Account or making updates to an Organization structure have key SME approvals before they are committed to the system and made to any target applications. The Approvals are automatically generated and sent via email to the approving parties that are configured, and recurring “reminder” emails can also be generated to help move along the process.
Data Chain Configuration
When configuring Approval Policies, you must determine at which level the Approvals need to take place in the Data Chain. You have 4 choices of levels:
- On a Application
- On a Dimension
- On a Hierarchy Set
- On a Node Type
Approval Policies follow the same “cascading” functionality like security in that if an Approval Policy is applied at the Application level, it applies to all Dimensions, Hierarchy Sets, and Node Types within that Application. This is where I would apply Approval Policies if all layers of approval are the same for a given application; like all GL Segments need the same 4 groups of approval. However, if you need a lower level of granularity, or need to have specific policies for different dimensions, or even lower sections of the data chain, Approval Policies should be applied lower.
A few other things to consider when determining where the Approval Policy should be configured:
- Approval Policies on Applications or Dimensions, approvals will be required for any request action.
- Actions: add / delete / remove / update / insert / move / reorder
- Approval Policies on Node Types require approvals for requests in which nodes are added or deleted, or in which the node properties are updated.
- Actions: add / delete / update
- This is because Node Types determine the context of the nodes within its subject matter area, and can only add / remove or change items within its context of nodes // does not define the relationship between the nodes.
- Approval Policies on Hierarchy Sets require approvals for requests in which nodes are inserted, moved, removed, or reordered in a hierarchy set, or in which node relationship properties (such as Parent) are updated.
- Actions: insert / move / remove / reorder
- This is because Hierarchy Sets determine the relationship of the nodes
Below is a diagram that illustrates the potential Action Types for Approval Policies by Data Chain Object:
Approval Policy Settings
On the Approval Policies, there a number of fields that can be configured based on the organization’s needs.
To find Approval Policies on any of the Data Chain objects (Application, Dimension, Node Type, or Hierarchy Set), go to Inspect the object and find the Policies tab. OOTB the “Approval” policy is in place and ready to be configured. There is no other way at the current release to add additional approval policies on an object, just configure the default Approval – but I assume that functionality will be added with time.
Note that the Policies tab shows if the Approval is active, the method, and will display any approval groups if you have it configured.
Below is an example of a configured Approval Policy that is applied to the Application level for a Cloud financials GL application.
- Enabled – specifies if the Approval Policy is enabled or not enabled on the Data Chain object
- Approval Method – Parallel or Serial
- Parallel: all approval groups can approve at the same time
- Serial: approval groups must approve in the specified order in the right-hand panel
- One Approval Per Group/# Approvals Per Group: specifies the number of approvals that are needed per group in the right-hand panel
- Note, this requires for all groups in the right-hand panel, so if you require 3 approvals per group, all groups will need minimum 3 users and need 3 approvals. This is an incredibly important piece of the design of the Approval Policy.
- Include Submitter – Include the submitter as one of the approvals
- Reminder Notification – number of days without action that a reminder email should be sent to the groups needing approval
- Approval Escalation – number of days without action that the request will be escalated to an administrator (results in Timeout Escalation)
In additional to the Approval Escalation, there is another type of escalation called Deadlock Escalation. This escalation occurs when the number of users in the group does not meet the minimum requirements for the number of approvals needed per group.
How Approvals Look
Once you get the Approval Policy set up on your Data Chain objects, it’s time to test. I was able to make a simple request to the Account viewpoint in my Oracle Cloud Financials Setup. Once I submit, the Approval Policy takes over.
Any requests made on Data Chain objects requiring Approval, the Request goes into a new Status, In Flight, and a new Stage, Approve.
On my homepage as the Requestor, I can see my In Flight requests that I have made that are still waiting to be Approved.
If I now log in as one of the users that are in groups configured on the Approval Policy, I can see that I have outstanding requests in my queue that need to be approved.
And when I navigate to the Request, I am now given the option of Approving, Pushing Back, or Rejecting the request.
Lessons Learned & Tricks
A few things I learned while testing Approval Policies:
- If you have an Approval Policy enabled and push a request through from Submit to an Approval, and then remove the Approval Policy from the Data Chain (changing the Enabled flag to False) then the Requests that are In Flight status and Approve stage are going to be in limbo until the Approval Policy is re-enabled. If you log in as an Approving user, they do not have the Approve, Pushback, or Reject options as they would if the Approval Policy was enabled. If you do not need the Approval Policy anymore, an administrator will have to delete the request and the request will need to be redone as a new request.
- I believe there is a small bug on Approval Policies, in that you cannot remove a group or user that was assigned to the Approval Policy at this time. I created a test Approval Policy and even after disabling the Approval Policy and clicking the “…” icon next to the group, no menu appears to remove it. I have an SR open with Oracle on this right now, but at this time (19.03) please be mindful when adding groups to Approval Policies (or take a Snapshot before you do so you can revert!)
hyperionbarbie.wordpress.com 
Hi , I have a question in approval work flow.
If we load a file with few nods to add using load request items and submit. after that approval wants to approve only few nodes from that loadable file and few nodes he needs to reject. is it possible in EDMCS?
Approvals and Rejections are done at the Request level. There is no way to Approve partial Requests with multiple Request Items. The items would have to be in separate requests.
1. Once submitter submits the reqest a Approver will recives notification to approve ,What is the timing of notification, if submitter create one account at 1pm, approve will receive notification today at 1pm, and tomorrow at 1pm until it is approved?
2. Suppoer A user with data manger and he is also approver , if he is not responeded to email notifications to approve request, the esclation mail will go to both data manager and owner?
1. The approval email is pretty much instance, I usually get it in seconds after the submission of a Request. And depending on the reminder setting; it will be the number of days after the initial approval request was submitted.
2. I’m not 100% sure of your question here, but my recommendation would be to do a test scenario with a user with those roles/settings.