# About Vault Objects Vault Objects are part of the application data model. You're probably already familiar with objects: many standard objects have document fields that you use all the time, like _Product_, _Study_, and _Country_. The application data model is a critical part of what makes each Vault application unique. It provides context information that drives the business processes in each Vault application. Each application has its own distinct application data model. For example, the structure of _Study_, _Site_, _Location_, _Product_, and _Country_ in eTMF is part of the data model. Each of those items is an object. In PromoMats, the data model includes the _Product_ and _Country_ objects. With this feature, Admins can easily customize and extend standard objects in the application data model (_Product_, _Country_, etc.) and create entirely new custom objects to meet their specific business needs. The Vault Objects data model includes: * **Objects**: Top-level in the data model; for example, _Product_, _Country_, and _Study_ are all objects. * **Object Classes**: Classification that applies to multiple objects; for example, _User Role Setup_ and _User Task_ are both object classes. An object with an object class applied has its own relationships, security settings, and custom attributes, but the object has a common set of standard fields and behaviors defined by the object class. * **Object Data Records**: Items within an object; for example, _United States_ and _Canada_ are each object data records within the _Country_ object. * **Object Fields**: Fields that hold details associated with each object data record; for example, _Indication_ and _Product Code_ are fields associated with the _Product_ object. Object fields support UTF-8 3-byte encoded characters. * **Object Types**: Classification within an object that allows organizations to store data that is similar but not identical in a single object * **Object Relationships**: Hierarchical (parent-child) or non-hierarchical (reference) relationships between objects and object data records; for example, a parent-child relationship exists between _Study_ (parent) and _Site_ (child), while a reference relationship exists between _Site_ and _Location_. Reference relationships can also be self-referencing, for example, a _Territory_ object where records can be individual countries or regions, with individual countries referencing a region to create a hierarchy within the object. * **Document Fields**: Metadata fields associated with each document type; for an end user to select an object value/object data record for a field, Admins must configure a document field that corresponds to an object, for example, the _Product_ document field corresponds to the _Product_ object and is associated with all document types. Document fields support UTF-8 3-byte encoded characters. ## Object Capabilities There is a lot of functionality built around objects, including both basic functions like document field linking and more complex capabilities like Custom Sharing Rules and reporting. ### Enhanced Object Record Selection Fields {#lookup} When you click into an object-type document field, you'll see a new picklist that shows the most recently selected data records first, then lists all records in alphabetical order. If you're selecting a child object data record, each option is listed under its parent. For example, when selecting sites, they are grouped together by their parent study. To use a more advanced search to find the correct data record, click the binoculars icon. From the **Search** dialog, you can search and filter to find a specific data record. You can hover over any field in the dialog record grid, and Vault will display a hovercard showing up to 1000 characters of the value of that field. If you're selecting a record for a child object, Vault automatically applies a filter based on the parent data record. You can also click **Select All** to select all available data records or **Unselect All** to clear your selections if you accidentally clicked **Select All**. Note that Vault limits **Select All** functionality based on the maximum number of related records possible for a document.
### Reporting Admins can create custom report types to report on object records (products, departments, sites, etc). Using these report types, a user could view and export object metadata like: * Listing of all products (with or without associated documents) that you can group by product details like _Therapeutic Area_ or _Product Family_ * A listing of sites under each study country * A listing of documents organized by _Owning Department_ and showing the _Department Code_ value for each department ### Attachments Using attachments allows you to upload and connect files to a specific object data record. For example, you could upload logos to each _Product_ record. Admins can enable attachments individually by object, so they are available where relevant (for logos on _Product_ records), but not where they are not needed. ### Dynamic Access Control Dynamic Access Control allows Admins to restrict which users can view, link to, edit, and delete specific object data records through Matching Sharing Rules and Custom Sharing Rules. This feature supports organizations that need to segregate access to individual records within an object, for example, individual products within the _Product_ object or studies within the _Study_ object. Admins enable this feature for specific objects, allowing organizations to provide a more granular level of security for one object without affecting others. ### Object Types {#object-types} An object type is a collection of fields that are grouped to capture similar but not identical data within a single object. For example, the _Product_ object could include two types: _Pharmaceutical_ and _Medical Device_. These object types share fields like _Abbreviation_ and _Internal Name_, but each also has data specific to its business purpose like _Dosage_ for _Pharmaceutical_ and _Model No_ for _Medical Device_. ### Object Relationships In addition to relationships with documents, objects and object records can have relationships to each other . For example, the standard eTMF data model provides a hierarchy of objects: _Study_ to _Study Country_ to _Site_, as well as a reference (non-hierarchical) relationship to the _Location_ object. Relationships can also exist between records within a single object. For example, in the custom _Region_ object, an organization has an _Asia-Pacific_ region, as well as regions for _Southeast Asia_, _Central Asia_, and _Australasia_, which have a hierarchical relationship to the _Asia-Pacific_ region. ### Configurable Object Record Page Layouts Admins can modify the default page layout, by object, for data record detail pages . This feature allows Admins to organize the display of metadata in a way that makes sense for each object. For example, fields like _Last Modified By_ and _External ID_ are often not relevant to a user viewing a _Product_ record, so an Admin may move those fields into a separate panel at the bottom of the product details page. ### Field-Level Encryption All Vault data today is stored securely. For sensitive information like Protected Health Information (PHI) and Personally Identifiable Information (PII), Vault offers a second level of protection that Admins can enable for field values. Vault will provide additional security for values entered into fields where an Admin has enabled this option. They can only enable this option for a maximum of ten (10) fields per object. ### Object Class {#object-class} In the first release of DAC, Vaults included a single _User Role Setup_ object to support access rules. Later, we introduced the concept of an "object class" and _User Role Setup_ became a class of objects, rather than a single object. When using Matching Sharing Rules, each _User Role Setup_-class object can define matching fields for one or more objects . An organization might use multiple _User Role Setup_ objects if they use DAC in different contexts. For example, VeePharm's eTMF Vault controls document access using the _Study_, _Study Country_, and _Study Site_ fields to indicate a user's context. In the same Vault, VeePharm uses _Therapeutic Area_ to indicate a user's context and control access to _Product_ records. If VeePharm had a single _User Role Setup_ object, it would need to include all of these fields. By using two objects with the _User Role Setup_ class, each object needs fewer fields and record setup is easier for each object. Object classes can be used for outside of dynamic access control with the _User Task_ object class. An organization can use _User Task_ -class objects to plan, assign, and track units of work. For example, VeePharm uses a CTMS Vault to manage their clinical trials. VeePharm may use a _User Task_-class object to track ad hoc work needed to bring a site up to compliance. The _Security Tree_ object class allows organizations to control user access to object records through a hierarchical structure, similar to a tree. Access to a Security Tree-class object is based on user and object record assignment to nodes within the _Security Tree_. Object classes can apply to multiple objects. Organizations can configure objects with a class. Those objects will have their own object relationships, security settings, and custom attributes, but those objects will also have a standard set of fields and behaviors defined by the object class. ### Object Data Store Options Vault offers both _Standard_ and _Raw_ data store options for Vault objects, with raw objects optimized for large or frequent transactions. The _Raw_ data store option delivers fast write performance, but has a narrower feature set than standard Vault objects and requires technical knowledge to configure optimally. For this reason, we recommend thoroughly reviewing the documentation on raw objects before using this data store option. ### Locked Objects {#locked-objects} Some objects are only enabled in your Vault if specific applications are licensed. When not enabled, Vault locks these objects, ensuring users do not accidentally interact with functionality designed for unavailable applications. Locked objects are typically hidden in the UI, but Admins can view them in **Admin > Configuration > Objects** by clicking **Show Locked**. However, Admins cannot edit any details on locked objects. ## Vault Objects in Multilingual Vaults Currently, Admins are only able to add translations for field labels, not object data record values. For example, the _Product Name_ and _Country Name_ labels could be translated, but the product and country names (_United States_, _Japan_) could not. [0]: #locked-objects