EDMCS Approval Policies – Initial Release in 19.02

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:

1. On a Application
2. On a Dimension
3. On a Hierarchy Set
4. 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:

1. 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.
2. 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!)