Skip to content

Basic Functionality of Data Relationship Governance

February 13, 2015

In this post, I will discuss Data Relationship Governance and its functionality in Data Relationship Management. Data Relationship Governance was an add-in to DRM 11.1.2.3 and has many features than can be very beneficial to DRM users.

Data Relationship Governance is a component within Oracle’s Data Relationship Management. DRG is a tool that allows DRM users to easily make changes to their data hierarchies. It allows users to communicate within the DRM system, which means users can view, request, and approve data changes all in the same place. DRG has four main focal points: User Roles, Access Levels, Workflow Tasks, and Workflow Stages.

There are several DRG User Role Permissions that can be assigned to DRM users. The permission with the most freedom is the “Workflow Participant”. This permission allows users to Request and/or Approve changes to the data hierarchies. The next level down in the DRG permissions is “Browse Versions”, which allows DRM users to navigate through different versions within the DRM system, but doesn’t allow them to request and/or approve changes to the data structures. Finally, there are three more permission levels: “Browse Hierarchies”, “Browse Categories”, and “Browse Properties”. These three permissions are the lowest level of permissions and there names describe what the user is able to navigate through.

In Data Relationship Governance, there are six different Access Levels that users can be given. All of these access levels build on each other, so, for example, level 3 includes all of the access rights that level 1 and 2 have. Level 6 has all of the access rights that levels 1 through 5 have. The six Access Levels in DRG are: Read, Limited Insert, Edit, Insert, Inactivate, and Add. Read access only allows users to view the data. Any user with this Access Level cannot make any changes. Limited Insert is allowed to insert a node, but only if that node has Global Properties. The Edit access level allows users to modify property values. The Insert access level grants users the ability to insert, move, and remove nodes. Inactivate allows users to deactivate and reactivate nodes. Lastly, the Add access level allows users to do all of the previous tasks, plus add or delete nodes.

Workflow Tasks are made up of an action type, properties that need to be reviewed, and validations. There are eight different Action Types a Workflow Task can use: Add Leaf, Add Limb, Delete, Inactivate, Insert, Move, Remove, and Update. These Action Types are self-explanatory and they are named for exactly the action that they perform. Workflow Tasks must be created in the Administer tab within DRM before any user can Request and/or Approve any data changes.

The last component of Data Relationship Governance are the Workflow Stages. There are four stages in total, but only three of them are required. The Workflow stages include: Submit, Enrich, Approve, and Commit. The Submit stage is where the requests for any sort of data change take place. All of the Action Types are associated with this stage except for the Update action. The Enrich stage is used to update requests that have already been submitted. This is the stage that is not always necessary to be included, and includes the Update, Insert, and Move Action Types. The third stage is the Approve stage, which is where all requests are viewed and managed. The Update Action Type is also a part of this Workflow Stage, which is why the Enrich Workflow Stage does not always need to be included. Finally, the Commit stage is where requests are approved or rejected. Only a user with the access to approve a request may view the Commit stage.

These four components of Data Relationship Governance, User Roles, Access Levels, Workflow Tasks, and Workflow Stages, are what make DRG so useful in DRM. As previously mentioned, DRG serves as a central hub for requesting and approving/rejecting changes to data structures. By setting up the User Roles and Access Levels, management does not have to spend as much time dealing with the requests and can outsource the approval process to other employees.

Advertisements

From → DRG, DRM, Oracle, Oracle EPM

Leave a Comment

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: