Submissions and Regulatory Objectives are core RIM objects which drive the creation and management of Registrations and Content Plans, XML generation during publishing, and filtering in the Submissions Archive Viewer.

A record’s scope is determined by the numerous Submission and Regulatory Objective relationship records containing metadata, such as Submission Clinical Study and Regulatory Objective Clinical Study. These relationship records are a subset of the Application relationship records (for example, Application Clinical Study), which collectively contain all Application metadata to be used in a related Submission or Regulatory Objective.

The Submission Wizard streamlines the process of defining the Submission and Regulatory Objective records and their relationships by allowing users to select from a controlled list of Application relationships, which Vault copies to the selected Submission or Regulatory Objective. This improves the data quality and data consistency of these records.

Configuration & Set-Up Overview

  1. Configure Application relationship object types to align with equivalent Submission and Regulatory Objective relationship object types. This may include creating new object types and updating object page layouts, in addition to defining fields and adding the Application Source field to the object types and their page layouts.
  2. Configure the Submission Wizard action on all Application, Submission, and Regulatory Objective relationship object types.
  3. Configure user permissions for new Application relationship objects, the Application Source field, and the Submission Wizard action.
  4. Migrate Application relationship record data using RIM Maintenance.
  5. Recommended: Review your Vault’s Submission object lifecycle configuration and remove any Pull Objective Data user actions. When the Enable Application Relationships setting is enabled, Vault does not use the Application flow or set the Application Source field when copying Submission relationships from Regulatory Objective relationships. As such, if users create Submission relationship records using the Pull Objective Data action, these fields will be blank.
  6. Review your Vault’s Object Type Mapping records and, where required, create records to map the Application object types to Submission object types. The wizard uses these records to default the Submission object type when creating submissions.
  7. Enable the Enable Application Relationships Vault settings.

Configuring the Application Relationship Objects

In order for Vault to maintain consistent data across all relationship object types, Application relationship object types must align with the equivalent Submission and Regulatory Objective relationship object types. For example, Application Product has object types Application Drug Product and Application Device Product, which correspond to the Submission Product object types Submission Drug Product and Submission Device Product.

Object Types

Review your Vault’s configuration to determine which Submission and Regulatory Object relationship objects have custom (__c) object types, then create a corresponding object type on the equivalent Application relationship object if one does not already exist.

For example, Submission Drug Packaging is an object type of Submission Packaging, and Regulatory Objective Drug Packaging is an object type of Regulatory Objective Packaging. To align the Application object configuration with these object types, you would create Application Drug Packaging, an object type of Application Packaging.

When configuring object type Names, ensure the values match across all object types. For example, the Application Drug Product object type Name drug_product__c matches both the Regulatory Objective Drug Product and Submission Drug Product object types with Name drug_product__c.

Custom Object Fields & Page Layouts

Reviewing & Configuring Fields

Review your Vault’s configuration to determine which Submission and Regulatory Object relationship object fields your organization wishes to populate on the equivalent Application relationship object. (When a custom field exists on both the Application relationship object and the Submission and/or Regulatory Objective relationship object with a matching name, the field is included in the validations and trigger logic for data consistency and data quality.) Then, create the corresponding fields on the equivalent Application relationship object and page layouts. You must also ensure these matching fields have identical settings.

When configuring object field Names, ensure the values match between the Submission or Regulatory Objective relationship object and the corresponding field in the Application relationship object. For example, the custom Submission Product relationship object field Product Code Type (product_code_type__c) matches the Application Product relationship object field Product Code Type (product_code_type__c).

Reviewing & Configuring Field Settings

The Submission Wizard also requires that fields matching between the Application,Submission, and Regulatory Objective relationship objects are configured identically with the following characteristics:

For example, within a Submission Product, the Manufacturer field is constrained by the related Product’s manufacturers on the Submission Product. This same Criteria VQL must be added to the equivalent Manufacturer field on the Regulatory Objective Product and Application Product.

Review your Vault’s configuration to determine whether Application relationship object field configurations require update to align with the corresponding Submission and Regulatory Objective relationship object field configurations.

Additionally, any object field defaults set on the Submission and Regulatory Objective relationship objects should be removed and replicated within the corresponding Application relationship object fields.

Configuring Object Page Layouts

In addition to adding custom fields to page layouts:

  1. Create a new section for each applicable Application relationship object (for example, Application Active Substance) for each Application object type (for example, Substance Application).
  2. Review and update the Application relationship object page layouts as needed.

Configuring the Submission & Regulatory Objective Objects

Fields

Review your Vault’s configuration to determine whether any Submission or Regulatory Objective join object fields are configured to populate with default values. If so, you must remove the default value configuration, as these are now set on the Application relationship objects and should not be separately defined.

Page Layouts

To ensure users are able to work with the Application Source field, add it to page layouts as follows:

  1. Within the Submission and Regulatory Objective objects, add Application Source as a column within all applicable Submission relationship sections.
  2. Add Application Source to all Submission and Regulatory Objective relationship objects.

Additionally, update the following object page layouts to add the indicated fields:

  • Regulatory Objective Clinical Study object: Add the Regulatory Objective Indication field
  • Regulatory Objective Inactive Ingredient object: Add the Regulatory Objective Product field

Configuring the Submission Wizard Action

To allow users to launch the wizard from the Application, Submission, and Regulatory Objective object records, you must enable the Submission Wizard object action on each object and their object types.

To do this:

  1. Navigate to Admin > Objects and select the Application object.
  2. Within the Actions tab, click the Submission Wizard action.
  3. Edit the action and change the Status to Active.
  4. Select the Object Types tab, then click the blue Actions link.
  5. Select Edit Object Type Actions.
  6. In the Submission Wizard Object Type Action row, check the box below each applicable object type. Click Save.
  7. Repeat for the Submission and Regulatory Objective objects and their object types.

You can control user access to the action through action level security.

Configuring User Permissions

In order for users to work with the Submission Wizard, ensure their security profiles are configured. Users need:

  • A permission set with Read permission on the Application object, in addition to all relevant Application relationship objects, for example Application Product.
  • A permission set with Create permission on all relevant object types on the equivalent Submission relationship, for example Submission Drug Product, an object type of Submission Product.
  • View and Execute action level security for the Submission Wizard object action.
  • The ability to View and Edit relevant fields within the Submission and Regulatory Objective relationship join records they will be working with in the wizard. One such field is the Application Source field.
  • The ability to Edit relationships on the Submission or Regulatory Objective based on Atomic Security for relationships. When each secured join object (for example, Submission Active Substance, Submission Pharmaceutical Product) is configured with Read as the default behavior in the desired lifecycle state (for example, Archived or Health Authority Received), the wizard does not create those relationship records and logs it in the failure file.

Data Migration

In order for users to select relationships in the wizard, Application relationship records should exist in the Vault. You can expedite this process by using RIM Maintenance to extract and load Application relationship records based upon existing Submission relationships. Data migration can also be completed using Vault Loader.

Extracting Application Relationships

When extracting, Vault generates a ZIP file containing one CSV file for each Application relationship, for example, Application Clinical Study. Each row represents the individual records, and each column contains the matching fields shared between Application and Submission, for example Clinical Study External ID.

To extract Application relationships:

  1. Navigate to the RIM Maintenance tab.
  2. In the left panel, click Extract.
  3. From the Action picklist, select Extract Application Relationships.
  4. Select the applicable radio button to extract All Applications, or Select Applications from the Applications picklist. You can extract up to 1,000 applications.
  5. Click Extract. Vault begins processing the request. When finished, you’ll receive a Vault notification and email with request details and a link to the output file.

Vault excludes the following from extracted files:

  • Lookup, formula, and inactive fields
  • Application Pharmaceutical Form and Application Indication records
  • Application Authorization records in non-Registrations RIM Vaults

Loading Application Relationships

You can use extracted files to work with the existing metadata, then load new and transformed records as zipped CSV files back into your Vault.

To load Application relationships:

  1. Navigate to the RIM Maintenance tab.
  2. In the left panel, click Load.
  3. From the Action picklist, select Load Application Relationships.
  4. For the File, click Choose to select the ZIP file containing the CSV file(s) you wish to load.
  5. Select a unique Key Field from the picklist.
  6. Click Load. Vault begins processing the request. When finished, you’ll receive a Vault notification and email with request details and a link to the output file.

Enabling the Submission Wizard

The Submission Wizard is controlled by a one-way Vault setting, which includes a two-way sub-setting to manage relationship record creation and update. It is recommended that you enable the sub-setting and disable it only as required for data migrations.

To enable the submission wizard:

  1. Navigate to Admin > Settings > Application Settings.
  2. Under RIM Settings, select Enable Application Relationships. Once you enable this feature, you cannot disable it.
  3. Recommended: Select Enable Relationship Triggers to enforce validation on Application, Regulatory Objective, and Submission relationships. This setting enforces validations and data syncing on record creation, update, and deletion.
  4. Select at least one submission lifecycle state in the Exclude Submission Lifecycle States picklist. The selected lifecycle states will block Application relationship records from being updated or deleted when a Submission in one of the configured lifecycle states has a join record sourced from the Application relationship record.

Once enabled, Vault converts most Submission and Regulatory Objective relationship record fields sourced from Application to system-managed fields. System-managed naming is enabled only in Vaults where the Values must be unique setting is enabled for the Name field.

When a field is system-managed, it can no longer be edited within the record and must be set with the Submission Wizard, or by using the Application Source field if configured. See About the Application Source Field for more information.

About the Application Source Field

The Application Source field within the Submission and Regulatory Objective relationship objects maps records to the Application relationship records from which they were created. When the Enable Application Relationships and Enable Relationship Triggers admin settings are enabled, any updates to the Application Source field will trigger Vault to update the relationship record fields mapped to the indicated Application Source, maintaining data consistency across the object records.

The recommended Enable Relationship Triggers setting and its related Submission lifecycle state sub-setting apply an additional layer of control. When enabled:

  • Vault prevents duplicate Application relationship records from being created.
  • Users are able to edit only the Application Source field and any unique fields which are not shared with the selected Application Source record.
  • Vault prevents Application relationship records from being edited or deleted when referenced within a Submission in a configured lifecycle state where records should not be edited or deleted, such as Archived.

Veeva recommends enabling these settings to continually enforce data validation and automatic updates, though you may choose to temporarily disable the setting during relationship record migration.