RIM Submissions Archive allows you to import final submission dossiers for your organization’s records and users’ later review.
Note: These features are only available on RIM Submissions Archive Vaults. Some of these features require an Admin’s configuration before you can use them.
Setting Up for Imports in Vault
Before you import submissions, you must set up your Vault to do this. 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 for detailed instructions and information about how Vault imports submissions.
Supported DTD & Schema Versions for Import
Vault supports the following eCTD DTDs and schemas at this time. Imports will fail for submissions that use an unsupported version.
- ICH 3.2, 3.0
- ICH-STF 2.2
- Australia (AU) 0.90, 3.0, 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
- 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
- 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)
- Thailand (TH) 0.92, 1.0
- Ukraine (UA) 1.0
- United States (US) 2.01, 3.3
- World Health Organization (WHO) 1.1
Note: Vault supports import for China non-eCTD, containing index.xml and index-sm3.txt.
Note: Eurasian Economic Union (EAEU) R.022 1.0 submissions require the Dossier Format to be set to EAEU with a RIM UUID value of de79963b-3c40-4256-8d1a-bb710c68a95b.
Note: 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.
Importing Submissions
You can import submission dossiers in several ways.
Note: For performance reasons, Vault does not populate the Submissions document field for any util files in eCTD submissions during import.
How to Import Submissions
To import a submission dossier:
- Navigate to the Submission record. You can also access submissions from their related Application records.
- From the Actions menu, select Import.
- 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. Depending on your Vault’s configuration, you can alternatively import these files from your Vault’s file stating server (FSS), or from Vault File Manager:
- To add larger dossiers via the FSS, choose whether to upload to the FTP root folder or FTP 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 FTP root folder, a user must have adequate 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. See also File Size Limitations.
- Click Next.
- 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.
- Optional: When enabled, you can also choose to manually map submission data to various Vault object records if you are importing an eCTD submission and the XML contains elements with attribute information. This option is not available when you import using Vault File Manager or the API.
- Vault populates select document fields automatically on import, creates or updates a related Dossier Details record, and updates the Submission Archive Status field on the Submission record throughout the import process. When the import is complete, you’ll receive an email and a Vault notification. Vault also adds the import results as an attachment on the Submission record if attachments are enabled on the Submission object.
In the Import Submission dialog, Vault hides the option to upload to the FTP root folder if there is no SubmissionsArchive folder in the Staging Server root. Vault hides the FTP user folders option if you don’t have File Staging: Access permission, or if there is no Submissions Archive Import folder within your Staging Sever folder.
On the File Staging Server, 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 FTP user folder.
How to Import Common Submissions in Bulk
From a list of Submission records, you can import a single dossier to multiple submissions using a bulk action. 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 Server 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 (API, Vault File Manager) do not provide a mapping page and therefore do not automatically import into the secondary Submissions.
How to Reimport Submissions
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:
- 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.
- From the Actions menu, select Reimport. Your Admin must grant you the correct permissions to see this action.
- Select an import option from the Import Submission dialog and complete the import.
- Vault removes the existing dossier and queues the new dossier for import. Once the import is complete, Vault will send you a notification and up-version the import results attachment file on the Submission record, if results vary from prior imports.
About Submissions Archive Documents
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.
Note: For performance reasons, Vault does not populate the Submissions document field for any util files in eCTD submissions during import.
About 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
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 as usual. If you reimport the submission dossier, Vault up-versions the existing attachment.
About Duplicate Content 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 for additional information about how Vault prevents duplicate documents.
About 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.
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 binder because of the submission import and removes any documents in the submission from the archive binder. This does not delete the documents from Vault, but the documents no longer appear in the Viewer tab, and users will not be able to access them using cross-document navigation. Vault also clears the Applications and Submissions document field values.
How to Remove 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
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
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.
Note: The Submissions Archive Delete Orphaned Files job is designed to remove imported documents. If your organization manually creates documents of the Submissions Archive (archive__v
) type, we do not recommend enabling the job. Vault will delete manually-created documents of this type, even if the Application and Submission fields are populated.
Job Instance Details
Vault skips the Delete Orphaned Files job and logs it as Missed Schedule in the history if there is an import or removal job running when the orphaned files job attempts to run.
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.
Errors & Limitations
File Size Limitations
Submission dossier files are subject to size limitations based upon import method:
- When importing via Vault user interface (UI), ZIP/TAR.GZ files must be under 4GB in size.
- Before a ZIP/TAR.GZ file is compressed, it must be under 10 GB in size and contain fewer than 20,000 files.
- When importing a ZIP/TAR.GZ file via Vault File Manager for Windows, it must be under 10 GB in size when uncompressed.
- For larger submission directories that are over 10GB in size or contain more than 20,000 files when uncompressed, you must use one of the following methods:
- Upload the uncompressed submission to your Vault’s file staging server, then import via Vault API or root import from the staging server.
- Import via Vault File Manager for Windows. An uncompressed submission must be under 100 GB in size and contain fewer than 100,000 files, per Vault File Manager for Windows limits.
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 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
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 Server 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 Staging Server.
Import Warning & Error Details
When you see the following warning, error, or informational messages after submission import, follow these actions to resolve issues:
Message |
Type |
Description |
Action |
STF {0} contains an empty reference and was skipped. |
Warning |
A Study Tagging File contains no leaf references. This may impact how the leaf displays within the Submissions Archive Viewer. |
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. |
An error occurred when importing the submission, document {0} id {1} from submission {2} is no longer available in Vault. Contact support for assistance. |
Error |
A document was deleted by a user or by Vault during an import. |
Reimport the submission's dossier. If the issue persists on subsequent imports, contact your Veeva representative for assistance. |
The dossier format import parameter is empty or null, {0}.{1} |
Error |
The fields referenced by the Dossier Format's import parameter do not contain a value. For example, the Dossier Format parameter references the application__v.folder_name__v field but the field is not populated. |
Populate the fields referenced in the notification and then reimport the dossier. |
Submission folder was not found, populate the submission {0} XML Submission ID field before proceeding with the import. |
Error |
No Submission folder is present within the ZIP/TAR.GZ package and the xml_submission_id__v field on the Submission record is not populated. Vault will attempt to use the value in the xml_submission_id__v field as the Submission folder when the ZIP file doesn't include a Submission folder and the Dossier Format is not defined on the Submission record. |
Reimport the submission after making one of the following corrections:
|
Submission folder was not found, the folder name {0} was used. |
Informational |
Vault applied the Dossier Format or the xml_submission_id value on the Submission record as the Submission folder because a Submission folder was not included in the imported submission package. |
Confirm that the Submission folder name appears as expected. No additional action is required. |
The uncompressed submission exceeds {0}GB, use Vault File Staging Server to import larger submissions. |
Error |
The uncompressed ZIP or TAR.GZ file exceeds the Vault limit for uncompressed packages. |
Uncompress the submission and import it via the File Staging Server or Vault File Manager. |
The uncompressed submission exceeds {0} documents, use Vault File Staging Server to import larger submissions. |
Error |
The uncompressed ZIP or TAR.GZ file exceeds the Vault limit for uncompressed packages. |
Uncompress the submission and import it via the File Staging Server or Vault File Manager. |
Document {0} exceeds the maximum number of object references in a field and cannot be updated. |
Informational |
Vault is unable to add more object references to one or more fields on the imported document. For example, the ich-ectd-3-2.dtd field already references the maximum number of Application records. |
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. |
Picklist value {0} ({1}) was not created properly in {2} ({3}). Remove and re-import the submission again. |
Error |
The Archive Section picklist value was not successfully created during the import process. |
Reimporting the submission should correct this behavior. If the issue persists on subsequent imports, contact your Veeva representative for assistance. |
[{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. |
Error |
The Submissions Archive Status field must be available on the Submission record prior to import. |
Add the Submissions Archive Status field to all Submission object types and reimport the submission. |
Application folder was not found, the folder name {0} was used. |
Informational |
Vault applied the Dossier Format value or the folder_name__v field value as the Application folder because the submission package did not include one. |
Confirm that the Application folder name appears as expected. No additional action is required. |
Application folder was not found, populate the application {0} folder name field before proceeding with the import. |
Error |
No Application folder is present within the ZIP or TAR.GZ package and the folder_name__v field on the Application record is not populated. Vault will attempt to use the value from the folder_name__v field as the Application folder when an Application folder is not included in the ZIP file and a Dossier Format is not defined on the Submission record. |
Reimport the submission after making one of the following corrections:
|
Unsupported {0} operation on leaf {1} – {2}. |
Warning |
During import, Vault was unable to locate the target of the lifecycle operation. This may occur if:
|
Vault corrects some of these occurrences automatically when the target submission is imported or when the Submissions Archive Harmonization jobs completes. If this doesn't correct automatically:
|
STF for study {0} references leaf id {1} that is not found in the submission. |
Warning |
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. |
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 Dossier Format parameter with the four-digit sequence ID. If the issue persists after reimport, contact your Veeva representative for assistance. |
{0} is invalid. Correct the XML and import the submission again. |
Error |
The Index or Regional XML is invalid against the DTD or XSD. |
|
The DTD or schema version is not currently supported. {0} |
Error |
The version specified in the Regional or Index XML is not currently supported for import. |
Contact your Veeva representative for information about when the version will be supported. 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. |
{0} was not found. Verify the XML file is in the correct Staging Server location. |
Error |
The index references a Regional XML that is not present within the specified location. |
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. |
The XML leaf checksum does not match the file's checksum: {Title: filename, ID:} |
Informational |
The checksum specified in the XML or index-md5.txt file does not match the calculated checksum of the document. |
If the warnings are unexpected, retrieve the submission from the source location and reimport it. If you imported via the File Staging Server, confirm that your FTP client was set to transfer as binary. If it was not, update the setting on your client, delete the submission from the Staging Server, reupload the submission to the Staging Server, and then reimport the submission. |
Submission folder name does not match the Submission record name |
Informational |
Vault detected an inconsistency between the Submission folder and the Submission record name. |
Confirm that the Submission folder name appears as expected. No additional action is required. |
Application folder name does not match the Application record name |
Informational |
Vault detected an inconsistency between the Application folder and the Application record name. |
Confirm that the Application folder name appears as expected. No additional action is required. |
The following eCTD leafs were not found. Vault created a placeholder to represent each missing leaf:{Title: filename, ID:} |
Informational |
Vault created placeholders for missing leaf documents. |
Confirm the result is as expected. If the result is not expected, confirm that all files exist within the location referenced in the XML. |
This submission folder has already been used for a previous import. |
Informational |
Another submission within the same application that uses the same import location is being processed. |
Confirm the duplicate import is intentional. |
Submission folder name does not match the dossier Submission identifier. |
Informational |
Folder name does not match the dossier identifier. |
Confirm the results are expected. If not expected, the submission may need to be reimported. |
Application folder name does not match the dossier Application identifier. |
Informational |
Folder name does not match the dossier identifier. |
Confirm the results are expected. If not expected, the submission may need to be reimported. |
Submission folder name does not match the Submission record sequence number. |
Informational |
Submission folder name does not match the Submission record sequence number. |
Confirm the results are expected. If not expected, the submission may need to be reimported. |
Zero (0) KB files found and omitted from import: {IDs} |
Warning |
Vault detected and omitted empty files during import. |
Verify the files are 0 KB. If they are not, contact your Veeva representative. |
The following XML files cannot be rendered. Contact support for further assistance. {list of leaf nodes} |
Warning |
Vault cannot render missing leafs. |
Confirm the result is as expected. If the result is not expected, confirm that all files exist within the imported archive. |
An error occurred when importing the submission. The document field {field name} on document type {document type} cannot be populated. |
Error |
Import cannot be completed with the required field on the document type. |
A required field must be removed from the document type for Vault to proceed with the import. |
Related 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 Server. |
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.