jcarlson,
Relationships are a business need.  Something that allows you to control a business process without change control.  Example, for procedure document, I have used relationships to identify documents that are referenced in the procedure so that under any change there is opportunity for the owner to evaluate impact to the related documents.  Again, this is used to enhance your business practice and is extremely flexible yet one thing to keep in mind is that it is NOT under change control and any user may make changes at any time if they have the privileges.  I know this isn’t exactly a guide but should help you to understand its usage and engage your business units in conversations.

Patrick – 

Thanks for your response.  That’s exactly what we were looking to do, but I didn’t want to jump the gun on what relationships are intended for.  

And your comment about not being controlled was already raised as a concern as well.  Is there a relationship edit option on users profiles that can be turned on/off?  I know that at the end of the day, it will all be logged in the history of that document, but with a 100% new user base I would rather be safe than sorry.

Thanks again,

Jeremy

Jeremy,

I have used criteria to only allow the object creator the ability to make any edits to the relationships (create user = $USER), that way you reduce the risk.  This does tend to bring another issue to light and that is attrition.  If the user leaves the company then the create user idea become invalid so I additionally add an attribute that would identify a USERGROUP that has the relationship access.  Now I can move folks in and out of the group and solve that problem.

Patrick – 

Has there been any thought (or is the availability there out of the box), to require adding/changing relationships to go through a change control process (workflow)?  I’m guessing there will be a push for that, in order to have a stronger level of control.

That’s when you opt to use the BoM feature.  You can set these relationships up similarly but now they are under change control.

For more questions you are welcome to call me at 408-568-1980

Just to add something to the perfect explaination by Patrick, The relationship privilege is a bit tricky because it is bidirectional. You have to manage the privilege and check the criteria on both object to grant the correct modify access to an user. I suggest to don’t use it to bind very imprtant business info but just to have such a kind of linkage between two objects.
If you have to manage a unidirectional information, you can use a Dynamic List field where is only in the source object. In that field,, you can select an existing object and manage the privilege like any other field.
This field can be set under change control and redlined over a change (in 9.3 version)

Antonio-

Thanks for the further clarification on this.  I was reading about the relationship being bi-directional, and wondered about the effect of that.  I’ll have to look into the Dynamic List option and further explore that.

Thanks again!