About Vault Components

MDL Components are instances of MDL Component Types and contain specific configuration details. For example a Component Type Docfield has a Component instance Docfield.country__v.

Metadata Component Types

Metadata component types represent specific elements of Vault's configuration. For example, the Docfield metadata component type relates to the Documents object.

You cannot delete a component with a standard namespace and can only make certain changes, for example, updating the label.

Code Component Types

Code components, such as Recordtrigger, contain Java SDK code which extends functional behavior of Vault.

Component Type Names

Component type names are case-sensitive and follow a convention of a capitalized first letter with no spaces or special characters. For example, Objectlifecycle is the component type name for Object Lifecycle.

Component Names

Every component has a name which must be unique within the context of that component type.

Subcomponents must have a name which is unique within context of the parent component and the subcomponent type.

Names are lower-case, snake_cased and are suffixed by a double underscore (__) followed by a namespace. Names must be 40 characters or fewer excluding the double underscore and namespace.

Namespace

The namespace of a component determines the owner of the component, for example, the namespace of country__v is __v which is the Veeva standard namespace. Custom components have the __c suffix. Learn about Namespace in Vault Help.

You cannot delete a component with a standard namespace and can only make certain changes such as updating the label.

Code Component Namespace

Code component names are defined by their fully-qualified Java class name. A fully-qualified Java class name includes the class name prefixed by the package name. In Vault, the package name can be com.veeva.vault.custom.{} for custom Java SDK code or com.veeva.vault.{AppName} for standard system Java SDK code.

For example, a Recordtrigger HelloWorld Java SDK class exists in the com.veeva.vault.custom.triggers package. This would be described with MDL as Recordtrigger.com.veeva.vault.custom.triggers.HelloWorld.

Components with Content

Some components contain binary and significantly larger content which requires a separate process to migrate and reference. The following components include content:

Formattedoutput
Overlaytemplate
Signaturepage

To manage components with content, send a POST request to the api/mdl/files endpoint.

See MDL API Reference.

Subcomponent Reference

This allows you to define subcomponent references in a standard way by reducing repeated effort and providing a consistent behavior.

Managing Subcomponent References

Provide valid references to subcomponents as values for component reference attributes with subcomponent types. Use the following format for the value for the attribute type with a subcomponent reference type:

{subcomponent_type}.{subcomponent_name}

Example

CREATE Checklistmapping example __c (

   label('Example'),
   active(true),
   target_record_object('Object.checklist__sys'),
   target_record_field('Field.target_quality_event__v')
);

Component Directory

The component directory de-normalizes component records into a single queryable data object named vault_component__v. Each component in a Vault will have a record in this object.

This enables Admins to use Vault Query Language (VQL) to query for all components or for specific components and to additionally verify when a component has been modified.

The vault_component__v object includes the following fields of interest:

Name	Description
`component_name__v`	The API name of the component.
`component_type__v`	The component type of the component.
`name__v`	The label of the component.
`checksum__v`	The checksum of the component.
`modified_date__v`	The date & time the component metadata was last modified.

You can retrieve all available fields using the api/{{version}}/metadata/vobjects/vault_component__v API endpoint.