**Source URL:** https://regulatoryone.veevavault.help/en/lr/75233/index.md # Configuring Split Registration Items (Registration & Dossier Management) [ Registration & Dossier Management](/en/lr/71498/) allows users to generate new _Registration Items_ based on the attributes of a single _Registration Item_ by "[splitting](/en/lr/75235/)" a source _Registration Item_ into multiple related _Registration Items_. This allows your organization to create and manage granular registration items that may have to be assessed in different ways. For example, if your organization needs to register a holiday kit composed of four (4) _Products_, you can configure a _Split Rule_ that allows users to "split" the holiday kit _Registration Item_ by _Product_. When users select that _Split Rule_ on a _Registration Item_ record and run the _Split Registration Items_ action, Vault creates four (4) new related _Registration Items_, one (1) for each _Product_ in the holiday kit. The _Split Registration Items_ action lets users generate new _Registration Items_ based on _Split Rules_, which utilize [Relational Tokens](/en/lr/71507/) to determine how to create and relate the new records, including the option to maintain a recursive hierarchical structure. You can also specify which fields on generated records inherit values from the source record and define which fields Vault populates based on Object Mappings linked to the Relational Token. You can also configure the _Registration Item_ object to display a hierarchical structure of the composition of each _Registration Item_ and its related split records. This allows users to easily assess and register a product and its components for registration.
## Configuration Overview {#overview} Configuring your Vault to split _Registration Items_ involves the following steps: 1. Optional: [Define Object Mappings with Field Mappings][1] to specify how certain fields on generated _Registration Items_ are populated based on how the applicable Relational Token resolves 2. [Define applicable Relational Tokens][2] that determine how Vault creates and relates new _Registration Items_ 3. [Create _Split Rules_][3] that users can select to specify how to split a source _Registration Item_ 4. [Configure the _Registration Item_ object][4] 5. Optional: Configure the [Registration Item Viewer][7] on the _Registration Item_ object so users can see the hierarchical structure of split records 6. [Configure actions on the _Registration Item_ object][5] 7. [Configure user permissions][6]
## Defining Object Mappings & Field Mappings {#mappings} You can map object field values between a source object and the target _Registration Item_ object so that fields on generated _Registration Items_ are populated based on how the [Relational Token][2] specified in the [_Split Rule_][3] resolves. For example, you can create an Object Mapping with a Field Mapping to populate the _Product_ field on generated _Registration Items_ based on the _ID_ field on the _Product_ object referenced in the Relational Token. The _Source Object_ you define for the Object Mapping must be the same _Object_ defined in the Relational Token you add to the _Split Rule_. When creating an Object Mapping to use in a _Split Rule_, we recommend as a best practice that you map a unique field from the _Source Object_, such as the _ID_ field, to a corresponding field on the _Registration Item_ (_Target Object_). This will help users understand which records Vault creates when they run the _Split Registration Items_ action. Do not map the _Name_ field if it is a [system-managed](/en/lr/30986/) field on the _Registration_ object. See [Defining Object Mappings & Field Mappings](/en/lr/74401/) for more details. ## Defining Relational Tokens {#relational-tokens} _Split Rules_ rely on Relational Tokens to determine how to create and relate new _Registration Items_. You must first [define the appropriate Relational Tokens](/en/lr/71507/) before you can create _Split Rules_. Vault creates new _Registration Item_ records based on how the Relational Token referenced in a _Split Rule_ resolves. For example, you can create a Relational Token that resolves based on the _Products_ related to the source _Registration Item_, which would create and relate new _Registration Items_ for each related _Product_. Vault creates and relates records even when the Relational Token references objects for which users do not have _Read_ permission. If you link a _Split Rule_ with an _Output Structure_ of _Hierarchy_ to a [recursive Relational Token](/en/lr/71507/#recursive), the _Split Registration Items_ action creates and relates new _Registration Items_ to mirror the same hierarchy of the records queried by the Relational Token. For example, if a gift set contains a travel kit and the travel kit includes a lotion, users can generate hierarchical _Registration Items_ for the gift set. In that scenario, the travel kit _Registration Item_ is a child of the gift set _Registration Item_, and the lotion _Registration Item_ is a child of the travel kit _Registration Item_. ## Creating Split Rules {#create} _Split Rules_ determine how Vault creates and relates new _Registration Items_ based on the attributes of a source _Registration Item_ when users run the _Split Registration Items_ action. For example, splitting by _Product_. To create a new _Split Rule_: 1. Navigate to **Business Admin > Objects > Split Rules**. 2. Click **Create**. 3. Enter a **Rule Name**. Ensure you describe the rule appropriately because this is the name users see for selection when selecting a _Split Rule_. 4. Optional: Enter **Fields to Inherit**. You must enter the exact _Name_ of the field on the _Registration Item_ object, such as `product__v`. You can include up to 40 field _Names_, each separated by a comma. When users run the _Split Registration Items_ action, Vault populates these fields on all new _Registration Items_ with the same values on the source _Registration Item_ record. * If you want the generated _Registration Items_ to be the same object type as the source record, include `object_type__v` as a **Field to Inherit**. * If any of the **Fields to Inherit** you include are configured with [dynamic reference constraints](/en/lr/75340/) that reference other _Registration Item_ fields, you must also include the referenced _Registration Item_ fields as **Fields to Inherit**. 5. Enter the _Name_ of an active [**Relational Token**][2] to define how Vault generates new _Registration Items_ from the source _Registration Item_. 6. Select the **Output Structure**. If you choose **Hierarchy** and also enter a [recursive Relational Token](/en/lr/71507/#recursive), the parent-child relationships of the _Registration Item_ are replicated on the new records Vault creates as the Relational Token resolves. If the underlying data is non-recursive or you do not select a recursive Relational Token, Vault will generate a flat output even if you select **Hierarchy** for this field. 7. Click **Save**.
## Configuring the Registration Item Object {#page-layout} You must configure the following components on the _Registration Item_ object for all object types: * Ensure that the _Name_ field is [system-managed](/en/lr/30986/) * Add the _Split Rule_ field and a related object section to the [object layout](/en/lr/26387/) * Optional: Add the _Split Source_ and _Split Parent_ fields to the object layout so that users can see the source and parent on generated records * [Assign the following fields to all object types](/en/lr/32857/): * _Depth in Split Hierarchy_ * _Depth in Split Parent Hierarchy_ * _Split Job Status_ * _Split Parent_ * _Split Rule_ * _Split Source_
### Configuring the Registration Item Viewer {#viewer} You can insert the _Registration Item Viewer_ control section to the _Registration Item_ object layout so that users see the viewer on a _Registration Item_ record's detail page and view all _Registration Items_ related to the source _Registration Item_ as well as their children via the self-referencing _Split Parent_ field. To insert the viewer: 1. Navigate to **Admin > Configuration > Objects > Registration Item > Layouts > [Layout]**. 2. Insert the **Registration Item Viewer** control section with the slider (Slider Icon) icon. 3. Optional: Enter a **Section Label**. 4. Optional: In the **Show the section only in these lifecycle states** field, select one (1) or more lifecycle states. This option only appears if the object uses a [lifecycle](/en/lr/29798/). 5. Optional: Enter **Section Help** that users will see in this section. 6. Optional: Select the **Expand the section by default** checkbox so that the section is always open when users open _Registration Item_ object records. 7. Optional: Select the **Shade hierarchical levels** checkbox to help distinguish the hierarchical composition of the _Registration Item_ object records. 8. Optional: Select the **Highlight row on hover** checkbox to highlight the row that users hover on. 9. Optional: For **Grid Columns**, select up to 24 _Registration Item_ [supported fields][8] to display in the viewer. If you don't add any fields, the viewer will only display the _Name_ field. Drag and drop the fields to determine the order columns are displayed to users. 10. Click **Done**. 11. Click **Save** when you are finished updating the _Registration Item_ layout. #### Supported Fields {#supported-fields} Vault supports the following object field types in the _Grid Columns_ field: * Date * ID * Lifecycle State * Name * Number * Object (excluding references to the _Document_ object) * Object Type * Picklist * Text * Yes/No * Lookup (so long as the type is a supported type listed above) * Formula (so long as the return type is Date, Number, Text, or Yes/No field) The Registration Item Viewer always includes the _Name_ field as the first column in the grid, so you cannot add it to the _Grid Columns_ field. ## Configuring Registration Item Object Actions {#action-config} You must configure actions on the _Registration Item_ object in order for users to generate and deep delete _Registration Items_. If you have configured object types on the _Registration Item_ object, ensure that you assign the actions to all object types.
### Configuring the Split Registration Items Action {#split-action}
The _Split Registration Items_ action allows users to generate new _Registration Items_. When users run the _Split Registration Items_ action, Vault creates and relates new _Registration Items_ based on the _Split Rule_ they select and does the following: * Populates the _Split Source_ field on all new _Registration Items_ to reflect the parent-child relationship to the source record. * Populates the _Split Parent_ field on all new _Registration Items_ to reflect the relationship in the split hierarchy. When the _Output Structure_ of the _Split Rule_ is _Flat_, the _Split Parent_ field value is the same as the _Split Source_ field. * Populates the _Depth In Split Hierarchy_ and _Depth In Split Parent Hierarchy_ fields on the source record and all new records to indicate each record's place in the split hierarchy. * Populates any fields on new _Registration Items_ that are configured to inherit values from the source record. * Populates any fields on new _Registration Items_ based on Relational Token resolution (and the Object Mapping linked to the Relational Token). * If a parent _Registration Item_ record is filtered out of the generated split hierarchy, such as from [post-recursion VQL criteria](/en/lr/71507/#recursive), Vault re-parents any child record to the next closest ancestor record in the hierarchy. * Updates the _Split Job Status_ field to the current status of the job. * Removes any duplicate sibling _Registration Items_. Depending on your business needs, you can: * Add this action as an [entry action](/en/lr/59885/#entry-actions) on any _Registration Item_ lifecycle state * Add this action as a [user action](/en/lr/59885/#user-actions) on any _Registration Item_ lifecycle state * Add this action as a [record action](/en/lr/43127/#assign-actions) on the _Registration Item_ object ### Configuring the Deep Delete Split Registration Items Action {#deep-delete} The _Deep Delete Split Registration Items_ action allows users to delete a _Registration Item_ and all related child records and their descendant records. Descendant records are identified by way of _Split Parent_ hierarchy values. Depending on your business needs, you can: * Add this action as a [user action](/en/lr/59885/#user-actions) on any _Registration Item_ lifecycle state * Add this action as a [record action](/en/lr/43127/#assign-actions) on the _Registration Item_ object Users cannot delete _Registration Items_ with related child records if you select the _Prevent deletion of the related object record checkbox_ on the _Registration Item_ object. ## Configuring User Permissions {#user-permissions} You must ensure users have the appropriate read and create [permissions](/en/lr/22824/) to access the appropriate objects and object fields in addition to the permissions outlined below: * For the _Registration Item_ object: * _Edit_ permission, including _Edit_ permission on the _Split Rule_, _Split Parent_, and _Split Job Status_ fields. * _Read_ permission on any fields you added to the _Grid Columns_ field in the [_Registration Item Viewer_ section][7]. Users can only see values of fields for which they have _Read_ permission. * To delete _Registraton Items_: _Delete_ permission on all object types. If [DAC](/en/lr/33946/) is enabled on a child _Registration Item_ record, Vault prevents users from deleting the parent _Registration Item_ unless they have _Read_ and _Delete_ permission on all related records in the hierarchy. * For the _Split Rule_ object: * _Read_ permission, including _Read_ permission on any fields you added to the _Fields to Inherit_ field in [_Split Rule_ records][3]. * If your Vault utilizes [DAC](/en/lr/33946/) for the _Split Rule_ object, users can only select _Split Rules_ for which they have permission to _Read_. * To bulk update the lifecycle state of _Registration Items_ and trigger the automatic bulk creation of _Registration Items_ based on the _Split Registration Items_ entry action: _Application: Object: Bulk Action_. * If your Vault utilizes [Atomic Security](/en/lr/47850/#Atomic_Security_Fields) on fields, users must have _Edit_ permission on the appropriate lifecycle states for the applicable fields. ## Related Permissions {#related-permissions} You can complete all the steps in this article with the standard _System Administrator_ or _Vault Owner_ security profile. If your Vault uses custom security profiles, your profile must grant the following [permissions](/en/lr/22824/):
Type Permission Controls
Security Profile Admin: Configuration: Configuration: All Configuration Ability to add Relational Tokens to Split Rule records.
Security Profile Admin: Configuration: Object Lifecycles: Create, Edit Ability to create and modify object lifecycles.
Security Profile Admin: Configuration: Objects: Create, Edit Ability to create and modify Vault objects.
Security Profile Admin: Security: Permission Sets: Edit Ability to modify permission sets for users.
Security Profile Objects: Object Permissions: All Objects: Read Ability to create Split Rules.
[1]: #mappings [2]: #relational-tokens [3]: #create [4]: #page-layout [5]: #action-config [6]: #user-permissions [7]: #viewer [8]: #supported-fields