EDMCS and Data Governance – Part 2
Welcome to Part 2 of the blog series “EDMCS and Data Governance!”
Part 1 provides an introduction and primer for data governance workflows in Oracle Enterprise Data Management Cloud Service (EDMCS) which was introduced in the 19.02 release. This exciting feature addresses a major gap in EDMCS as the product continues to rapidly evolve and mature.
In Part 2, we dive into the details of how to configure workflows. This process revolves around the concept of an “approval policy.” Interestingly, approval policies can be configured at different points of the EDMCS data chain and cascade or inherit to affect downstream points of the data chain.
Before we dive into approval policies, let’s discuss EDMCS workflow stages a bit more. They are similar in concept to Data Relationship Governance (DRG) workflow stages. See Figure 1 for an overview:
Figure 1 – EDMCS Workflow Stages
- Submit (or Assign) Request - A request is initially created as you do today. But wait...there’s more! You can Submit the request to immediately move the request into the Approve stage OR you can Assign the request to colleagues to collaborate on the request together. When the request is ready, it is submitted to move to the Approve stage.
- Approve Request - The approver(s) have 3 choices:
- Approve – the request is approved and moves forward (thanks Captain Obvious!).
- Push Back – like DRG, the request is pushed back to the submitter for clarification or changes, who then updates and resubmits the request.
- Reject – like DRG, the request is denied and closed. Think of “reject” as the RAID of the data governance world – it kills requests dead.
- Commit Request – once fully approved, the request is auto-committed and closed. EDMCS has now been updated.
Now for approval policies. Approval policies can be configured at 4 levels:
- Node Type
- Hierarchy Set
It is important to note that each data chain object can contain one, and only one, approval policy. However, approval policies have a cascading impact so that multiple approval policies can work in concert to govern and control exactly what you want. Yes, you heard that right: Approval Policy Inheritance - it’s not just for properties anymore!
The types of actions governed by an approval policy depend on the data chain object it is configured with – see figure 2 below:
Figure 2 – Approval Policies and Data Chain
As you can see, policies defined at the Application or Dimension level govern all actions (add, delete, insert, remove, move, etc.) while policies defined at the Node Type or Hierarchy Set level govern a subset of actions. Why is this important? Because it means you need to carefully design what types of actions you want to govern and who will perform them. If I define an approval policy at the Hierarchy Set level and then submit a request that Adds 3 accounts, how many approvers are required for the request? A big ZERO! Since I requested “add” actions and only have an approval policy at the Hierarchy Set level, no applicable approval policy exists to govern the request.
Putting It All Together
Let’s walk through an example.
- Define Approval Policy
First, I will define an approval policy for the Account dimension. To do this, Inspect either the application or default viewpoint and access the Account dimension from the Definition tab. From there, click the Policies tab.
Here you will see the Approval policy for the Account dimension. Click on the Approval link to inspect the approval policy.
The General tab will display basic information about the approval policy. You can edit the approval policy name and description if necessary.
The Definition tab is where the magic happens. Select edit to update the following parameters:
- Enabled – click this check box to enable the approval policy.
- Approval Method – select Serial or Parallel.
- One Approval Per Group – if using Serial approvals, this will automatically be set to "True." If using Parallel approvals, you can select one approval per group or define a Total Required # of approvers.
- Include Submitter – enable this to allow the submitter to also be an approver (the submitter’s approval will be automatically granted). If “separation of duties” is required for your company, do not enable this.
- Reminder Notification – the # of days that will elapse before reminder emails are sent.
- Approval Escalation – the # of times a reminder occurs before an escalation email will be sent.
- Approval Groups – select user(s) and/or group(s) to be included in the approval process. When using Parallel approvals, the order of approval groups does not matter. When using Serial approvals, the order of approval groups does matter – you need to list the approval groups in the order that approvals should be executed.
With my example approval policy, I am using serial approvals, 2 approval groups (a Planning group and GL group), a reminder interval of 5 days, and an escalation interval of 2 reminders.
- Submit Request
Now we’re cooking with gas. It’s time to submit a request. I will submit a request to my default Account viewpoint that includes 1 add, 1 property update, and 1 move. Here is the request in Draft status:
Did you notice something new? Look at the Actions button next to Submit. This is where you can assign the request to another user and collaborate with him to finish up the request.
- Approve the Request
After the request is submitted, it is considered “in flight” because it has been submitted, but not yet approved/committed. And look! EDMCS now offers a nice Activity page on the home screen displaying the status of various workflow requests:
First, the users in the Planning Approvers group will receive an email notifying them that they have been “invited to approve a request” (it’s very polite):
As mentioned earlier, an approver has 3 choices: Approve, Reject, or Push Back. Reject and Push Back are available under the Actions dropdown. Here are the dialog windows that will be displayed for those actions (note the comment field is required):
Otherwise, the approver will click the Approve button and see this:
And then the same process will continue with the GL Approvers group since I am using Serial approvals. Once again, an approver can reject, push back, or approve. Once approved, the request is committed and closed.
Congratulations! You have now completed your very first data governance workflow request in EDMCS!
This blog post should be useful in providing more details and clarity on workflows, workflow stages, and approval policies. In the third and final post for this series, I’ll offer a recap and some closing thoughts. Talk to you then.
Read the next post in this EDMCS blog series: EDMCS and Data Governance - Part 3
And don’t forget to follow me on Twitter (@kblackEPM) and check out these links for more information: