# Submission Wizard Administration (RIM)

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 <a href="/en/gr/450731/">Submissions Archive Viewer</a>
.

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.



<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>: This feature is available for all RIM Vaults. See <a href="/en/gr/53688/#rim-settings-enable-app-relationships">RIM Application Settings &amp; Configuration Options</a>
 for enablement details.</p>
    </div>
  </div>
</div>



## Configuration & Set-Up Overview

<div class="note-border alert-important">
  <div class="alert alert-important" role="alert">
    <div><i class="far fa-exclamation-circle"></i></div>
    <div class="alert-text">
      <p><strong>Important</strong>: Submission Wizard set-up includes enabling a one-way setting which cannot be disabled. You must complete all configuration and data setup <strong>before</strong> enablement.</p>
    </div>
  </div>
</div>



  1. Configure [_Application_ relationship object types][1] to align with equivalent [_Submission_ and _Regulatory Objective_][2] 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][3] for new _Application_ relationship objects, the _Application Source_ field, and the Submission Wizard action.
  4. [Migrate][5] _Application_ relationship record data using <a href="/en/gr/44812/">RIM Maintenance</a>
.
  5. Recommended: Review your Vault's _Submission_ object lifecycle configuration and remove any <a href="/en/gr/67245/">_Pull Objective Data_</a>
 user actions. When the _Enable Application Relationships_ setting is enabled, Vault does not use the _Application_ flow or set the [_Application Source_][8] 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 <a href="/en/gr/62601/">_Object Type Mapping_ records</a>
 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][4] the _Enable Application Relationships_ Vault settings.


##  Configuring the Application Relationship Objects {#configuring-app-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

<a href="/en/gr/42889/">Review your Vault's configuration</a>
 to determine which _Submission_ and _Regulatory Object_ relationship objects have custom (`__c`) object types, then <a href="/en/gr/32857/">create a corresponding object type</a>
 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 {#reviewing-configuring-fields}

<a href="/en/gr/42889/">Review your Vault's configuration</a>
 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, <a href="/en/gr/15057/#how_to_add_object_fields">create the corresponding fields</a>
 on the equivalent _Application_ relationship object and <a href="/en/gr/26387/">page layouts</a>
. You must also ensure these matching fields have [identical settings][7].

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 {#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:

  * <a href="/en/gr/15057/#required">Requiredness</a>

  * Criteria VQL for <a href="/en/gr/75340/">reference constraints</a>


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_.

<a href="/en/gr/42889/">Review your Vault's configuration</a>
 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 <a href="/en/gr/42778/">object field defaults</a>
 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][6]:

  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 {#configuring-submission-ro}


### Fields

<a href="/en/gr/42889/">Review your Vault's configuration</a>
  to determine whether any _Submission_ or _Regulatory Objective_ join object fields are configured to populate with <a href="/en/gr/42778/">default values</a>
. 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_][8] field, add it to <a href="/en/gr/26387/">page layouts</a>
 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**.
  4. Repeat for the **Submission** and **Regulatory Objective** objects and their object types.

You can control user access to the action through <a href="/en/gr/43127/#configuring-action-level-security">action level security</a>
.

## Configuring User Permissions {#configuring-user-permissions}

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

  * A <a href="/en/gr/22824/">permission set</a>
 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_ <a href="/en/gr/43127/#configuring-action-level-security">action level security</a>
 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][8].
  * The ability to _Edit_ relationships on the _Submission_ or _Regulatory Objective_ based on <a href="/en/gr/47850/#Atomic_Security_Relationships">Atomic Security for relationships</a>
. 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 {#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 <a href="/en/gr/44812/">RIM Maintenance</a>
 to extract and load _Application_ relationship records based upon existing _Submission_ relationships. Data migration can also be completed using <a href="/en/gr/26597/">Vault Loader</a>
.


### 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:

  * <a href="/en/gr/34072/">Lookup</a>
, <a href="/en/gr/15057/#formula-fields">formula</a>
, 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 {#enabling-the-wizard}

<div class="note-border alert-important">
  <div class="alert alert-important" role="alert">
    <div><i class="far fa-exclamation-circle"></i></div>
    <div class="alert-text">
      <p><strong>Important</strong>: All configurations and data setup must be complete <strong>before</strong> enabling the <em>Enable Application Relationships</em> setting. Failure to complete these steps prior to enablement may prevent users from creating <em>Submission</em> records.</p>
    </div>
  </div>
</div>



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. It is recommended that you enable this setting and disable it only as required for [data migrations][5].
  4. Select at least one submission lifecycle state in the <a href="/en/gr/53688/#exclude-submission-lifecycle-states">**Exclude Submission Lifecycle States**</a>
 picklist. The selected lifecycle states prevent 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.
  5. Review your organization’s business processes and decide whether to populate the <a href="/en/gr/53688/#exclude-regulatory-objective-lifecycle-states">**Exclude Regulatory Objective Lifecycle States**</a>
 picklist. The selected lifecycle states prevent Application relationship records from being updated or deleted when a _Regulatory Objective_ 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][8] for more information.


### About the Application Source Field {#about-the-application-source-field}

The _Application Source_ field within _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 triggers Vault to update the relationship record fields mapped to the indicated _Application Source_, maintaining data consistency across the object records.

The Submission Wizard’s _Exclude Submission Lifecycle States_ and _Exclude Regulatory Objective Lifecycle States_ subsettings apply additional layers of control. See <a href="/en/gr/73649/#managing-application-relationships">additional details</a>
 about how Vault behavior varies based on this and other configurations, such as the RIM Object Configuration _Editable Application Detail_ property for <a href="/en/gr/702685/#submissions-settings">RIM Object Configurations</a>
.


[1]: #configuring-app-relationship-objects
[2]: #configuring-submission-ro
[3]: #configuring-user-permissions
[4]: #enabling-the-wizard
[5]: #data-migration
[6]: #reviewing-configuring-fields
[7]: #field-settings
[8]: #about-the-application-source-field