# Importing Submissions (RIM)

RIM Submissions Archive allows you to import final submission dossiers for your organization's records and users' later review.



<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: These features are only available on RIM Submissions Archive Vaults. Some of these features require an <a href="/en/lr/64130/">Admin’s configuration</a> before you can use them.</p>
    </div>
  </div>
</div>



## Preparing Submissions for Import

Before importing a submission, you must prepare various Vault records. You can also define your desired folder hierarchy for various submission types within your Vault so you don't need to stage submission content outside of Vault. See [Preparing Submissions for Import](/en/lr/64129/) for detailed instructions and information about how Vault imports submissions.

### Choosing an Import Method

When importing submissions into Vault, you must select an import method that is appropriate for your submission package's format and size. Generally, when a submission package's size and structure does not match the chosen import method, imports fail. 
To avoid failed imports, review the submission file size and count [limitations][13] to help choose the correct path for a successful import.

## Supported Versions for Import
Vault currently supports the below eCTD and non-eCTD DTDs and schemas.

Imports will fail for submissions that use an unsupported version.

### Supported DTD & Schema Versions for Import

Vault currently supports the following eCTD DTDs and schemas for ICH 3.2 and 3.0

  * ICH 3.2, 3.0
  * ICH-STF 2.2
  * Australia (AU) 0.90, 3.0, 3.1, 3.2
  * Bosnia and Herzegovina (BA) 3.1
  * Canada (CA) 0.9, 1.0, 2.2
  * China (CN) 1.0
  * Economic Community of West African States (ECOWAS) 1.0
  * Eurasian Economic Union (EAEU) R.022 1.0, 1.1.0
  * European Union (EU) 0.9, 0.92, 1.0, 1.1, 1.2.1, 1.3, 1.4, 2.0, 3.0, 3.0.1, 3.1
  * Gulf Cooperation Council (GCC) 1.0, 1.1
  * Japan (JP) 1.0
  * Jordan (JO) 1.0, 1.1
  * Korea (KR) 1.0
  * Singapore (SG) 1.0
  * South Africa (ZA) 1.0, 2.1, 3.0, 3.1
  * Switzerland (CH) 1.0.1, 1.1, 1.2, 1.3, 1.4, 1.5
  * Taiwan (TW) FDA v1.1 (DTD 1.0), 2.0
  * Thailand (TH) 0.92, 1.0
  * Tunisia (TN) 1.1
  * Ukraine (UA) 1.0
  * United States (US) 2.01, 3.3
  * World Health Organization (WHO) 1.1

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: Eurasian Economic Union (EAEU) R.022 1.0 and 1.1.0 submissions require the Dossier Format to be set to EAEU with a RIM UUID value of de79963b-3c40-4256-8d1a-bb710c68a95b.</p>
    </div>
  </div>
</div>



#### About Japan eCTD 1.0

Japanese eCTD 1.0 submissions must be queued for import in the order in which they were submitted to the Health Authority to ensure that leaf lifecycle operations display properly and cross-document navigation is correct. If you remove and reimport submissions, subsequent submissions in the application must also be removed and reimported. This is only applicable for eCTD submissions.

#### About Implementation Guide & DTD Versioning and Viewing Submissions

In some regions, the Health Authority did not increment the Document Type Definition (DTD) version alongside the Implementation Guide. In other words, the Implementation Guide version is incremented whereas the DTD / XSD version stays the same. 

The Ukraine (UA) Document Type Definition (DTD) is version 1.0 between the pilot and 1.2 specifications. As such, any imports or re-imports of pilot submissions that follow the UA eCTD 1.0 specification will display according to UA eCTD 1.2 expectations. UA 1.0 pilot submissions imported before the release of this feature are unaffected, and will continue to display according to the UA eCTD 1.0 specification.

The China (CN) Document Type Definition (DTD) is version 1.0 for both the 1.0 and 1.1 specifications. As such, any imports or re-imports of pilot submissions that follow the CN eCTD 1.0 specification will display according to CN eCTD 1.1 expectations. CN 1.0 pilot submissions imported before the release of this feature are unaffected, and will continue to display according to the CN eCTD 1.0 specification.

### Supported Versions for ICH eCTD 4.0 Import

Vault currently supports the following eCTD specification versions for ICH 4.0:

* Japan (JP) 1.4, 1.5, 1.6
* United States (US) 1.7, 1.8

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: Japan (JP) v1.4, v1.5, and v1.6 submissions must be imported in sequential order, for example <em>Sequence ID</em> 1 is imported prior to 2, <em>Sequence ID</em> 2 is imported before 3, and so on. When submissions are imported out of sequential order, the submission structure may not display as expected.</p>
    </div>
  </div>
</div>



#### Additional Considerations

Submissions Archive Harmonization job does not yet support Harmonization across ICH 3.2 and ICH 4.0. Therefore, it is recommended to batch imports of United States eCTD 3.2-based submissions into Vault first, wait for the system to complete process all eCTD 3.2 (i.e., ensure all imported Submissions have a Dossier Status of Import Successful,) then import all United States eCTD 4.0 in a separate batch. This is particularly important for custom scripted migrations into Submissions Archive of United States eCTD 4.0 submissions that use eCTD 4.0 Forward Compatibility.


### About Non-eCTD Import

When Vault does not find an index.xml file (eCTD 3.2, 3.0) or submissionunit.xml file (eCTD 4.0) in the submission dossier, it is imported as non-eCTD. The XML eCTD Version column displays "Non-eCTD" for submission content that was imported as non-eCTD.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: Vault supports import for China (CN) non-eCTD, containing index.xml and index-sm3.txt.</p>
    </div>
  </div>
</div>



## Importing Submissions

You can import submission dossiers in several ways.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: For performance reasons, Vault does not populate the <em>Submissions</em> document field for any util files in eCTD submissions during import.</p>
    </div>
  </div>
</div>



### How to Import Submissions {#how-to-import}

To import a submission dossier:

  1. Navigate to the _Submission_ record. You can also access submissions from their related _Application_ records.
  2. From the **Actions** menu, select **Import**.
  3. In the **Submissions Archive Import** dialog, click **Choose** and select the target ZIP or TAR.GZ dossier file you've prepared according to the import [File Size Limitations][11]. Depending on your Vault's configuration, you can alternatively import these files from your Vault's file staging, or from Vault File Manager:
      * To add larger dossiers via the FSS, choose whether to upload to the **File Staging root folder** or **File Staging user folder** and use the drop-downs to select a folder from either the root _SubmissionsArchive_ folder or from the _Submissions Archive Import_ folder in your personal directory. To upload to the FSS root folder, a user must have [adequate permissions](/en/lr/38653/#staging_server_permissions) provided by their security profile.
      * If you're working on a Windows computer, choose **Vault File Manager** to [import the submission dossier from the Vault File Manager client](/en/lr/62385/). See also [File Size Limitations][11].
  4. Click **Next**.
  5. In the confirmation dialog, review the application folder name, submission folder name, and any warnings. If these details are acceptable, click **Import**. If your submission contains an invalid XML, Vault displays a warning or blocks the import, depending on your Admin's configuration. In order to import an eCTD submission, it must contain the util folder and the XMLs cannot be malformed.
  6. Vault populates select [document fields][4] automatically on import, creates or updates a related [_Dossier Details_][5] record, and updates the [_Submission Archive Status_ field][6] on the _Submission_ record throughout the import process. When the import is complete, you'll receive an email and a Vault notification. If two or more imports to the same Submission occurs, Vault attaches a new _Submissions Archive Import Results_ CSV file with its own unique file name.

In the **Import Submission** dialog, Vault hides the option to upload to the **File Staging root folder** if there is no _Submissions Archive_ folder in file staging's root. Vault hides the **File Staging user folders** option if you don't have _File Staging: Access_ permission, or if there is no _Submissions Archive Import_ folder within your Staging folder.

On file staging, the _SubmissionsArchive_ folder is visible to System Administrator and Vault Owner security profiles. All other users with file staging access should stage imports to the **File Staging user folder**.

### How to Import Common Submissions in Bulk {#bulk-import}

From a list of _Submission_ records, you can import a single dossier to multiple submissions using a [bulk action](/en/lr/33725/). When importing in bulk, we recommend using this method for any submission which is not a US eCTD grouped submission.

On the **Choose Action** page, select the **Submissions Archive > Import** action. On the **Submission** page, the import options you see depend on your permissions and file staging configuration. When enabled, Vault also includes a step to manually map submission metadata to various Vault object records for eCTD submissions.

When you click **Finish**, Vault imports the dossier asynchronously and sends you an email and a Vault notification containing import successes and failures.

#### Importing US eCTD Grouped Submissions

To import US eCTD grouped submission dossier files, create any additional _Submissions_ in the Vault UI first, then import the files. During this operation, Vault prompts you to map the additional _Submissions_ referenced in the regional XML.

We recommend this method as other import methods (Vault API, Vault File Manager) do not provide a mapping page and therefore do not automatically import into the secondary _Submissions_.

### How to Reimport Submissions {#reimport}

You may need to replace a submission that was imported previously, for example, when a leaf operation is incorrect or a file needs to be replaced prior to finalizing the dossier. With the **Reimport** action, you can remove the previous submission and import a new submission in a single step:

  1. Navigate to the _Submission_ record from Business Admin or a custom tab. You may also be able to access submissions from their related _Application_ records.
  2. From the **Actions** menu, select **Reimport**. Your Admin must grant you the correct [permissions][9] to see this action.
  3. Select an import option from the [**Import Submission** dialog][10] and complete the import.
  4. Vault removes the existing dossier and queues the new dossier for import. Once the import is complete, Vault will send you a notification. If two or more imports to the same Submission occurs, Vault attaches a new _Submissions Archive Import Results_ CSV file with its own unique file name. 

### Importing Many Submissions at Once {#importing-many-submissions}

Veeva Services and Veeva Migration partners are available to support devising the migration approach for importing many unique submissions in bulk (for example, importing 50 unique submissions into an application). Alternatively, the Submissions Archive Import API endpoint is <a class="external-link " href="https://developer.veevavault.com/api/24.1/#import-submission" target="_blank" rel="noopener">available here<i class="fa fa-external-link" aria-hidden="true"></i></a> for custom migration script development.

### About Submissions Archive Documents {#document_fields}

When you import a submission, Vault automatically creates a _Source References_ relationship between the source document and the _Submissions Archive_-type document when the file's checksum matches. If an active _Content Plan Item_ record in the submission content plan has a _Published Output Location_ that corresponds to a file location in the current import, Vault uses the matched document as the source for the _Submissions Archive_-type document as well.

At submission import, Vault also populates the following document fields:

  * **Applications** (`applications__v`): Any _Applications_ to which the archived document belongs.
  * **Submissions** (`submissions__v`): Any _Submissions_ to which the archived document belongs. This field updates each time the document is used.
  * **Archive Sections** (`archive_sections__v`): The top-level XML element (for eCTD submissions) or top-level folder (for non-eCTD submissions) where the archived document exists.
  * **Submissions Archive Document Section** (`submissions_archive_document_section__v`): Locations of a document inside an archived submission. For eCTD submissions, this is the XML element path (excluding node extensions), for example, m2-common-technical-document-summaries/m2-2-introduction. For non-eCTD submissions, this is the document's complete folder path, for example, 5 LABELING/5.01 Chapter Table of Contents.

You can search on these fields to find submission documents in your Vault.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: For performance reasons, Vault does not populate the <em>Submissions</em> document field for any util files in eCTD submissions during import.</p>
    </div>
  </div>
</div>



### About Dossier Details {#dossier-details}

When the submission import completes successfully, Vault creates a new _Dossier Detail_ record or updates the following fields if a record already exists:

  * **Dossier Status**: The status of the associated dossier. Similar to _Submissions Archive Status_, Vault updates this field as the submission progresses through import or removal.
  * **File Count**: The number of files in the associated dossier.
  * **Size MB**: The size of the associated dossier.

You can access the related _Dossier Detail_ record from the _Dossier Detail_ field on the _Submission_ record.

### Accessing Submission Import Results {#import-results}

When the submission import completes, you'll receive an email and a Vault notification. If attachments are enabled on the _Submission_ object, Vault also adds the import results as an attachment on the _Submission_ record.

To view the import results CSV file, open the _Submission_ record and expand the _Attachments_ section. From here, you can [work with attachments](/en/lr/58613/#working-with-attachments) as usual. 

If two or more imports to the same Submission occurs, Vault attaches a new _Submissions Archive Import Results_ CSV file with its own unique file name. A new CSV file is attached each time the **Import** or **Reimport** actions are executed.

### About Duplicate Content Detection {#duplicate-detection}

If your Admin has enabled Duplicate Content Detection, Vault reuses existing Submissions Archive documents based on the MD5 checksum value rather than creating duplicate documents each time you import a new submission. See [Using Duplicate Content Detection](/en/lr/21893/) for additional information about how Vault prevents duplicate documents.

### About XML Renditions {#xml-renditions}

When you import a submission containing valid XML files, Vault creates PDF viewable renditions based on the DTD/XSD and stylesheet included in the submission. To generate renditions for existing submission XMLs, select **Re-render Document** from the XML file's **Actions** menu.

Vault can generate PDF renditions for the following XMLs:

  * Index
  * Regional (us-regional, eu-regional, etc.)
  * SPL
  * STF
  * Define

  EAEU R.022 XML files are not rendered.

### SPL Rendition Requirements {#spl-renditions}

For SPL XML files, Submissions Archive generates a stylized PDF viewable rendition based on the stylesheet if the source file is located within a folder named `spl`. For example, `.../labeling/spl/example_spl.xml`.

You may encounter a scenario where an SPL XML file displays a stylized rendition even though its Source File Path does not contain an `spl` folder. This occurs when **Duplicate Content Detection** is enabled in your Vault. Vault is reusing an identical file (based on its checksum) that was previously imported into an `spl` folder in another submission.

To verify a file's location, you can add the Source File Path column to the document grid from **All Actions > Edit Columns**. This allows you to confirm whether the file resides in an `spl` folder. To investigate which other submission(s) in Submissions Archive use the same file, open the document in the **Mini-Browser** and expand the **Where Used in Archive** section.

## Removing Submissions

You may occasionally upload incomplete submissions or submissions with mistakes. When you remove a submission, Vault deletes any sections created in the archive. The documents no longer appear in the [**Viewer**](/en/lr/450731/) tab, and users will not be able to access them using cross-document navigation. Vault also clears the _Applications_ and _Submissions_ document field values, which qualifies the document for the [Submissions Archive Delete Orphaned Files job] [12].

Vault deletes documents from removed submissions based on the status of Submissions Archive Delete Orphaned Files job. If the job is active, Vault deletes Submissions Archive documents that are without Application and Submission document field values, based on the configured schedule. If the job is inactive, Vault will not delete the Submissions Archive documents. When an ICH eCTD 4.0-based submission is removed from the Submission Archive, Vault also deletes the _Application eCTD Keyword_ records associated with that Submission.

### How to Remove Submissions {#removing-submissions}

To remove a submission, navigate to the individual _Submission_ record and select **Remove** from the **Actions** menu. You do not need to wait for Vault to finish removing a submission before removing a second.

## Canceling Imports & Removals

If you need to remove a submission that has not yet finished importing, you can choose **Cancel Import** from the submission record's **Actions** menu. Conversely, you can cancel an in-progress removal by selecting **Cancel Removal**.

## About the Submissions Archive Status Field {#archive-status}

Vault updates the _Submissions Archive Status_ field (`archive_status__v`) as submissions progress through import or removal.

|Status|Description|
|--- |--- |
|Empty|There is no imported content associated with the _Submission_ record.|
|TRANSFER_INITIATED|Submission content is uploading in Vault File Manager. After the upload completes, Vault queues the submission for import and starts the import process.|
|IMPORT_IN_QUEUE|Submission is in queue for import.|
|IMPORT_IN_PROGRESS|Vault is processing the submission import.|
|IMPORT_SUCCEEDED|Submission was successfully imported and is available for viewing.|
|REMOVAL_IN_QUEUE|Submission is in queue for removal.|
|REMOVAL_IN_PROGRESS|Vault is processing the submission removal.|
|NULL|Submission was successfully removed or submission upload from Vault File Manager was successfully canceled.|
|ERROR|Submission import or removal failed, or submission reimport was canceled. See the Vault notification for details on the reason for failure.|

## Submissions Archive Delete Orphaned Files Job {#submissions-archive-delete-orphaned-files-job}

Submission documents can become "orphaned" when a user imports them as part of a Submissions Archive dossier, then removes the submission structure. In situations like this, organizations often need to delete the documents to prevent users from referencing them. Vault can automatically delete these documents as a daily batch job. Vault can delete up to 10,000 documents each time the job runs.



<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: The <em>Submissions Archive Delete Orphaned Files</em> job is designed to remove imported documents. If your organization manually creates documents of the <em>Submissions Archive</em> (<code class="language-plaintext highlighter-rouge">archive__v</code>) type, we do not recommend enabling the job. Vault will delete manually-created documents of this type, even if the <em>Application</em> and <em>Submission</em> fields are populated.</p>
    </div>
  </div>
</div>



### Job Instance Details

The *Submissions Archive Delete Orphaned Files* job cannot run concurrently with a submission import or removal.

When an import or removal is in progress, Vault skips the *Submissions Archive Delete Orphaned Files* job and logs its job status as "Missed Schedule" in **Admin > Operations > Job Status**.

### Criteria

Vault identifies documents to delete using the following document field value criteria:

  * _Document Type_ is _Submissions Archive_ (`archive__v`)
  * Document is not referenced in a binder generated from a Submissions Archive import
  * Document does not have an associated CrossLink
  * Document is not in an active workflow
  * Document is not on Legal Hold
  * Document is not associated with one or more object references
  * Document does not have unresolved annotations
  * Document was last modified more than one day ago (the _Last Modified_ value is greater than 24 hours)

Auto-delete has the same restrictions as the standard **Delete** action.

## Submission Archive Harmonization Job

RIM Submissions Archive includes the **Submission Archive Harmonization** job. When scheduled, the job corrects leaf lifecycle operations, which corrects instances when submissions have broken references. The job also corrects the eCTD submission placeholder files Vault creates when processing bulk imports asynchronously.

### Job Instance Details

Vault skips the _Submissions Archive Harmonization_ job and logs it as _Missed Schedule_ in the history if there is an import or removal job running when the harmonization job attempts to run.

This can also occur for multiple _Submissions Archive Harmonization_ job instances. For example, after a successful import, Vault schedules the _Submissions Archive Harmonization_ job to run when the import queue is empty. If the daily _Submissions Archive Harmonization_ is scheduled to run again within 24 hours, Vault updates the daily job's status to _Missed Schedule_.

Each time the Harmonization job fixes eCTD 4.0 keywords, it addresses all pending corrections for a maximum of 20 minutes per job run. In the event there are keywords remaining that are not addressed within the 20 minute period, those keywords will be addressed during the next Submissions Archive Harmonization job run. Vault Admins can review when the system has Keywords pending resolution from **Admin > Operations > Job Status > History**, by downloading the Job Log from the Job ID column for the Submissions Archive Harmonization. The Job Log text file reads: “Time limit of 20 minutes exceeded. Skipping remaining submissions for this application, these submissions will be processed the next time the Harmonization job runs.”

Additionally, the user who initiated the import receives a Warning notification in the SubmissionsArchive import complete with warnings email notification that says “There is one or more items not found in this import, see the Submissions Archive Items Not Found file attachment on the Submission record for more information”. The new system-generated CSV file, Submission Archive Items Not Found, informs the import user when a Suspend operation cannot be immediately displayed due to importing sequences out of order. 

## Errors & Limitations {#errors-and-limitations}

### File Size & Count Limitations {#file-size-limitations}

Use the below table to determine which import method to use. If your submission exceeds the limit for one method, use the next method in the list.

| Import Method | Package Format | Limitations |
|---|---|---|
| UI upload | Compressed (ZIP or TAR.GZ) | File must be 4GB or less. <br>Before compression, the file should be 10GB or less **and** file count must be 20,000 or fewer. |
| [Vault File Manager](/en/lr/62385/) | Compressed (ZIP or TAR.GZ) | File must be 10GB or less **and** file count must be 20,000 or fewer. <br>See [additional details][14] on the extracted file limits for this method. |
| [Vault File Manager](/en/lr/62385/) | Uncompressed | Total submission size must be 100GB or less **and** file count must be 100,000 or fewer. |
| <a class="external-link " href="https://developer.veevavault.com/api/24.1/#import-submission" target="_blank" rel="noopener">Vault API<i class="fa fa-external-link" aria-hidden="true"></i></a> via [file staging](/en/lr/38653/) | Compressed (ZIP or TAR.GZ) or<br>Uncompressed | No file size or count limits. This is the required method for submissions exceeding the Vault File Manager limits. |

#### About Compressed File Imports with Vault File Manager {#about-compressed-file-imports-with-vault-file-manager}

When using a compressed file to import with [Vault File Manager](/en/lr/62385/), we recommend first reviewing files in both their compressed and uncompressed formats prior to beginning the import process.

This is because, when importing a compressed ZIP or TAR.GZ file, Vault File Manager verifies both:

* The size of the compressed file when you select it for upload, and 
* The total size and file count of the submission once the files are extracted.

Imports fail when Vault File Manager determines that the files reviewed during these checks do not meet the file size and count limitations. This means that an import fails when either the initial compressed file or its extracted contents exceed the 10GB size limit of the 20,000 file count limit described in the table above. 

### File Limitations

Vault excludes `.ds_store` and `thumbs.db` files from submission imports as they are not part of the dossier.

### Import & Removal Limitations

In some cases, concurrent submission imports and removals may be in progress. Submission removals will not occur while there are ongoing submission imports for the same application.

### Folder Hierarchy Import Errors

If you've defined [folder hierarchies](/en/lr/64129/#hierarchy) for submission types within your Vault, you may see import errors under the following circumstances:

  * If the _Dossier Format_ field is populated on the _Submission_, but the _Parameter_ field contains less than two (2) folder parameters
  * If the _Dossier Format_ field is populated on the _Submission_, but the _Parameter_ field references fields on objects that are not the _Application_ or _Submission_ object
  * If an object field specified in the _Parameter_ field is empty or null
  * (For eCTD submissions) If the _Index XML_ is found at the root folder and the _Parameter_ field contains less than two (2) folder parameters, or the corresponding fields are empty or null
  * (For eCTD submissions) If the _Index XML_ is found at the root folder and both the _Dossier Format_ and _Submission ID_ fields are empty
  * (For eCTD submissions) If the _Index XML_ is found within the first two (2) folders but the _Parameter_ field contains more than two (2) folder levels

If the corresponding values for the first two folder _Parameters_ contain an invalid character, Vault replaces the invalid Windows folder characters with a hyphen (**-**) and stores the modified value as part of the source file path. You won't see warnings or errors if this occurs.

### Non-UTF-8 Characters {#non-utf-8-characters}

When importing a ZIP file, filenames cannot include non-UTF-8 characters. If a ZIP file contains filenames with these characters, you will see the following error:

_The archive package did not extract successfully. To import this submission, place the folders and files in the Vault's File Staging and restart the import._

As a workaround, you can unzip the archive and recompress it using TAR.GZ compression. You can also bypass this issue by uploading the files to your Vault's [file staging](/en/lr/38653/).

### Import Warning & Error Details

When you see the following warning, error, or informational messages after submission import, follow these actions to resolve issues:

<table class="wbord">
  <tr>
    <td>
      <p>
        <strong>Message</strong>
      </p>
    </td>
    <td>
      <p>
        <strong>Type</strong>
      </p>
    </td>
    <td>
      <p>
        <strong>Description</strong>
      </p>
    </td>
    <td>
      <p>
        <strong>Action</strong>
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        STF {0} contains an empty reference and was skipped.
      </p>
    </td>
    <td>
      <p>
        Warning
      </p>
    </td>
    <td>
      <p>
        A Study Tagging File contains no leaf references. This may impact how the leaf displays within the Submissions Archive Viewer.
      </p>
    </td>
    <td>
      <p>
        Open the referenced XML and confirm that no leaf references exist. If there are no leaf references in the XML, you can ignore the warning message. If leaf references are present, contact your Veeva representative for assistance.
      </p>
    </td>
  </tr>
<tr>
    <td>
      <p>
        Files not referenced by the submission XML were found within the submission folder. These files were omitted from import: {0}
      </p>
    </td>
    <td>
      <p>
        Warning
      </p>
    </td>
    <td>
      <p>
        Vault did not import one or more files present in the submission package because they are not referenced in the submission's XML. This warning appears when the <strong>Import files not referenced in the eCTD XML</strong> Application Setting is disabled.
      </p>
    </td>
    <td>
      <p>
        Review the <strong>Import files not referenced in the eCTD XML</strong> setting in <strong>Admin > Settings > Application Settings</strong>. When disabled, Vault omits files which are not referenced by the submission XML. When enabled, Vault imports the files which are not referenced as "Unreferenced Files". Such files display in Submissions Archive Viewer as additional folders under the user-friendly structure in the <strong>Name</strong> column.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        An error occurred when importing the submission, document {0} id {1} from submission {2} is no longer available in Vault. Contact support for assistance.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        A document was deleted by a user or by Vault during an import.
      </p>
    </td>
    <td>
      <p>
        Reimport the submission's dossier. If the issue persists on subsequent imports, contact your Veeva representative for assistance.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
       Vault cannot proceed with import because the _Dossier Format_ field has no value.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The fields referenced by the <em>Dossier Format</em>'s import parameter do not contain a value. For example, the <em>Dossier Format</em> parameter references the <em>application__v.folder_name__v</em> field but the field is not populated.
      </p>
    </td>
    <td>
      <p>
        Populate the fields referenced in the notification and then reimport the dossier.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Submission folder was not found, populate the submission {0} XML Submission ID field before proceeding with the import.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        No Submission folder is present within the ZIP/TAR.GZ package and the <em>xml_submission_id__v</em> field on the <em>Submission</em> record is not populated. Vault will attempt to use the value in the <em>xml_submission_id__v</em> field as the Submission folder when the ZIP file doesn't include a Submission folder and the <em>Dossier Format</em> is not defined on the <em>Submission</em> record.
      </p>
    </td>
    <td>
      <p>
        Reimport the submission after making one of the following corrections:
      </p>
      <ul>
        <li aria-level="1">
          Specify a <em>Dossier Format</em> on the <em>Submission</em> record
        </li>
        <li aria-level="1">
          Select a value in the <em>xml_submission_id__v</em> field
        </li>
        <li aria-level="1">
          Repackage the ZIP/TAR.GZ file to include a Submission folder
        </li>
      </ul>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Submission folder was not found, the folder name {0} was used.
      </p>
    </td>
    <td>
      <p>
        Informational
      </p>
    </td>
    <td>
      <p>
        Vault applied the <em>Dossier Format</em> or the <em>xml_submission_id</em> value on the <em>Submission</em> record as the Submission folder because a Submission folder was not included in the imported submission package.
      </p>
    </td>
    <td>
      <p>
        Confirm that the Submission folder name appears as expected. No additional action is required.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        The uncompressed submission exceeds {0}GB, use Vault File Staging to import larger submissions.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The uncompressed ZIP or TAR.GZ file exceeds the Vault limit for uncompressed packages.
      </p>
    </td>
    <td>
      <p>
        Uncompress the submission and import it via file staging or Vault File Manager.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        The uncompressed submission exceeds {0} documents, use Vault File Staging to import larger submissions.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The uncompressed ZIP or TAR.GZ file exceeds the Vault limit for uncompressed packages.
      </p>
    </td>
    <td>
      <p>
        Uncompress the submission and import it via file staging or Vault File Manager.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Document {0} exceeds the maximum number of object references in a field and cannot be updated.
      </p>
    </td>
    <td>
      <p>
        Informational
      </p>
    </td>
    <td>
      <p>
        Vault is unable to add more object references to one or more fields on the imported document. For example, the <em>ich-ectd-3-2.dtd</em> field already references the maximum number of <em>Application</em> records.
      </p>
    </td>
    <td>
      <p>
        The population of the document field does not directly impact Submissions Archive functionality. If document security is dependent on these fields being populated, your Vault might need to use a different security model for these common files.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Picklist value {0} ({1}) was not created properly in {2} ({3}). Remove and re-import the submission again.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The <em>Archive Section</em> picklist value was not successfully created during the import process.
      </p>
    </td>
    <td>
      <p>
        Reimporting the submission should correct this behavior. If the issue persists on subsequent imports, contact your Veeva representative for assistance.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        [{0}] (archive_status__v) is missing from the Submission object type definition. Contact the Vault administrator to update the Submission object type configuration before importing.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The <em>Submissions Archive Status</em> field must be available on the <em>Submission</em> record prior to import.
      </p>
    </td>
    <td>
      <p>
        Add the <em>Submissions Archive Status</em> field to all <em>Submission</em> object types and reimport the submission.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Application folder was not found, the folder name {0} was used.
      </p>
    </td>
    <td>
      <p>
        Informational
      </p>
    </td>
    <td>
      <p>
        Vault applied the <em>Dossier Format</em> value or the <em>folder_name__v</em> field value as the Application folder because the submission package did not include one.
      </p>
    </td>
    <td>
      <p>
        Confirm that the Application folder name appears as expected. No additional action is required.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Application folder was not found, populate the application {0} folder name field before proceeding with the import.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        No Application folder is present within the ZIP or TAR.GZ package and the <em>folder_name__v</em> field on the <em>Application</em> record is not populated. Vault will attempt to use the value from the <em>folder_name__v</em> field as the Application folder when an Application folder is not included in the ZIP file and a <em>Dossier Format</em> is not defined on the <em>Submission</em> record.
      </p>
    </td>
    <td>
      <p>
        Reimport the submission after making one of the following corrections:
      </p>
      <ul>
        <li aria-level="1">
          Specify a <em>Dossier Format</em> on the <em>Submission</em> record
        </li>
        <li aria-level="1">
          Select a value in the <em>folder_name__v</em> field on the <em>Application</em> record
        </li>
      </ul>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        Unsupported {0} operation on leaf {1} &#8211; {2}.
      </p>
    </td>
    <td>
      <p>
        Warning
      </p>
    </td>
    <td>
      <p>
        During import, Vault was unable to locate the target of the lifecycle operation. This may occur if:
      </p>
      <ul>
        <li aria-level="1">
          The target leaf has not been imported
        </li>
        <li aria-level="1">
          The path to the target leaf is invalid, for example, if the target's Application or Submission folder name is incorrect
        </li>
        <li aria-level="1">
          The leaf ID does not exist in the target submission's XML
        </li>
        <li aria-level="1">
          The leaf operation is considered invalid, for example, trying to replace a leaf that was already deleted by another sequence
        </li>
      </ul>
    </td>
    <td>
      <p>
        Vault corrects some of these occurrences automatically when the target submission is imported or when the <em>Submissions Archive Harmonization</em> jobs completes. If this doesn't correct automatically:
      </p>
      <ul>
        <li aria-level="1">
          Verify that the node displays properly in the Submissions Archive Viewer. If it does, no additional action is required.
        </li>
        <li aria-level="1">
          Verify that the leaf exists in the target application and submission. You may need to reimport the target submission. Contact your Veeva representative to help verify the cause.
        </li>
      </ul>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        STF for study {0} references leaf id {1} that is not found in the submission.
      </p>
    </td>
    <td>
      <p>
        Warning
      </p>
    </td>
    <td>
      <p>
        The Study Tagging File references a leaf node that was not found within the submission's Index XML. This impacts how the STF content is displayed in the Submissions Archive Viewer.
      </p>
    </td>
    <td>
      <p>
        Confirm that the leaf ID referenced by the XML is present within the Index XML. If it is, you may need to reimport the submission with the four-digit sequence ID as the Submission folder, or you may need to update the field referenced by the <em>Dossier Format</em> parameter with the four-digit sequence ID. If the issue persists after reimport, contact your Veeva representative for assistance.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        {0} is invalid. Correct the XML and import the submission again.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The Index or Regional XML is invalid against the DTD or XSD.
      </p>
    </td>
    <td>
      <ul>
        <li aria-level="1">
          Confirm that the util folder and referenced DTD/XSD files are present.
        </li>
        <li aria-level="1">
          Enable the <strong>Allow Imports to proceed with invalid XML</strong> setting on the <strong>Application Settings</strong> page and reimport the submission.
        </li>
      </ul>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        The DTD or schema version is not currently supported. {0}
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The version specified in the Regional or Index XML is not currently supported for import.
      </p>
    </td>
    <td>
      <p>
        Contact your Veeva representative for information about when the version will be supported.
      </p>
      <p>
        If an interim workaround is required, rename the Index XML and reimport the submission. If the Index XML is not found, Vault will reimport the submission as a non-eCTD.
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p>
        {0} was not found. Verify the XML file is in the correct file staging location.
      </p>
    </td>
    <td>
      <p>
        Error
      </p>
    </td>
    <td>
      <p>
        The index references a Regional XML that is not present within the specified location.
      </p>
    </td>
    <td>
      <p>
        Confirm whether the Regional XML is present in the location specified by the Index XML. If the file is present and the issue persists, contact your Veeva representative for assistance.
      </p>
    </td>
  </tr>
  <tr>
    <td>
       <p>The XML leaf checksum does not match the file's checksum: {Title: filename, ID:}</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>The checksum specified in the XML or index-md5.txt file does not match the calculated checksum of the document.</p>
    </td>
    <td>If the warnings are unexpected, retrieve the submission from the source location and reimport it.<br>
    If you imported via file staging, confirm that your client was set to transfer as binary. If it was not, update the setting on your client, delete the submission from file staging, reupload the submission to file staging, and then reimport the submission.</td>
  </tr>
  <tr>
    <td>
       <p>Submission folder name does not match the Submission record name</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Vault detected an inconsistency between the Submission folder and the <em>Submission</em> record name.</p>
    </td>
    <td>Confirm that the Submission folder name appears as expected. No additional action is required.</td>
  </tr>
  <tr>
    <td>
       <p>Application folder name does not match the Application record name</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Vault detected an inconsistency between the Application folder and the <em>Application</em> record name.</p>
    </td>
    <td>Confirm that the Application folder name appears as expected. No additional action is required.</td>
  </tr>
  <tr>
    <td>
       <p>The following eCTD leafs were not found. Vault created a placeholder to represent each missing leaf:{Title: filename, ID:}</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Vault created placeholders for missing leaf documents. </p>
    </td>
    <td>Confirm the result is as expected. If the result is not expected, confirm that all files exist within the location referenced in the XML.</td>
  </tr>
  <tr>
    <td>
       <p>This submission folder has already been used for a previous import.</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Another submission within the same application that uses the same import location is being processed.
       </p>
    </td>
    <td>Confirm the duplicate import is intentional.</td>
  </tr>
  <tr>
    <td>
       <p>Submission folder name does not match the dossier Submission identifier.</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Folder name does not match the dossier identifier.</p>
    </td>
    <td>Confirm the results are expected. If not expected, the submission may need to be reimported.</td>
  </tr>
  <tr>
    <td>
       <p>Application folder name does not match the dossier Application identifier.</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Folder name does not match the dossier identifier.</p>
    </td>
    <td>Confirm the results are expected. If not expected, the submission may need to be reimported.</td>
  </tr>
  <tr>
    <td>
       <p>Submission folder name does not match the Submission record sequence number.</p>
    </td>
    <td>
       <p>Informational</p>
    </td>
    <td>
       <p>Submission folder name does not match the Submission record sequence number.</p>
    </td>
    <td>Confirm the results are expected. If not expected, the submission may need to be reimported.</td>
  </tr>
  <tr>
    <td>
       <p>Zero (0) KB files found and omitted from import: {IDs}</p>
    </td>
    <td>
       <p>Warning</p>
    </td>
    <td>
       <p>Vault detected and omitted empty files during import.</p>
    </td>
    <td>Verify the files are 0 KB. If they are not, contact your Veeva representative.</td>
  </tr>
  <tr>
    <td>
       <p>The following XML files cannot be rendered. Contact support for further assistance. {list of leaf nodes}</p>
    </td>
    <td>
       <p>Warning</p>
    </td>
    <td>
       <p>Vault cannot render missing leafs.</p>
    </td>
    <td>Confirm the result is as expected. If the result is not expected, confirm that all files exist within the imported archive.</td>
  </tr>
  <tr>
    <td>
       <p>An error occurred when importing the submission. The document field {field name} on document type {document type} cannot be populated.</p>
    </td>
    <td>
       <p>Error</p>
    </td>
    <td>
       <p>Import cannot be completed with the required field on the document type.</p>
    </td>
    <td>A required field must be removed from the document type for Vault to proceed with the import.</td>
  </tr>
    <tr>
    <td>
       <p>One or more filenames in this import package exceed the byte limit for import.</p>
    </td>
    <td>
       <p>Error</p>
    </td>
    <td>
       <p>At least one file name in the submission package exceeds Vault's 255 byte limit for file names. </p>
    </td>
    <td><p>Verify the file names are under the 255 byte limit.</p> 
    <p>This error may be encountered when submission packages have file names where characters require multiple bytes in UTF-8 encoding, such as Chinese, Japanese, Korean, or Cyrillic characters where a single character may be equal to more than one byte.</p> </td>
  </tr>
      <tr>
    <td>
       <p>Vault found the following documents are missing a primary file name, and is using the file extension as the Document Name. Here are the Document Names in Submissions Archive.</p>
    </td>
    <td>
       <p>Warning</p>
    </td>
    <td>
       <p>An imported dossier contains one or more files that lack a primary filename (for example, the filename is only the extension .docx). Vault uses the file's extension as the Document Name for the Submissions Archive Document during import, and the 'Import complete with warnings' notification lists each Document Name for user review.
 </p>
    </td>
    <td><p>Verify the files in the imported dossier contain a primary filename</p> 
  </td>
  </tr>
      <tr>
    <td>
       <p>Document Published Output Location must be unique. Target source relationships are not created for documents with the same Publishing Output Location.</p>
    </td>
    <td>
       <p>Warning</p>
    </td>
    <td>
       <p>This warning appears when multiple <em>Content Plan Items</em> have the same <em>Published Output Location</em>, which is used in the archive process to find the source reference document. In these cases, only one document can be the source.
 </p>
    </td>
    <td><p>For non-Publishing customers, ensure the <em>Published Output Location</em> (POL) matched with the target publishing POL.</p> 
  </td>
  </tr>
      <tr>
    <td>
       <p>Duplicate detection found multiple SubmissionsArchive matches for the following files: {document}</p>
    </td>
    <td>
       <p>Warning</p>
    </td>
    <td>
       <p markdown="span">Vault located a document with [duplicate content](/en/lr/28082/#duplicate-detection) when comparing the Submissions Archive document with the normal Library document.
 </p>
    </td>
    <td><p>Use the message's Submissions Archive links to locate the duplicate documents, then remediate by deleting the source reference which is not needed.</p> 
  </td>
  </tr>

</table>

## Related Permissions {#permissions}

|Type|Permission Label|Controls|
|--- |--- |--- |
|User License Type|Full User|Ability to access the **Import** option from the **Actions** menu.|
|Security Profile|Application: RIM Submissions Archive: Import|Ability to access the **Import** option from the **Actions** menu and cancel in-progress submission imports or removals; ability to access the **Reimport** action.|
|Security Profile|Application: RIM Submissions Archive: Import from File Manager|Ability to import a submission from Vault File Manager. You also need the _Submissions Archive: Import_ permission, but you do not need the _Application: File Staging: Access_ permission.|
|Security Profile|Application: File Staging: Access|Ability to import submissions via Vault file staging.|
|Security Profile|Object: Country: Read|Ability to import a _Submission_ where the regional XML references _Countries_.|
|Security Profile|Object: Dossier Details: Read|Ability to access the related _Dossier Detail_ record that Vault creates or updates when importing a submission.|
|Security Profile|Object: Language: Read|Ability to import a _Submission_ where the regional XML references _Languages_.|

In addition to the permissions above, you need the _Object Action: View_ and _Object Action: Execute_ permissions on the _Submission_ object to access the following actions: _Remove_, _Import_, _Cancel Import_, _Cancel Removal_, _Reimport_, and _Cancel Upload_.

[4]: #document_fields
[5]: #dossier-details
[6]: #archive-status
[7]: #import-results
[9]: #permissions
[10]: #how-to-import
[11]: #file-size-limitations
[12]: #submissions-archive-delete-orphaned-files-job
[13]: #errors-and-limitations
[14]: #about-compressed-file-imports-with-vault-file-manager
[15]: #duplicate-detection