# Managing Applications, Submissions, and Regulatory Objectives with the Submission Wizard (RIM) The Submission Wizard guides you through creating _Submissions_, _Regulatory Objectives_, and their relationships based upon the related _Application_.
## About the Submission Wizard Submissions and Regulatory Objectives are core RIM objects which drive the creation and management of _Registrations_, _Content Plans_, XML generation during publishing, and filtering in the [Submissions Archive Viewer](/en/lr/450731/). 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. The Submission Wizard guides you to relate the Regulatory Objective to any existing Registration records. When a Submission and Regulatory Objective impact existing Registrations, the Registrations must be linked to the Regulatory Objective record in order to run Manage Registered Details to update the Registrations. ## Using the Submission Wizard You can launch the Submission Wizard from an _Application_, _Submission_, or _Regulatory Objective_ record. You also have the option to create a _Submission_ or _Regulatory Objective_ within the wizard prior to selecting the relationships to add to these records. To manage relationships from an application, submission, or regulatory objective: 1. Navigate to an _Application_, _Submission_, or _Regulatory Objective_ record. 2. In the **Actions** menu, select **+ Submission Wizard**. Vault launches the wizard to the **Start** page. 3. Select or create a **Submission**. When you launch the wizard from a _Regulatory Objective_, this selection is optional. If you do not make a selection, the selected relationships are copied to the _Regulatory Objective_ only. 4. Optional: Select or create a **Regulatory Objective**. 5. When a _Regulatory Objective_ is selected and the _Application_ has at least one related active _Registration_, you have the option to relate _Registrations_ to the selected _Regulatory Objective_. 6. Select one or more **Relationships**. Vault displays all relationships to which you have [permission][1], and for which at least one record exists for that relationship on the current _Application_. 7. Click **Next**. 8. Begin to **Define Relationships** selected in the wizard by checking the box next to each record you wish to add to the _Submission_ and/or _Regulatory Objective_. Vault also pre-selects the records defined for the selected _Regulatory Objective_ records for you. You can filter on the column headings to identify the _Application_ relationships to add to your _Submission_ and _Regulatory Objective_. When complete, click Next. Repeat for each relationship page. When complete, click **Next**. Repeat for each relationship page. 9. Once you have defined all relationships, click **Save**. 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. ### About the Pharmaceutical Form Name for CH Submissions {#about-the-pharmaceutical-form-name-for-ch-submissions} When configured by an Admin, you can override the _Submission Pharmaceutical Form Name_ field value with its XML equivalent to accommodate scenarios where the module value is different from the XML envelope value. See [Working with CH Regulatory Submissions](/en/lr/59852/) for more information. To view the XML value overriding the _Submission Pharmaceutical Form Name_ in the wizard, add a column for the _XML Submission Pharmaceutical Form Name_ field. ## Managing Submission and Regulatory Objective Relationships ### 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][2] mapped to the indicated _Application Source_, maintaining data consistency across the object records. ### Copying Custom Fields Vault copies custom field values from _Application_ relationship records to the corresponding _Submission_ relationship records or _Regulatory Objective_ relationship records when custom fields with matching names and field types are configured on both objects. Vault supports copying custom fields for _Picklist_, _Object_, _Date_, _DateTime_, _Yes/No_, _Text_ (excluding Long Text and Rich Text), and _Number_ field types. ### Editing Submission and Regulatory Objective Relationship Record Fields {#editing-sub-and-ro-relationship-fields} Once the Enable Application Relationships admin setting is enabled, Vault updates _Submission_ and _Regulatory Objective_ relationship object fields to be system-managed. This restricted editability enforces data consistency by requiring any updates to be made to the _Application_ relationship, or by changing the _Application Source_ value to the record which contains the correct values. Then, Vault copies these values to the applicable _Submission_ or _Regulatory Objective_ relationship record. #### Sample Use Case Wonderdrug's RIM Vault contains the below records and metadata: For _Application Clinical Study:_ |Application Clinical Study Name|Application|Clinical Study|Clinical Study Type|Clinical Study Subtype| |--- |--- |--- |--- |--- | |CS-12345-01|EU Wonderdrug MAA|12345|Pharmacodynamics|Healthy Subject PD and PK/PD| |CS-12345-02|EU Wonderdrug MAA|12345|Safety|Patient PK and Initial Tolerability| For _Submission Clinical Study_: |Submission Clinical Study Name|Submission|Clinical Study|Clinical Study Type|Clinical Study Subtype|Application Source| |--- |--- |--- |--- |--- |--- | |12345|0010 - New indication|12345|Pharmacodynamics|Healthy Subject PD and PK/PD|CS-12345-01| A user sees that the _Submission Clinical Study_ record's _Clinical Study Type_ and _Subtype_ should be "Safety" and "Patient PK and Initial Tolerability", respectively. Since Wonderdrug's RIM Vault Admin has enabled the Submission Wizard and these fields are no longer directly editable, the user can leverage the Submission Wizard, or change the _Application Source_ field value to make the update. The user's permission set allows them to delete the _Submission Clinical Study_ record and, using the Submission Wizard, add the correct _Application_ relationship record to the submission. However, the user opts to update the _Submission Clinical Study_ record's _Application Source_ field value from "CS-12345-01" to "CS-12345-02". This results in the following metadata: |Submission Clinical Study Name|Submission|Application Source|Clinical Study|Clinical Study Type|Clinical Study Subtype| |--- |--- |--- |--- |--- |--- | |12345|0010 - New indication|CS-12345-02|12345|Safety|Patient PK and Initial Intolerability| As the submission has an existing Content Plan, the user also: * Re-creates the related study section within the Content Plan. * Updates the _Clinical Study Type_ and _Subtype_ fields for the Content Plan records in the new section using a bulk action. ## Managing Application Relationships {#managing-application-relationships} When the _Enable Application Relationships_, _Enable Relationship Triggers_, and the _Exclude Submission Lifecycle States_ [settings](/en/lr/53688/#rim-settings-enable-app-relationships) are enabled, the following Vault behavior applies to _Application_ relationship record creation and update: * Duplicate records within an _Application_ are not allowed, and only one unique relationship record can be created per Application. * _Application_ relationship records referenced as the _Application Source_ of a _Submission_ relationship record cannot be edited or deleted while the _Submission_ is in a lifecycle state configured within the _Exclude Submission Lifecycle States_ setting. When an _Application_ relationship record is _Superseded_ or _Withdrawn_, Veeva recommends inactivating the record and creating a new one with the updated details. * Vault copies changes made to an _Application_ relationship record to the _Submission_ and _Regulatory Objective_ relationship records which reference that record as the _Application Source_. This behavior applies only when the _Application_ record's related _Submission_ is not restricted by its lifecycle state as configured in the _Exclude Submission Lifecycle State_ setting. When loading new Application relationships in RIM Vaults, we recommend using the Loader in RIM Maintenance with the _Enable Relationship Trigger_ flag on. The relationships are created and the duplicates logged. Using the Vault Loader to create application joins is not recommended and does not fail the entire batch job when a duplicate is detected. The _Enable Relationship Trigger_ flag prevents duplicate relationships from being created. It is recommended this flag not be disabled. You can use the _Exclude Regulatory Objective Lifecycle States_ setting to enable increased flexibility to update Application relationship fields that may change throughout the life of an Application. The updated field values automatically cascade onto existing relationships on Submissions and Regulatory Objectives that are in non-excluded lifecycle states. Admins can determine the fields that remain editable and the Submission and Regulatory Objective lifecycle states to be excluded from the cascading updates functionality. ### Managing Application Relationships with RIM Object Configurations RIM Object Configurations is used to determine which Application relationship fields can be modified after dependent _Regulatory Objectives_ and _Submission_ relationships have already been submitted. When the _Exclude Regulatory Objective Lifecycle States_ [setting](/en/lr/53688/#exclude-regulatory-objective-lifecycle-states) is enabled and the _Editable Application Detail_ setting is configured in [RIM Object Configurations](/en/lr/702685/#submissions-settings), the following additional Vault behavior applies to _Application_ relationship record creation and update: * _Application_ relationship records referenced as the _Application Source_ of a _Submission_ relationship record cannot be deleted while the _Submission_ is in a lifecycle state configured within the _Exclude_ _Submission_ _Lifecycle States_ setting. * _Application_ relationship records referenced as the _Application Source_ of a _Regulatory Objective_ relationship record cannot be deleted while the _Regulatory Objective_ is in a lifecycle state configured within the _Exclude Regulatory Objective Lifecycle States_ setting. * _Application_ relationship fields that have Editable Application Detail set to "Yes" remain editable over time, even after the _Application_ relationship record is referenced as the _Application Source_ of a _Submission_ relationship on a _Submission_ that's in a lifecycle state configured within the _Exclude Submission Lifecycle States_ setting. * _Application_ relationship fields that have Editable Application Detail set to "Yes" remain editable over time, even after the _Application_ relationship record is referenced as the _Application Source_ of a _Regulatory Objective_ relationship on a _Regulatory Objective_ that's in a lifecycle state configured within the _Exclude Regulatory Objective Lifecycle States_ setting. * When an _Application_ relationship field with Editable Application Detail set to "Yes" is updated on an _Application_ relationship record, Vault copies these changes to the _Submission_ relationship records which reference that record as the _Application Source_. This behavior only applies to _Submissions_ that are not excluded by its lifecycle state as configured in the _Exclude Submission Lifecycle States_ setting. * When an _Application_ relationship field with Editable Application Detail set to "Yes" is updated on an _Application_ relationship record, Vault copies these changes to the _Regulatory Objective_ relationship records which reference that record as the _Application Source_. This behavior only applies to _Regulatory Objectives_ that are not excluded by its lifecycle state as configured in the _Exclude Regulatory Objectives Lifecycle States_ setting. * _Application_ relationship fields that have Editable Application Detail set to blank or "No" are not editable after the _Application_ relationship record is referenced as the _Application Source_ of a _Submission_ relationship on a _Submission_ that's in a lifecycle state configured within the _Exclude Submission Lifecycle States_ setting. * _Application_ relationship fields that have Editable Application Detail set to blank or "No" are not editable after the _Application_ relationship record is referenced as the _Application Source_ of a _Regulatory Objective_ relationship on a _Regulatory Objective_ that's in a lifecycle state configured within the _Exclude Regulatory Objective Lifecycle States_ setting. ## Related Permissions {#related-permissions} Generally, you must have a permission set with _Read_ permission on the _Application_ object and its relationships, in addition to the ability to _Create_ object records of the relevant _Submission_ object types. See [Submission Wizard Administration](/en/lr/78228/) for more information. [1]: #related-permissions [2]: #editing-sub-and-ro-relationship-fields