Understanding relationship objects
Relationship objects connect main objects. They can represent many-to-many relationships or many-to-one relationships.
Relationships display on record profiles so you can see how objects are associated to each other. For example, on an HCP profile, you can view the Parent Affiliations section, which lists any HCOs that are associated to an HCP.
Cardinality is the number of relationships an object can have to another object.
Relationship objects support the following:
Many-to-one - The owner object is limited to one relationship.
Many-to-many - The owner object can have unlimited relationships.
When you create a custom object relationship object, you must define the maximum number of relationships for the object owner. If the relationship will be limited, it's important to decide which object is the owner.
Many-to-one (limited) relationship
The owner object can have a maximum of one relationship.
For example, when you create a custom relationship object for Payer and Plan main objects, Plan should be the owner object and the Maximum number of relationships per owner setting should be set to 1.
One Plan belongs to one Payer
One Payer can have many Plans
When Plan records are updated, Network ensures that no more than one Payer is associated to each Plan record.
For more information, see Limiting custom object relationships.
Many-to-many (unlimited) relationship
The owner object can have unlimited relationships.
For example, when you create a custom relationship object for HCP and Study main objects, either object could be the owner because it's a many-to-many relationship.
An HCP can participate in many studies.
A study can include many HCPs.
Supported relationship types
This is the most typical modeling pattern. A STUDY custom object can have a many-to-many relationship with HCPs; a clinical trial will have multiple HCPs participating in it, while one HCP can participate in multiple clinical trials. In contrast, a simple relationship could be a many-to-one relationship. In a relationship between Plan and Payer objects, the Plan owner object would be limited to one Payer.
A custom relationship object called STUDYINVESTIGATOR can be created to track the relationship between STUDIES and HCPs. Users must have access to HCPs and STUDIES to be able to view the STUDYINVESTIGATOR relationship on the related record profiles.
In an arc relationship, two or more main objects are on one side of the relationship. Use this modeling pattern when a main object has a similar relationship to one or more main objects. When a relationship record is created, a main object can have a valid relationship to only one of the other main objects (Exclusive OR). Using an arc pattern, a sales employee could have a relationship to accounts with HCPs and HCOs. The arc ensures that the Employee custom object has an exclusive relationship with each HCP and HCO.
The Parent HCO relationship object is an arc relationship; an HCO can have a similar relationship to an HCP or to another HCO.
Custom relationship objects can be used so that one main object can refer to itself.
In a recursive relationship, the custom relationship object refers back to itself.
- An hierarchy of organization levels - Sales organizations have hierarchies and are typically divided by geography and disease state (US Cardiology, EU Diabetes).
- A hierarchy of employees - Managers and direct reports.
Combination of Arc and recursive relationships
Network also supports combining both the arc and recursive modeling patterns. This means that one of the main objects is an owner and a related object at the same time, and an additional main object is added to the relationship.
In a package content relationship, you can use the relationship object to store a relationship between an inner package and an outer package, or you can use the relationship to store the product that is contained inside the package. In this relationship, the package can contain either another package or a product.
Veeva standard relationship object
The Parent HCO object is the Veeva standard relationship object; on record profiles, the label is Parent Affiliations.
Parent HCOs create the following relationships:
- HCPs to HCOs
- HCOs to HCOs
This relationship object is read-only; Veeva standard objects cannot be removed and custom objects cannot be added.
Custom relationship objects
Custom relationship objects are created and maintained by customers. Custom relationship objects can link Veeva standard objects (HCOs, HCPs) and any custom objects that are enabled in your Network instance (for example, PRODUCT, STUDY, and EMPLOYEE).
Example custom relationship
Owner and Related objects
Every relationship object must have an owner. When you create a relationship, define one object as an owner and the other object as the related object.
Determining the owner object
It is important to decide which object should be the owner object because it impacts some of behavior in Network features.
To help you decide which object should be defined as the owner object, consider the following questions:
Should the relationship be limited? Should it be a many-to-one relationship or a many-to-many relationship?
A many-to-one relationship means that the owner object can have only one relationship.
Which side of the relationship should be editable?
- How would you expect the relationship to be rendered in Network Explorer?
Which side of the relationship has the higher data volume?
This means the number of relationships that the object has, not the total number of records. For example, there are typically more HCPs connected to a Study record than there are Studies on an HCP record, so HCP should be the owner. Similarly, in a relationship that connects Payers and Plans, Plans should be the owner because there are more Plan objects on a Payer record.
- How do you expect to search for the objects in a relationship?
When you create a custom object relationship object, you must define the maximum number of relationships for the object owner. Will it be limited to one relationship per owner object or can the owner object can have unlimited relationships? If the relationship will be limited, it's important to decide which object is the owner.
When you create a custom relationship object for Payer and Plan main objects, Plan should be the owner object and the Maximum number of relationships per owner setting should be set to 1.
One plan belongs to one payer
One payer can have many plans
For more information, see Limiting custom object relationships.
For unlimited relationships, the owner object should be determined using the other factors because the owner can have an unlimited number of relationships.
Owner objects drive the permissions for editing and viewing the relationship. On the profile page of the owner object, you can view the relationship and create new relationship records. One the profile page of the related object, you can only view the relationships. Decide which object should be able to create new relationships.
Network Explorer hierarchy
The owner and related object determines how the relationship is rendered on the Network Explorer canvas. The hierarchy is always drawn with the owner object on the right side of the relationship; the related object displays on the left. The line connecting the objects represents the relationship.
The search results display differently when you search for owner and related objects. When you search for the related object, the search results will also include any existing owner objects. When you search for the owner, the search results do not include the related object. For example, when you search for a Study record, the associated HCP records will also display. Search results for an HCP will not include any associated Studies.
In the relationship object configuration, two different labels are defined. The perspective labels are used on the profile page to refer to the other object in the relationship.
- Owner object label - Used to refer to the owner from the profile page of the related object.
- Related Object label - Used to refer to the related object from the profile page of the owner object.
When you define the owner and related object, the object label is added to the perspective labels by default. For example, if HCP is the owner, the Owner Object Label would default to Health Care Professional.
In most cases, the default object name does not need to be changed. However, you might want to override the label to a more relevant term. For example, for a relationship that connects the HCP and STUDY object, you might want to refer to HCPs as Investigators from a Study record. On an HCP record, you might refer to Studies as Clinical Trials.
Perspective labels examples
In some relationships, the default object name can be used as the perspective labels. Other times, you'll want to change the label to a more relevant term.
|Relationship||Owner||Related Object||Perspective Label: Owner → Related Object||Perspective Label: Related Object → Owner|
|Product - Brand||Product||Brand||"Product"||"Brand"|
|Employee - Employee||Employee||Employee||"Manager"||"Direct Report"|
|Package Content||Package||Package, Product||"Package Content"||"Package"|
Recursive relationship example
In a recursive relationship, the object refers to itself, so the object name as the default perspective label would be too unspecific. For example, in an Employee recursive relationship, you might change the perspective labels to Direct Reports (Owner) and Managers (Related Object)
John Smith is an employee who manages other employees. On his profile, you can view his relationships with his Direct Reports and his Manager. Without the perspective labels, both of these sections would be called Employee.
Updating perspective labels
If you want to change the perspective label on record profiles, change it in the profile layout. Profile layouts must be created before custom objects can display in Network. The perspective labels are used as the section titles when you create a custom profile layout. The labels in the profile layout drive the name of the relationship object section on record profiles.
If you change the perspective label in the custom relationship object configuration, it does not update the label on the record profile; the updated label is used when you create a new custom profile layout only.
- To change a perspective label on a profile layout, edit the relationship section on the profile layout. Click the existing label for the language to override it by defining the new label.
In this example, HCPs and Studies are connected by the Study Investigator Relationship. The perspective label for HCP was not changed in the relationship object configuration, so the default object name is used.
To change the perspective label for HCPs to Investigators, edit the Health Care Professional section. Override the existing label and type a new label called Investigators.