CrossLink FAQ & Use Cases

This article provides answers to frequently asked questions and common CrossLink use cases.

A CrossLink is a document created in your Vault that uses the viewable rendition of another document in another vault as its source document.

For CrossLinks, a source document is a document in another vault which is bound to a CrossLink in your vault. Note that source document elsewhere in Vault refers to the source file or original content for a document.

Oftentimes, content from one vault is needed in another. Instead of downloading a copy of the needed document from one vault and then uploading it to another, a CrossLink can be created to re-use the same source content across multiple vaults to help maintain a “single source of truth” for the content.

Managing documentation across different departments and business processes is a challenging task. It’s not uncommon for multiple copies of documents to be scattered around in different specialized repositories. This poses a tremendous problem for organizations, not only in terms of the time and cost spent reconciling the various versions of content, but also with compliance risk.

CrossLinks provide a single source of truth for content in Vault by eliminating the use of uncontrolled copies of documents when content from one vault is needed in another. This allows users in their individual Vaults to share content within the specific business context which is relevant to their part of the business process without having to be familiar with how the content is used elsewhere in the organization.

Each user must be assigned privileges to create CrossLinks. Even then, they will only see other vaults in the domain and the documents therein which they have been assigned permission to view. That is, they will only be able to create a CrossLink in their Vault from documents in another vault to which they already have access. Once created, viewing the CrossLink is controlled within its own vault in accordance with sharing settings, without being impacted by the source document security.

Any user with permission to view the CrossLink in the CrossLink vault can open and view it. CrossLinks follow the same view permissions as regular documents. It is not necessary to have security to the source document in its source vault in order to view the CrossLink.

Users can view the name of the source Vault in the CrossLink’s metadata, regardless of whether or not they have access to that Vault.

Only if they have access to the source vault and permission to view the source document therein.

No. The CrossLink uses a copy of the viewable rendition from the source document.

Attempting to delete a source document that is being referenced by a CrossLink displays a warning message regarding the CrossLink bound to it. If the user proceeds with the deletion, the link will be broken but the CrossLink will remain. The CrossLink will retain the last synced copy of the content and fields from the source document and become an independent document.

Attempting to delete a source document version referenced by a CrossLink will not display a warning message regarding the CrossLink bound to it. If the user proceeds with the deletion, the CrossLink will retain the last synced copy of the content and the link to the soource document will remain. If the source document continues to be versioned, the version binding will be updated according to the Source Binding Rule.

Nothing. The CrossLink exists independently from the source document. The only change to the source document is that the CrossLink will no longer be listed in the Related CrossLinks document field.

Yes. A source document can be bound to one or more CrossLinks in one or more vaults in the same domain.

No. When creating a CrossLink, you are able to select more than one source document but each will become its own CrossLink.

What types of content can and cannot be bound to CrossLinks?

CrossLinks can be bound to (created from) “standard” documents, placeholders, or planned documents. CrossLinks cannot be bound to binders, unclassified documents, or other CrossLinks.

When creating a CrossLink, the default setting binds it to the latest steady state version of the source document. You can change this to the latest version (including minor versions) or to a specific version of the source document. When binding to the latest steady state version or latest version, the CrossLink is automatically updated when a new version of the source document becomes available.

In the Source Document Details section of the CrossLink document fields panel, use the Source Binding Rule picklist to select a source document version to bind to the CrossLink. You can change the bound version during initial creation of the CrossLink or by editing the CrossLink document fields after it has been created. Binding rules cannot be changed from static to dynamic when the CrossLink is in a steady state. To change the binding to dynamic when the CrossLink is in a steady state, you must create a new draft of the CrossLink.

Yes. CrossLinks almost always have a different document type than the source document. When creating a CrossLink, you must select a document type and (when applicable) a subtype and classification. Since the CrossLink exists in a different Vault than the source document, the available document types will be different.

No. When a CrossLink is created, its version is set to 0.1, just like any other new document. This CrossLink version may be bound to any source document version (0.1, 0.2, 1.0, 1.1, etc.). When a new version of the source document is created and the binding is dynamic, the CrossLink is updated. The CrossLink version, however, changes by progressing through its own lifecycle.

No. CrossLinks have their own lifecycle and workflows, which is based on the document type assigned to the CrossLink. Although inextricably bound to another document in another vault, CrossLinks are, for the most part, independent documents in the CrossLink Vault.

No.

By default, Vault copies over any overlays or signature pages applied to the source document when you create a CrossLink. Depending on your Admin’s configuration, your vault may exclude overlays, signature pages, or both when you create CrossLinks or when they are updated. Note that when you download a CrossLink’s viewable rendition, Vault includes any overlays or signature pages defined in your current vault.

Yes, but only if the CrossLink is bound to a specific version of the source document. If the binding is dynamic, CrossLink annotations would be erased every time a new version of the source document synced with the CrossLink.

Once enabled, users with the System Admin, Business Admin, or Vault Owner permissions may create CrossLinks. Other users must have the Create CrossLinks permission added to their security profile by Admin. All users must have access to at least one other vault in the domain and permission to view the documents therein to link the source file to the CrossLink.

The process of creating a CrossLink is analogous to uploading a new file into Vault. The key difference is that instead of selecting a file from the local file system, browse and select a source document from another Vault in the same domain. You can create CrossLinks from the Create menu, within a binder, or by converting an existing content placeholder into a CrossLink.

Use Vault REST API or the documents Actions menu to archive Crosslinks.

An Admin must enable CrossLinks in your Vault’s General Settings.

All existing CrossLinks will continue to exist and be updated but new CrossLinks cannot be created. Existing CrossLink configuration elements (document fields, relationship types, etc.) will continue to exist.

From the primary navigation bar, look for CrossLinks in the Create menu. If it’s not there, you have not been assigned permission to create CrossLinks or CrossLinks have not been enabled in your vault.

Why couldn’t my source Vault be accessed?

While retrieving a rendition, Vault may display the “Source vault could not be accessed” error. Vault returns this error if the source vault is down for maintenance or if the Vault was deleted. If you see this error, please contact Veeva Support.

Example Use Cases

Source: Clinical Trial Documents in eTMF Vaults:

  • In Submissions vaults, some eTMF documents must be submitted to regulatory authorities. Particularly in the United States, where Investigational New Drug (IND) and New Drug Applications (NDA) submissions contain much of the same content.
  • In MedComms vaults, Final Study Reports should be available to medical teams.
  • In PromoMats vaults, Final Study Reports should be available for PromoMats references.

Literature references in MedComms Vaults:

  • In eTMF vaults, literature references support study protocols and final study reports.
  • In Submissions vaults, literature references must be submitted to regulatory authorities.
  • In PromoMats vaults, literature references support promotional claims.

Manufacturing details (batch records, specifications, certificates of analysis, etc.) in QualityDocs Vaults:

  • In eTMF vaults, investigational product manufacturing details may need to be stored in eTMF.
  • In Submissions vaults, manufacturing details may need to be submitted to regulatory authorities.

Labeling and prescribing information in Submissions Vaults:

  • In eTMF vaults, labeling and prescribing information is needed for investigational labeling.
  • In MedComms vaults, final approved labeling and prescribing information must be available to all medical teams.
  • In PromoMats vaults, final approved labeling is needed as supporting documentation for promotional activities.

Promotional material in PromoMats Vaults:

  • In Submissions vaults, promotional material must be submitted to regulatory authorities, especially for eCTD submissions in the United States.
  • In MedComms vaults, promotional material should be made available to Medical Science Liaison (MSL) teams.