# Pulling Regulatory Objective Data to Submissions (RIM)

Regulatory objectives sometimes require multiple submissions to get approved, often with similar or identical details. To reduce data entry, Vault allows users to enter all required details on a _Regulatory Objective_ record, and then copy the related records from the _Regulatory Objective_ record to a _Submission_ record.

<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 only available on RIM application Vaults and requires an Admin to configure it.</p>
    </div>
  </div>
</div>



## How to Pull Regulatory Objective Data to Submissions

To pull _Regulatory Objective_ details to _Submission_ join records:

  1. Ensure all relevant details are entered on the _Regulatory Objective_ record.
  2. Open the _Submission_ object record detail page and expand the _Regulatory Objective_ section.
  3. Click **Add** and select the _Regulatory Objective_ record in the dialog to relate it to the _Submission_.
  4. Click **OK** to return to the _Submission_ object record detail page.
  5. Open the _Submission_ record's **Actions** menu and select **Pull Objective Data**.
  6. Vault creates the new _Submission_ join records asynchronously from the related _Regulatory Objective_. When record creation is complete, you'll receive a notification from Vault with details about record creation.

You must wait for Vault to complete record creation on one _Submission_ before you can pull _Regulatory Objective_ details to another _Submission_ record.

## Supported Objects {#supported-objects}

When you pull _Regulatory Objective_ details to a _Submission_ record, Vault can create records for the _Submission_ join objects below. Vault determines the object types for the created records and populates key fields with values from the _Regulatory Objective_ join records based on your Admin's configuration.

| Regulatory Objective Join | Submission Join |
|-|-|
| Regulatory Objective Active Substance | Submission Active Substance |
| Regulatory Objective Clinical Study | Submission Clinical Study |
| Regulatory Objective Inactive Ingredient | Submission Inactive Ingredient |
| Regulatory Objective Indication | Submission Indication |
| Regulatory Objective Nonclinical Study | Submission Nonclinical Study |
| Regulatory Objective Packaging | Submission Packaging |
| Reg Objective Packaging Characteristic | Submission Packaging Characteristic |
| Regulatory Objective Product | Submission Product |
| Reg Objective Product Characteristic | Submission Product Characteristic |
| Reg Objective Product Classification | Submission Product Classification |
| Regulatory Objective Shelf Life and Storage | Submission Shelf Life and Storage |
| Regulatory Objective Site Contact | Submission Site Contact |
| Regulatory Objective Site Organization | Submission Site Organization |
| Regulatory Objective Site Role | Submission Site Role |

### Use Case: Submission Packaging for Medical Devices

When creating a _Submission Packaging_ record from a _Regulatory Objective Packaging_ record for a medical device, Vault would populate the following fields:

  * _DI Contained Within_
  * _Finished Product Code_
  * _Finished Product Manufacturer_
  * _Packaging_
  * _Packaging Site_
  * _Packaging UDI-DI_
  * _Product_
  * _Product Variant_
  * _Shelf Life_
  * _Site Role_
  * _Site Product Type_
  * _Submission_
  * Any additional custom fields configured by your Admin on both objects

## Related Permissions

The _Pull Objective Data_ action requires that your security profile grant _Create_ permission on the objects you're creating, for example, _Submission Product_. Vault checks for the required permissions during the asynchronous record creation phase of the process. You may be able to view the action even if it is not available to you. Any <a href="/en/gr/39108/">field-level security</a> your Admin has configured on these objects may impact record creation as well.

You must also have _Read_ permission on the source _Submission_ record from which you initiate the wizard and the records from which the wizard pulls data, for example, _Regulatory Objective Product_. If the objects use Dynamic Access Control, you must have at least the _Viewer_ role on the specific records. If your Vault uses field-level security, you must have _Read_ permission on the fields from which Vault pulls data.