Building a DRG Workflow: The Magical Steps

As we stated in our intro blog post, Oracle DRM enables organizations to achieve a standardized and centralized management of their metadata for various entities and attributes (accounts, products etc.). However, technology alone is just an enabler, it is not the complete solution for the master data management needs of an enterprise. The missing parts of the puzzle are the people and the process.

That’s where ‘Data Governance’ comes into the picture. Without proper data governance oversight and efficient processes, data quality issues will arise, the trust level on the data will decrease, the usage of the system will suffer and subsequently the enterprise investment on the data management initiatives will not be fulfilled.

Data Relationship Governance (DRG) is the workflow module of  Oracle DRM. Oracle describes what DRG does very well: “DRG automates change request approval and data remediation workflows between front-line business users, subject matter experts, signing authorities and data stewards using automated, repeatable business processes to enable data quality, policy compliance, user collaboration, and change awareness across the business community.” Check out the Oracle Data Relationship Governance (DRG) Data Sheet for more info.

How about we explain what DRG truly, magically does in ODTUG #KScope18 Disney terms !

Let me give you a New Fantastic POV of the Agrabah of Data .Gov(ernance)! It’s quite a magical Enterprise MDM Production!

Imagine the DRM technology as the laMp: Out of all the lamps in Agrabah, there’s only one or two specific lamps that will enable our Data Lovers to get their data.Gov(ernance) wishes fulfilled…

Imagine the DRG SME people combined into one as the Genie: The subject matter expert(s) who will review and approve all DRM data changes… The ‘3 wishes only’ rule does not apply to our DRG Genie, however every data wish update goes through a selective validation assessment…

Imagine the process to be the Magic Carpet: that which will facilitate our Data Lovers’ easy breezy exploration of this Whole New Data World … Without the magical ability of the carpet to fly fast and go around obstacles, Aladdin and Jasmine wouldn’t have been able to discover the potential of the DRM laMp…

Imagine the horrific Manual Governance processes as Jafar: How used are some teams to hold on to the ancient manual, complex ‘rituals’ that create so many delays, data quality issues and complete chaos in the realm of data management…

We all know what happens in the end… Our Data Lovers get on a journey to discover this Whole New Data World with the help of the Magic Carpet, the DRM laMp and the DRG Genie… Who wouldn’t want to experience this New Fantastic POV??? And of course… once they set their DRG Genie free to become his own Master, all their Data Wishes come true!!!

MDM Agrabah

DRG Workflow Build Steps

As is everyone’s experience, after a Disney fairytale comes to an end, you get abruptly awoken back to reality… Good news for you… reality is awesome if you know what steps to follow… Let’s get started!

The following steps may seem dry and straight to the point, but there’s a number of people that have worked to put them together through iterations of building DRG workflows in Oracle DRM. We will address more of the terminology and the functionality behind each of the steps in future posts.

1. Requirements Gathering

  • List the breakdown of all Workflow Tasks and Node Access Groups (NAG).
    • If Common User Provisioning (CUP) is implemented, consider adding more details for LDAP group names, members in the groups and the steps to configure LDAP groups with NAG.
  • For each Workflow Task, list all the DRM Properties that should be displayed as DRG Labels.
    • Which fields are required vs. optional?
    • Which fields are editable vs. read-only?
  • Determine which hierarchies need to be accessed by the workflow.
    • Create an ActionScript that will give each NAG access to Leaf/Limb members within the relevant hierarchies.
  • Define Validations. (highly important!)
    • Determine whether you can reuse existing validations (with or without modifications) or must build new validations.
    • Share requirements with the team to ensure that multiple people aren’t building the same validation.
  • Add a Bulk Upload Template for the workflow in the requirements document.
DRG Requirement Template
Sample DRG Requirement Template

2. Build

  • Workflow Tasks to be built first.
    • You can create a Category to store all relevant Properties for easy retrieval, however, do not migrate this Category to Stage or Prod.
  • Workflow Model built to follow after completing 2.1.
  • Node Access Groups to be reuse if possible.
    • If CUP is enabled, no updates will be needed at this step.
  • Validations to be built by following the below 4 steps:
    • Build Validation object. (required)
    • Build Validation Export. (only required if building a validation report for the entire hierarchy would be useful on an ongoing basis – e.g. Do not create a Validation Export for a validation that throws an error if the node is a limb.)
    • Update all relevant Node Types with the new Validation.
    • Assign the Validation to the relevant hierarchies using an Action Script.
  • NAG to be assigned to hierarchy Leaf/Limb members using ActionScripts (see 1.3).

3. Test

  • DRG GUI Dev Testing
    • Test your Bulk Upload Template.
    • Ensure that the NAGs are properly set up by successfully submitting, enriching/approving, committing your request.
    • Supply both good and bad data to ensure that the validations work.
  • Validation Exports Dev Testing
    • Update test node with improper property values to see if the export catches the validation errors.
  • Functional Team Stage Testing
    • Migrate the workflow to the Stage environment.
    • Give business users access to the workflow for additional testing.
    • Update objects based on feedback.
  • Migration (Dev -> Stage -> Prod)
    • Use the migration client to export new/updated objects from Dev to Stage to Prod.
    • Coordinate migration activities with colleagues to prevent overwriting modifications to the same object. (e.g., two people may make changes to the same Node Type)
    • Document updates in the requirement document as a reference to keep the environments in sync.

Wrap Up


We do hope that you learned how to apply some best practices on the steps to follow for a proper DRG workflow build! Learning to sing along or lip sync A Whole New ‘Data’ World was just an extra goal for this post. However, if you’re attending #KScope18  make sure to attend the EPM Community Monday Night event, where you’ll be part of the first ever ODTUG Lip Sync Battle!


Neviana Zhgaba

Sr. Technical Product Manager

Finance EPM at General Electric

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s