The 23.03 release of Oracle EDM cloud had 18 new features! I’m still getting familiar with them, but the Consolidation Requests feature really drew my attention. Link to the Oracle documentation for reference.

EDM has always been a user friendly tool – users can visualize requests and make changes very simply; but what happens if users are making multiple requests that may overlap? This can make it difficult for approvers/enrichers that may have two or more requests that could have changes to the same nodes.

Enter Consolidation Requests! This new feature allows Data Managers to group and consolidate requests to simplify the review process.

Considerations of Consolidation Requests Feature

A few key considerations before we get into the application to show the steps:

  • There are a new “Status and Stage” and “Request Type” categorization on Requests.
    • Requests with a “Status and Stage” of “Consolidated” are requests that have been consolidated into a new request. Once a request is in this status, it can’t be changed except for adding more comments and attachments.
    • Requests with a “Request Type” of “Consolidation” are requests resulting of a consolidation of two or more requests.
  • Users that can consolidate requests must be a Data Manager permission on the request items in the requests.
  • Requests that can be consolidated must be in the same View and be in “In Flight” status (meaning they need to be approved or committed).
  • Requests that are consolidated are processed in LIFO order – meaning the most recent request to be submitted is the one that ‘wins’ in the consolidation. Will have an example of this in the steps below.
  • Attachments from the original requests that are being consolidated do not flow through to the new Consolidated request, but they are still available on the original requests themselves. A new attachment is attached to the Consolidated request with all of the request items from the consolidating requests.
  • If for some reason you do not want to consolidate the requests, you can delete the Consolidation request and the original source requests will return back to the “Status and Stage” they were prior to the consolidation.

Consolidating Requests

The first step to testing the Consolidation Requests feature is that we need to create at least two requests to consolidate. Remember, these need to be in the same View and go into “In Flight” status.

In my test application, I have a Default Application View named “KateTest” where I’ll be performing this test. I’ve added an Approval Policy for KT_Account dimension for User 31 to get the approvals. User 31 is also provisioned as a Data Manager.

My first request is “Test Consol Req 1” and has two request items: Adding AC130 as a new Account and Updating AC110 with a new description. I’ve submit this Interactive request, and you can see it as “In Flight” status.

Next, I need to create a second request in this View so I have two requests to consolidate. My second request is “Consol Req Test 2” and has two more requests items: Adding AC140 as a new Account and Updating AC110 with a new description. Notice, both requests have done the same action: Update AC110 with a new Description. This was a test to see the LIFO of overlapping updates in action. My expectation is that the most recent update in this second request will “win”.

Now that both Request have been submitted and are “In Flight” status, I can log in as User 31 to test the consolidation.

I can navigate via the “Requests for me to approve” on my Activity Panel or head straight to the Requests card to see the Requests to consolidate. I find my two requests – note the Request Status is “In Flight” and both requests are for the same View, “KateTest“.

Next, on the left hand side I am able to select the two Requests via checkbox and the “Consolidate Requests” button becomes active.

The following window will appear to confirm you want to consolidate the requests. There is an option to add the submitters to the original requests as collaborators. I check it; this should show us that User 32 (original submitter of the Requests) should be a Collaborator on the Consolidation request. I press “Yes”.

The result is a new request, “Request 11409” with a Request Type of “Consolidation” and the Status is set to Draft.

By clicking into “Request 11409”, I am able to see the request items. There are 3: 2 Account additions and one Account Description Update. Note, the Request Type is marked as “Consolidation”.

  • New Account AC130 was the add from “Test Consol Req 1”
  • New Account AC140 was the add from “Consol Req Test 2”
  • Account Description Update on AC110 was from “Consol Req Test 2”
    • This was the 2nd update to the same node – most recent update will be in the request

Next, I go to inspect “Request 11409”: a new tab option appears on the top called “Consolidation” which shows the requests that sourced the Consolidation request. See below it shows “Consol Req Test 2” and “Test Consol Req 1”.

Next, I click to the “Attachments” tab and see what the new attachment format looks like. I download and review the attachment.

The request file shows the items from both consolidation requests. The most interesting thing in the file to me is the yellow highlighting and error message for the first AC110 description update that was not processed, since there was a more recent update.

The full Message for row 5 reads: “Record with the same key was processed earlier. Highlighted cells were skipped due to conflicts with the previous record.”

The file also includes hyperlinks to the source requests in column A.

Lastly, the Workflow tab shows that User 32 (original submitter) was tagged as a Collaborator on the Request.

One last thing to check was that the originally submitted requests were marked with a Consolidated status and unable to be edited. Opening up “Consol Req Test 2” I am not able to make any changes via uploading Request items or any other interactive means – all actions are greyed out.

So that’s it! This is helpful for bundling requests together; or if you are reviewing and approving multiple requests in one, takes a lot of the review burden off of the approver. The LIFO of request updates that overlap is also very nice!

What do you think? Will you use the Consolidation Requests feature when making updates?

Thanks for reading!