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.

Relationship cardinality

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

Simple relationships

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.

Example

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.

Arc relationships

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.

Example

The Parent HCO relationship object is an arc relationship; an HCO can have a similar relationship to an HCP or to another HCO.

Recursive relationships

Custom relationship objects can be used so that one main object can refer to itself.

Examples

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.

Example

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?

Limited relationships

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.

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

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.

Edit permissions

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.

Search behavior

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.

Perspective labels

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"
HCP-Study	HCP	Study	"Clinical Trial"	"Investigator"
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)

Example

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.

Example

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.