# Configuration for Bulk Creating Activities, Submissions & Regulatory Objectives

Vault provides a Create Related Records wizard that enables users to create _Activity_, _Submission_, or _Regulatory Objective_ records in bulk. Bulk creation allows users to standardize and minimize much of the local affiliate data entry required for global change events.

This feature is automatically enabled for drug products on RIM Registrations Vaults. See details below about configuration needed to bulk create activities, submissions, and regulatory objectives for medical devices.

<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 Registrations Vaults.</p>
    </div>
  </div>
</div>



## Configuring Naming Patterns {#naming-patterns}

You can define the naming patterns for new _Regulatory Objective_ and _Submission_ records created in the wizard:

1. Navigate to **Admin > Settings > Application Settings**.
2. Select the **Set naming pattern for Regulatory Objective Name when using Create Related Records wizard** and **Set naming pattern for Submission Name when using Create Related Records wizard** checkboxes.
3. Define the naming patterns for each object in the fields below the checkboxes. You can enter static strings for any _Object_-, _Picklist_-, _Text_-, or _Formula_-type fields on the _Event_ object as tokens. To enforce uniqueness, your naming pattern should include a numerical token, for example, _{##}_. Record names should be unique and shouldn't exceed 128 characters or record creation could fail. We recommend creating a text field on the _Event_ object with a default formula to ensure that record names meet these requirements.
4. Click **Save**.
5. Vault validates your naming patterns and displays a warning if a pattern is not valid.

If [system-managed naming](/en/lr/30986/ ) is enabled on the _Regulatory Objective_ or _Submission_ objects, Vault names new records based on those patterns rather than the ones defined for the Create Related Records wizard.

## Configuring Default Activity Scope

You can select a default _Activity Scope Level_ for the Create Related Records wizard. Vault automatically selects this scope when users create activities in the wizard, but users can choose a different value. To set a default scope, navigate to **Admin > Settings > Application Settings** and select the **Define default Activity scope when using Create Related Records wizard** checkbox. Then, select the **Activity Scope** from the drop-down.

## Configuring Custom Fields

Vault can copy or default custom field values from _Event_ join records to the corresponding _Submission_ join records or _Regulatory Objective_ join records. Vault supports this functionality for the following field types: _Picklist_, _Object_, _Date_, _DateTime_, _Yes/No_, _Text_, and _Number_.

The method you use to configure this functionality depends on whether the configuration should copy a value from a field on the source record, or default a value from a formula on the target record. These differences are summarized in the table below.

| Goal | Field Name | Source Field<br>Permission | Target Field Permission |
|---|---|---|---|
| Copy | Source and target object field names must be the same, for example `field_name__c` and `field_name__c`. | Read | Edit |
| Default | Source and target object field names must be different, for example `ro_autoname_calc__c` and `sub_autoname_calc__c`. | None | None |

Additionally, this functionality requires that:
  * The fields you configure are also configured for any object types.
  * Selected _Regulatory Objective_ join object fields are not configured within lifecycle state entry criteria.
  * Auto-naming field names do not match across related join objeccts. Otherwise, Vault copies field values from the source record to the target record instead of applying the auto-name field's configured default value. For example, the fields labeled *Auto-name Calculation* across the below *Product* relationship objects are uniquely named as:
     * *Event Product*: `event_autoname_calculation__c`
     * *Submission Product*: `autoname_calculation_sub__c`
     * *Regulatory Objective Product*: `autoname_calculation_ro__c`

## Configuring Enhanced Change Management {#configuring-enhanced-change-management}

When your organization uses _Product Change_ records to track changes to a product as it relates to a specific _Event_, the Create Related Records wizard can push these _Event Change Items_ out to related _Activity_ records for impacted markets. Then, regulatory teams can track the resulting _Activity Change Items_ to their completion. A single _Product Change_ can be linked to multiple _Events_ and _Activities_, creating more flexibility to include:
  * Items from more than one change control within the same _Event_, for example annual reports that include items from multiple changes.
  * The same _Product Change_ for more than one _Event_, for example when going to market in regional waves.

To configure enhanced change management:

1. To all applicable _Event_ and _Activity_ object page layouts, add a "Product Changes" related object section, corresponding to the appropriate object types:
    * Event: _Event Change Item_
    * Activity: _Activity Change Item_
2. Create _Product Change_ records to capture individual product changes. A _Product Change_ is an object type of the _Change Item_ object.
3. Associate _Product Change_ records to one or more _Events_.

Additionally, the below business logic configuration components are included in your Vault to provide further flexibility in tracking change items to their completion:
  * _Change Item_ [object lifecycle](/en/lr/30683/) and [lifecycle stage group](/en/lr/52053/)
  * _Activity Change Item_ object lifecycle and lifecycle stage group
  * _Event Change Item_ object lifecycle



<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>: Once configured, this capability is automatically enabled for the <a href="/en/lr/50545/#about-enhanced-change-management-for-splitting">Splitting</a> wizard.</p>
    </div>
  </div>
</div>



## Enabling Application Relationships {#enabling-application-relationships}

Vault can reference _Application_ relationship records as the source of truth when creating records in bulk. This is useful, for example, for global _Events_: The wizard copies data from the _Event_ relationship records to the country-level records for _Applications_, _Regulatory Objectives_, and _Submissions_. For existing relationships, the wizard matches _Event_ data with _Application_ relationship records, then copies the _Application_ relationship to the _Regulatory Objective_ and _Submission_.

This feature is only available in RIM Vaults enabled with both the Registrations and Submissions applications. It is also controlled by a [one-way setting](/en/lr/53688/#regs-enable-app-relationships) which first requires an Admin to [configure and enable](/en/lr/78228/) the [Submission Wizard](/en/lr/73649/).

### Enabling Dynamic Validation {#dynamic-validation}

When _Application_ relationships are enabled and fully populated, a related [setting](/en/lr/53688/#regs-enable-dynamic-validation) allows the wizard to run additional validation checks based on existing _Event_ data. This ensures the local data needed to support change management can be propagated quickly and correctly.

Dynamic validation supports a variety of use cases, including:
  * Preventing _Shelf Life_ data from being pushed to _Regulatory Objectives_ or _Submissions_ that do not have the same related _Packaging_ records.
  * Adding a new _Packaging Site_ only where the related _Packaging_ records exist.
  * New product approvals where _Registrations_ do not yet exist.
  * Changes requiring new _Registrations_ to be created.
  * Adding a new investigational product, a frequent case including comparator and reference products, without requiring the relationship between the _Application_ and _Product Family_.

To enable dynamic validation:
  1. Ensure the _Update_ value in the _Event Change Action_ picklist is active.
  2. Create or update Event Change Types for the new _Related Change Type_ picklist options, for example the options for drug or device manufacturer changes (_Add Drug Product Manufacturer Details_, _Update Device Product Manufacturer Details_), or any of the options for updating records (_Update Product Details_).
  3. Navigate to **Admin > Settings > Application Settings** and select the **Enable dynamic validation for Create Related Records and Bundling** [setting](/en/lr/53688/#regs-enable-dynamic-validation).

### Enabling eCTD 4.0 Support {#enabling-ectd4-support}

Vault can propagate _Extended eCTD Keyword_ details from _Events_ to _Submissions_, _Regulatory Objectives_, and _Applications_ to support eCTD 4.0 submissions.

To support this required functionality for eCTD 4.0 markets in the Create Related Records wizard, you must:
1. Enable _Application_ relationships and fully populate all relationship records.
2. Update the _Event_, _Application_, _Submission_, and _Regulatory Objective_ object page layouts to include a related object section referencing the _Extended eCTD Keywords_ object.
3. Populate _Event Extended eCTD Keyword_ records mapping _Events_ to _Extended eCTD Keywords_. This information is captured across the _eCTD Components_, _eCTD Containers_, _eCTD Descriptors_, and _eCTD Facilities_ object types.

Once enabled, eCTD 4.0 support is also automatically extended to [Bundling and Splitting](/en/lr/50545/).

## About Object Type Mapping

Vault uses object type mapping to determine which object types to use for particular records depending on the object types of the _Event_ or _Applications_ the user selects in the bulk creation wizard. This is especially important for objectives and submissions with a combination of drug products and medical device products.

To do this, the wizard checks for active _Object Type Mapping_ records you've created and, based on that mapping data, selects the object types. If there are no active records, the wizard automatically selects the target object type by comparing the Names of the source and target object types (for example, `device_intended_use__v`). If the _Name_ values do not match, Vault prompts the user to select the target object type.

Vault supports name-based object type mapping for creating the following _Submission_ and _Regulatory Objective_ join object records:

  * _Active Substance_
  * _Authorization_
  * _Clinical Study_
  * _Inactive Ingredient_
  * _Indication_
  * _Nonclinical Study_
  * _Packaging_
  * _Packaging Characteristic_
  * _Product_
  * _Product Characteristic_
  * _Product Classification_
  * _Regulatory Text_
  * _Site Contact_
  * _Site Organization_
  * _Site Role_

### About the Object Type Mapping Object

The _Object Type Mapping_ object supports customers who want to manually create activities, submissions, or regulatory objectives in bulk for both drug products and medical device products.

See [Configuring Object Type Mapping for Registrations](/en/lr/62601/) for a sample set of mappings. This setup ensures that the correct details will be carried over when users bulk create activities, submission, or regulatory objectives for drug products or for medical device products. You may create similar mappings for custom source registration object types or custom object types on target registered detail objects.

You must add the _Applicable Product Type_ field to all _Application_ object types and populate this field for object type mappings to work.

## Configuring Global-to-Local Mapping {#configuring-global-to-local-mapping}

You can configure Vault to allow users to select global terms (such as those defined for the original _Application_) for certain object record fields in the wizard. When Vault creates the resulting records in bulk, it uses the appropriate _Constraint_ and _Controlled Vocabulary_ records to populate the corresponding local term. See also [Configuring Constraints](/en/lr/43081/) for more information.

### Submission Type & Submission Subtype

The **Enable Global to Local Submission Type Mapping** [setting](/en/lr/53688/#submission-type-mapping) and its sub-setting, **Enable Global to Local Submission Subtype Mapping** allow users to select a global term for the _Submission Type_ and _Submission Subtype_ fields in the wizard when creating _Submissions_.

When Vault finds a matching term for the selected field via the _Constraint_ and _Controlled Vocabulary_ records, it populates the local term in the resulting _Submission_ records. If Vault cannot locate a matching term or if it finds multiple matches, the selected fields are set to _Planned Submission_. This value corresponds to the _Controlled Vocabulary_ record for planned submissions (_Vault RIM UUID_ 8dc011b9-306b-4621-b513-4c75aba832ff).

See the use case in [Configuring Constraints](/en/lr/43081/#mapping-submission-type-and-subtype) for more information on [currently-supported](/en/lr/43081/#supported-constraint-scopes-and-appplication-object-type-combinations) _Constraint Scope_ and _Application_ object type combinations.

### Manufacturing Site Role

The **Enable Global to Local Manufacturing Site Role Mapping** [setting](/en/lr/53688/#manufacturing-site-role-mapping) allows users to select the global term for the _Manufacturing Site Role_ field in the wizard when creating _Submission_ and _Regulatory Objective_ records.

When Vault finds a matching term for the selected field via _Constraint_ and _Controlled Vocabulary_ records, it populates the local term in the resulting _Submission_ and _Regulatory Objective_ relationship records that specify _Manufacturing Site Role_, such as _Submission Product_ or _Regulatory Objective Packaging_.

If Vault cannot locate a matching term or if it finds multiple matches, the _Global Manufacturing Site Role_ value is copied from the _Event_ relationship record to the _Manufacturing Site Role_ field in the new _Submission_ and _Regulatory Objective_ relationship records.

See the use case in [Configuring Constraints](/en/lr/43081/#mapping-manufacturing-site-role) for more information.



<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 setting and related <em>Manufacturing Site Role</em> Constraints are supported for bulk record creation, as well as <a href="/en/lr/50545/">bundling and splitting</a>. They are not supported when <a href="/en/lr/77853/">dispatching</a> a <a href="/en/lr/77855/#manufacturing-site-role-note">global content plan</a>. We recommend using separate records for Content Planning/Publishing versus Registrations.</p>
    </div>
  </div>
</div>



## Configuring Related Record Review {#configuring-related-record-review}

The [Create Related Records wizard](/en/lr/31322/#reviewing-and-refining-related-records) includes additional functionality allowing users to preview the records Vault is proposing to create or update based on the _Event_ and other selected records. Vault displays them in the wizard, allowing users to navigate through each Lead Market's _Application_ and remove any related records which Vault should not create or update.

To configure related record preview in your Vault:

1. Within the _Event_ object, add the _Review Related Records_ and _Clear Preview_ actions. As of 25R3, we recommend labeling the _Review Related Records_ action as "Review Local Regulatory Information".
2. Within the _Event_ object lifecycle:
    * Create a new _In Data Review_ state.
    * Create a new _In Data Review_ state type, then map it to the _In Data Review_ state.
    * To the _In Data Review_ state, create to new user actions using the _Review Related Records_ and _Clear Preview_ actions. As of 25R3, we recommend labeling the _Review Related Records_ action as "Review Local Regulatory Information".
3. Review your Vault's security configuration. In addition to the minimum _Read_ and _Create_ permission to the objects they're reviewing, users must be assigned a permission set with _View_ and _Execute_ Object Action Permissions for the _Event_ object. In some newer Vaults, users assigned the _Change Management - Contributor_ permission set will have these permissions automatically via the _All Object Actions_ Object Action Permission.
4. Navigate to **Admin > Settings > Application Settings** and enable the **Enable Create Related Records Review** setting.

## Configuring Fields for Indications & Orphan Designations

Vault uses the _Full Indication Text_ object and its related objects to track the full text required for therapeutic indications, as documented in section 4.1 of the Summary of Product Characteristics (SmPC).

Additionally, Vault uses the _Regulatory Authorisation_ object to store data related to special authorisations, such as Orphan Designation or Advanced Therapy Medicinal Products (ATMPs).

If your organization requires this IDMP reporting data to be populated during bulk creation, add the _Full Indication Text_ and _Orphan Designation_ fields to the object page layouts of the following objects:
  * _Application Indication_
  * _Event Indication_
  * _Regulatory Objective Indication_
  * _Submission Indication_

## Configuration for Gouping Change Items

Grouping _Change Items_ assists RIM users in assessing and dispositioning single changes that involve many products and/or packaging types by grouping records by *Product Family* within the Create Related Records wizard. To enable this feature:
* Activate the *Change Item* object type within the *Change Item*, *Event Change Item*, *Activity Change Item* objects and ensure users are assigned Read, Create, and Edit permissions for these objects via assigned permission sets.
* Navigate to **Admin > Settings > Application Settings** and select the **Enable Grouping of Change Items by Product Family** [Application Setting](/en/lr/53688/#grouping-of-change-items).

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

In order for users to create records in bulk, you must ensure that their security profiles are configured correctly. Users need a permission set with:

* _Create_ permission on the objects they're creating, for example, _Submission_
* _Read_ permission on the source records from which they initiate the wizard, for example, _Event_, and the records from which the wizard pulls data, for example, _Event Active Substance_
* _View_ and _Execute_ object action permissions for the _Create Related Records_, _Review Related Records_ (_Review Local Regulatory Information_), and _Clear Preview_ actions on the _Event_ object.
* If the objects use Dynamic Access Control, users need at least the _Viewer_ role on the specific records
* If your Vault uses field-level security, users must have _Read_ permission on the fields from which Vault pulls data
