This content has been marked as final. Show 2 replies
1. Create a Property as LOV and Inheritable which includes all the 3 Node Types EBS, HFM etc. as List values.
2. Assign the Property as the Hierachy Node Type.
3. Make sure to include the Property with LOV is part of all the 3 Node Types and make sure you placed it in a category where you have EDIT access.
4. Select the Target system as a value for the LOV Property on the hierarchy Top Node, then you will be all set,
But with this always a target system value is locked for all users,
To have a User specific views, Instead of a LOV property create a derived property whcih uses for example,
The complexity is purely based on the no of users you have etc.
Wish this is somewhat helpful!
Edited by: Murali Pasumarti on Apr 8, 2013 12:51 PM
I'm late to respond to this, but I always preach to customers that it is critical for DRM to act as an enterprise view. This isn't a "System A" hierarchy, or a "System B" hierarchy, but rather it's an asset that is shared by both systems, and therefore attributes for both systems are valid. Since node types provide the ability to hide properties, many interesting options present themselves, not all of which lead to a good outcome in the longer term. If a user doesn't ever want to see properties for a particular system, it would be better to just remove their access to that property category in many cases. (They may already have read only access but they object to "being bothered" with seeing those properties.)
I've seen many DRM implementations head down the other path and end up with duplicate maintenance requirements, configuration challenges, or even having to do major reengineering efforts to transition DRM from a Finance department tool into an enterprise use case feeding a data warehouse. A current customer of mine used a scheme where a checkbox on each property category would make the properties disappear if unchecked...this worked great with a handful of node types, but unfortunately the number of node types needed to support all of these property category combinations was bound by factorial math principles. Consequently the maintenance for this solution went from unweildy to unmanageable as more "non-HFM" data was added to DRM.
DRM implementations should be guided by governance principles and maintenance business rules, rather than than how things appear in DRM. It's how they appear when published that is of primary importance. I think the new features related to Data Governance will help greatly in this regard. Users that are overwhelmed by the DRM UI can easily be limited to the attributes that are relevant to their specific workflows, and only the "Power users" will see everything.