# Configuring Bundling & Splitting

Vault provides wizards that allow users to bundle multiple _Activity_ or _Regulatory Objective_ records into logical groups for future submission to Health Authorities. Users can also split bundled activities and regulatory objectives to create separate activities, submissions and regulatory objectives. These wizards ensure that related records are updated when bundling or splitting occurs, reducing the risk that users overlook update tasks and headquarters loses traceability.

The bundling wizards are particularly useful when an organization initiates changes at the headquarters level that affect country-level teams. The country-level teams can bundle multiple global activities along with local changes to reduce the overhead of multiple submissions.

When changes are bundled, it is possible that Health Authorities will reject some changes, or that pending labeling changes must be deferred and tracked separately from completed ones. The splitting wizard helps users to separate the unapproved or incomplete changes from the approved or completed changes, helping to ensure global traceability of their status.

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



## Prerequisites

Before starting configuration, you must:

  * Verify that the _Activity_ and _Regulatory Objective_ objects in your Vault use object lifecycles. If either does not, you will need to <a href="/en/gr/30683/ ">set one up</a>
. The lifecycle does not need to be complex; a simple two-state lifecycle is sufficient.
  * Set the **Enable Activity and Objective Bundling & Splitting** checkbox from the **Admin** > **Settings** > **Application Settings** page. Once you enable this setting, you cannot disable it. See [Settings][2] below and <a href="/en/gr/53688/">RIM Application Settings & Configuration Options</a>
 for information about additional bundling and splitting configurations.
  * Verify that your Vault uses the _Submission Regulatory Objective_ join object. If this is not already set up, you'll need to inactivate the _Regulatory Objective_ field (`regulatory_objective__rim`) on the _Submission_ object (`submission__v`). Then, update the _Submission_ object page layout to display the _Submission Regulatory Objective > Regulatory Objective_ join object and remove the _Regulatory Objective_ field (now inactive). You will also need to modify or recreate any reports in your Vault that rely on the _Regulatory Objective_ field.

## Configuration Overview

You must complete the following steps to fully configure this feature:

  1. Configure the **Bundle Activities** <a href="/en/gr/59885/#user-actions">user action</a>
 on one or more of the _Activity_ object lifecycle states. This allows users to initiate the bundling wizard. If needed, use <a href="/en/gr/47850/#Atomic_Security_Actions">Action Level Security</a>
 to control which users can access the action.
  2. Configure the **Start Splitting Process** <a href="/en/gr/59885/#user-actions">user action</a>
 on one or more of the _Activity_ object lifecycle states, for example the _In Progress_ state. This allows users to initiate the splitting wizard. If your organization plans to split only _Activities_ related to <a href="/en/gr/73795/">_Labeling Concepts_</a>
, you can configure the action conditionally, for when the _Activity_ object's _Labeling Impact_ field equals Yes. If needed, use <a href="/en/gr/47850/#Atomic_Security_Actions">Action Level Security</a>
 to control which users can access the action.
  3. Configure the **Bundle Regulatory Objectives** <a href="/en/gr/59885/#user-actions">user action</a>
 on one or more of the _Regulatory Objective_ object lifecycle states. This allows users to initiate the bundling wizard. If needed, use <a href="/en/gr/47850/#Atomic_Security_Actions">Action Level Security</a>
 to control which users can access the action.
  4. Configure the **Split Regulatory Objectives** <a href="/en/gr/59885/#user-actions">user action</a>
 on one or more of the _Regulatory Objective_ object lifecycle states. This allows users to initiate the splitting wizard. If needed, use <a href="/en/gr/47850/#Atomic_Security_Actions">Action Level Security</a>
 to control which users can access the action.
  5. Review the **Bundling/Splitting Results** (`rim_bundling_splitting_results__v`) notification from **Admin** > **Configuration** > **Object Messages**. This is the <a href="/en/gr/2157/ ">notification template</a>
 that Vault will use to notify users who initiate the wizard of the results of the bundling or splitting action. If editing, be sure not to modify the tokens included; these tokens allow notification recipients to access the results of the wizard actions.
  6. Add the _Reviewing Country_ and _Worksharing Tracking Number_ fields to the _Regulatory Objective_ <a href="/en/gr/26387/ ">object page layout</a>
.
  7. Optional: Enable <a href="/en/gr/30986/ ">system-managed object record naming</a>
 on the _Application Regulatory Objective_ object. Vault creates these records as part of the bundling and splitting processes. Vault also automatically creates _Application Regulatory Objective_ records when a user creates a new _Regulatory Objective_ record with the _Application_ field populated.
  8. Optional: Configure [Object Type Mapping][8] to allow users to bundle activities or regulatory objectives for both drug products and medical device products.
  9. Optional: [Enable Application relationships][9] to reference _Application_ relationship records when bundling.
  10. Optional: Enable *Change Item* grouping. This assists RIM users in assessing and dispositioning single changes that involve many products and/or packaging types by grouping records by *Product Family* when splitting _Activities_ and _Regulatory Objectives_. 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** <a href="/en/gr/53688/#grouping-of-change-items">Application Setting</a>
.

## About Object Type Mapping {#object-type-mapping}

Vault uses object type mapping to determine which object types to use for _Submission_ or _Regulatory Objective_ join records depending on the object type of _Application_ related to the source record. This is especially important for objectives and submissions with a combination of drug product, medical device product, and packaging details. It is also important for Unique Device Identification (UDI) and shelf life details, which have multiple object record types that can be included on the same submission or regulatory objective, such as _Device Description_ and _Device Intended Use_, which are both _Submission Regulatory Text_ object types.

You can download a <a class="download-link " href="https://platform.veevavault.help/assets/downloads/RIM-Object-Type-Mapping-20R3.xlsx" target="_blank" rel="noopener">sample set of mappings<i class="fa fa-download" aria-hidden="true"></i></a> for drug and medical device object types. This setup ensures that the correct details will be carried over to _Submission_ and _Regulatory Objective_ join records for drug products or for medical device products. You may create similar mappings for custom source _Application_ object types or custom object types on target _Submission_ and _Regulatory Objective_ join objects.

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_
  * _Shelf Life Storage_
  * _Site Contact_
  * _Site Organization_
  * _Site Role_

### About the Object Type Mapping Object

The _Object Type Mapping_ object supports customers who want to manually bundle activities or regulatory objectives for both drug products and medical device products.

See <a href="/en/gr/62601/">Configuring Object Type Mapping for Registrations</a>
 for a sample set of mappings. This setup ensures that the correct details will be carried over to _Submission_ and _Regulatory Objective_ join records for drug products or for medical device products. You may create similar mappings for custom source _Application_ object types or custom object types on target _Submission_ and _Regulatory Objective_ join objects.

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

## About Enhanced Change Management for Splitting {#about-enhanced-change-management-for-splitting}

Enhanced change management provides the ability to track product changes at a more granular level than an _Activity_ using _Change Items_, and the ability to split _Activity Change Items_ helps regulatory teams manage changes at a level that makes sense from a regulatory perspective. For example, managing a change control where Quality has grouped many changes together which may fall under different regulatory submission categories.

This capability is automatically available when enhanced change management is configured for the <a href="/en/gr/59835/#configuring-enhanced-change-management">Create Related Records</a>
 wizard.

## Settings {#settings}

When you select the **Enable Activity and Objective Bundling** setting in **Admin** > **Settings** > **Application Settings**, additional configuration settings related to bundling become available. See details about these settings below.

The **Enable Application Relationships** RIM Setting on this page is also available for use in Registrations Vaults. See details about [configuring the supporting feature for Submissions][9].

### Restrict Bundling by State

Two settings allow you to restrict the _Activity_ and _Regulatory Objective_ records that are eligible for bundling based on their lifecycle state:

  * **Restrict Activity bundling by state**
  * **Restrict Regulatory Objective bundling by state**

If you do not enable these settings, Vault will allow users to select activities or regulatory objectives in any lifecycle state.

#### How to Set State Restrictions

To set a lifecycle state-based restriction:

  1. From **Admin** > **Settings** > **Application Settings**, click **Edit**.
  2. Enable the **Restrict Activity bundling by state** and/or **Restrict Regulatory Objective bundling by state** settings.
  3. For each setting, select various **Lifecycle States**. Users will be unable to bundle activities or regulatory objectives that are in unselected states.
  4. Click **Save**.

### Submission Copying for EU Worksharing

EU worksharing and EU grouping allow users to avoid duplicating work. If users choose to copy submissions for this purpose, Vault creates _Related Submission_ records using the _Worksharing Group_ object type. The **Restrict Submission copying for worksharing** setting allows you to restrict the types of submissions that users can copy for worksharing.

#### How to Restrict Copying for EU Worksharing

To restrict the submissions that users may copy for EU worksharing:

  1. From **Admin** > **Settings** > **Application Settings**, click **Edit**.
  2. Select the **Restrict Submission copying for worksharing** checkbox.
  3. In the **Submission Types** field, choose _Controlled Vocabulary_ items. Only items where the _Controlled Vocabulary_ type is _Submission_ will appear in this list. When users choose to copy for EU worksharing, they will only be allowed to copy items with the selected type.
  4. Click **Save**.

### Submission Copying for US Grouping

US grouping allows users to avoid duplicating work by applying the same submission to multiple applications, for example, if promotional material applies to a family of products where each has a unique application but not unique promotional materials. If users choose to copy submissions for this purpose, Vault creates _Related Submission_ records using the _US Grouping_ object type. The **Restrict Submission record creation for US grouping** setting allows you to restrict the types of submissions that users can copy for grouping.

#### How to Restrict Copying for US Grouping

To restrict the submissions that users may copy for US grouping:

  1. From **Admin** > **Settings** > **Application Settings**, click **Edit**.
  2. Select the **Restrict Submission record creation for US grouping** checkbox.
  3. In the **Submission Types** field, choose one or more _Controlled Vocabulary_ items. Only items where the _Controlled Vocabulary_ type is _Submission_ will appear in this list. When users choose to copy for US grouping, they will only be allowed to copy items with the selected types.
  4. Click **Save**.

### Marking Records as Inactive

You can configure your Vault to allow users to move unused _Submission_, _Regulatory Objectives_, or _Activity Labeling Concept_ records into an inactive lifecycle state during the bundling or splitting process. This optional configuration helps your organization keep data clean and organized. If set up, this setting moves the records into the configured lifecycle state. The option is available for any records that are associated with the target record, but users must identify individual records to inactivate.

#### How to Configure for Marking Records Inactive

To set up the Vault's bundling wizard to allow users to make records inactive:

  1. From **Admin** > **Settings** > **Application Settings**, click **Edit**.
  2. Enable the desired object setting(s):
      * **Mark submissions as inactive during bundling**
      * **Mark regulatory objectives as inactive during bundling**
      * **Mark Activity Labeling Concepts as inactive during bundling**
  3. For each setting, choose one (1) or more **Starting States**. Users will only be able to inactivate records in the selected lifecycle states.
  4. For each setting, choose a lifecycle state as the **Target State**. To make the records inactive, the state you select must be <a href="/en/gr/30683/ ">configured as inactive</a>
.
  5. Click **Save**.

### Setting Default Filters for Activities & Regulatory Objectives

By configuring default filters, you can provide users with a shorter and better list of activities and regulatory objectives when it comes time for them to select these. Because users are able to remove and change the filters themselves, you can set default filters that will work for 80% of situations, and users will still be able to set their own filters for the other 20%.

Vault provides settings to filter both submissions and regulatory objectives:

  * **Default filters for Regulatory Objectives**
  * **Default filters for Activities**

#### How to Set Default Filters

To set default filters:

  1. From **Admin** > **Settings** > **Application Settings**, click **Edit**.
  2. Select the **Default filters for Regulatory Objectives** or **Default filters for Activities** checkbox.
  3. For Activity filters, select one (1) or more **Activity Fields** as filters.
  4. For Regulatory Objective filters, select one (1) or more **Regulatory Objective Fields** as filters.
  5. Click **Save**.

### Setting Naming Patterns

Setting a naming pattern for regulatory objectives and activities allows you to define how Vault names new records created during the bundling and splitting process. From **Admin > Settings > Application Settings**, select the **Regulatory Objective Naming Pattern** and/or **Activity Naming Pattern** checkboxes and enter a naming pattern.

When you enable the setting and define a pattern, the name appearing in the wizard cannot be edited by users.

If you do not enable the setting and define a pattern, Vault populates the _Name_ field according to its field configuration:
  * If the field is configured to be <a href="/en/gr/30986/">system-managed</a>
, Vault populates the _Name_ based on that configuration.
  * If the field is not configured to be system-managed, Vault applies the <a href="/en/gr/53688/#enable-bundling-splitting">default pattern</a>
 (`{application__rimr.name__v} - Bundle` for Regulatory Objectives, and `{impacted_market__rimr.country_code__rim}-{related_application__rimr.name__v} - Split` for Activities), and users are able to edit the _Name_ field once the record is created as an output of the wizard.

### Relating Regulatory Objectives & Submissions to Events

When users bundle or split a _Regulatory Objective_ or _Submission_, this setting allows Vault to relate the resulting records to the _Event_ for any _Activity_ selected in the wizard.

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

Vault can reference _Application_ relationship records as the source of truth when bundling _Activities_ and _Regulatory Objectives_. This is useful, for example, when using the bundling wizard to create _Activity_ groupings against a new or existing _Regulatory Objective_ or _Submission_, or to consolidate multiple _Regulatory Objectives_ into one.

This feature is only available in RIM Vaults enabled with both the Registrations and Submissions applications. It is also controlled by a <a href="/en/gr/53688/#regs-enable-app-relationships">one-way RIM Setting</a>
 which first requires an Admin to <a href="/en/gr/78228/">configure and enable</a>
 the <a href="/en/gr/73649/">Submission Wizard</a>
.

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

When copying _Event_ details to _Regulatory Objectives_ and/or _Submissions_ during bundling, Vault can validate them against relevant _Application_ data based on their _Related Change Type_. This behavior requires _Application_ relationships and its related dynamic validation <a href="/en/gr/53688/#regs-enable-dynamic-validation">setting</a>
 to be enabled.

This setting's use cases include:
* When bundling _Activities_, the corresponding local _Regulatory Objective_ and _Submission_ may not yet exist. If this is the first time copying _Event_ details to a local context, validation ensures the details make sense for that _Application_.
* Bundling Regulatory Objectives may also group _Activities_ together against a _Regulatory Objective_ that did not originate from the same _Event_. This leads to further propagation of _Event_ relationships to local records that have not yet been validated against the related _Application_ data.
* When bundling _Regulatory Objectives_ across _Applications_ to support worksharing or grouping, the existing _Regulatory Objective_ and _Submission_ relationships may have an _Application Source_ that is not on the primary _Application_.

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

Once <a href="/en/gr/59835/#enabling-ectd4-support">enabled</a>
 for the Create Related Records wizard, eCTD 4.0 support is automatically extended to bundling and splitting.

 [2]: #settings
 [8]: #object-type-mapping
 [9]: #enabling-application-relationships
