Introduction
Most people that start creating custom domains in Network likely have a background either in relational databases or in other third-party MDM tools. If your background is in relational databases then you are familiar with terms and concepts like database schemas, tables, cardinalities, primary and foreign keys, etc. And if you have experience with other MDM tools in the market, then you probably know that these applications often have their own specific data modeling concepts.
Veeva Network allows you to create custom data models; for example, to master product data, payer data, or clinical trial data. And Network also comes with its own application data model which has some very specific concepts that you need to be aware of before getting started. Therefore, in the following sections, I would like to explore and deep-dive into these data modeling concepts so that you know how to make the right design decisions when creating a custom domain in Network.
Network Data Model Entities
Let’s start with the various data model entities that are available in Veeva Network. This is basically the tool box that you can choose from when creating a custom data model. And there are four different entity types that are available to you when creating a custom data model:
Data Domain
The data domain is the specific area of activity or knowledge for which you want to manage the data. By default every Network instance comes with a "Customer Master" domain. Examples of custom domains would be "Product Master," "Payer Master," "Clinical Trial Master," and so on.
The data domain’s only purpose is to group the data model objects in your instance by a certain topic or theme. If you have a background in relational databases, think of the data domain as a database schema. That comes probably close to it, although there are some differences of course. Apart from grouping the objects in your instance, the domain doesn’t really drive any functionality. And you can also share objects across multiple data domains (see further below for more details).
Custom Main Object
A main object is used to store the main data entities that you plan to manage in your custom domain. You should start with creating your main objects first, because in contrast to sub-objects or relationship objects, main objects are independent of other objects. In Network Customer Master, HCP and HCO are main objects, and examples of custom main objects are "product," "brand," "payer," "study," "employee," and so forth.
Custom Sub-Object
Unlike main objects, sub-objects cannot exist on their own; they always depend on a main object. Since a sub-object needs to be associated with at least one main object, you should create the sub-object only after you have created your main object. In Network Customer Master, address and license are sub-objects because they always belong to a certain HCP or HCO. Other examples of custom sub-objects could be "indication," "price," "administration route," "certification," and so forth.
Custom Relationship Object
Relationship objects are used to create relationships between main objects. Therefore, they are also dependent on the main objects and should be created after the main objects are created. When it comes to the cardinality of the relationship object you can choose between many-to-many and one-to-many relationships (see details further below). In Network Customer Master, "Parent HCO" is a relationship object and examples of custom relationship objects could be the "brand-product relationship" or the "investigator relationship" between a study and an HCP.
In fact, relationship objects are quite special so I dedicated the complete second part of this article to deep-dive into the specifics of relationship objects.
Default Fields
Whenever a custom object is created, a bunch of default fields will be automatically created along with the object. The specific fields differ slightly depending on the object type; a main object, for example, has slightly different default fields compared to a custom relationship object. But among other fields, the default fields typically include the Network entity ID, the record state, the create and modified date, as well as any required foreign keys to other objects. So you don’t need to bother about creating these types of fields; they are just there after you created the object. You just need to focus on creating the attributes that are specific to your object.
Cross-Domain Objects
Two questions that I am often asked are: "Can I create relationships across domains?" and "Can I reuse objects across domains?" The answer to both of these questions is "Yes!"
Let’s say you have one domain called "Product Master" and a second domain called "Payer Master." In the "Product Master" domain you have one main object called "Product" to store your product definitions, and in the "Payer Master" domain you also need the product definitions so that you can refer to them in your formulary object.
Instead of creating two separate product objects and duplicating the data, you can just reuse the same product object in both domains. A main object can be part of one or many data domains at the same time. And when you add a main object to a second domain, it is still the same object. The object is neither cloned nor is a second instance of the object created. This means that it is exactly the same object with the same data that is just used in more than one domain. So, by reusing objects in several domains, you don’t have to worry about redundant data sets.
As an alternative to adding main objects to two different domains, you can also just create a relationship between two main objects, even if they are in different domains. Let’s say your "Payer Master" domain should also have a relationship with HCOs in order to manage the preferred HCOs for each plan. Then you can create a relationship between "Plan" which is in the "Payer Master" domain and "HCO" which is in the "Customer Master" domain. The HCO object does not necessarily have to be part of the "Payer Master" domain in order to have a relationship with the "Plan" object. You can just create relationships between main objects across different domains.
Next Steps
After you have created your custom domain and custom objects, the next step is to enable all objects because they are disabled by default. Enabling custom objects means making them visible and usable for administrators. This means once custom objects are enabled, administrators can create profile layouts and DVPs for custom objects and can start loading data via source subscriptions or the API. Enabling custom objects does not mean that data stewards or standard users can access the custom objects via the profile page. To make that happen, you (as an administrator) need to first create profile layouts and DVPs that allow other users access to custom objects.