Registration & Dossier Management allows users to generate new Registration Items based on the attributes of a single Registration Item by “splitting” 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 trigger the Split Registration Items action, Vault creates four (4) new related Registration Items, one (1) for each Product in the holiday kit.

You can configure an action that lets users automatically generate new Registration Items based on Split Rules, which utilize Relational Tokens 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 are automatically populated 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.

Splitting Registration Item Objects

Registration & Dossier Management uses the following core objects to support splitting Registration Items:

  • Registration Item (request__v): This object represents a request to identify or scope out what needs to be done to market or sell a product in a jurisdiction.
  • Split Rule (split_rule__v): This object represents an Admin-defined rule that users can use to split a source Registration Item into new, related Registration Items.

Configuration Overview

Configuring your Vault to split Registration Items involves the following steps:

Defining Object Mappings & Field 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 automatically populated based on how the Relational Token specified for the Split Rule resolves. For example, you can create an Object Mapping with a Field Mapping to automatically 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 (request__v) Target Object. This will help users understand which specific records Vault creates when they trigger the Split Registration Items action.

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

If you link a Split Rule with an Output Structure of Hierarchy to a recursive Relational Token, 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

Split Rules determine how Vault creates and relates new Registration Items based on the attributes of a source Registration Item when users trigger the Split Registration Items action. For example, splitting by Product.

To create a new Split Rule:

  1. Navigate to Admin > Business Admin > 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”. 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. You can include up to 40 field Names, each separated by a comma. When users run the Split Registration Items action, Vault automatically populates these fields on all new Registration Items with the same values on the source Registration Item record.
  5. Enter the API name of an active Relational Token to define how Vault generates new Registration Items from the source Registration Item. You can find the API name of Relational Tokens using MDL.
  6. Select the Output Structure. If you choose Hierarchy and also enter a recursive Relational Token, 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

You must configure the following components on the Registration Item object for all object types:

  • Ensure that the Name field is system-managed
  • Add the Split Rule field and a related object section to the object page layout
  • Optional: Add the Split Source and Split Parent fields to the object page layout so that users can see the source and parent on generated records
  • Assign the following fields to all object types:
    • Depth in Split Hierarchy
    • Depth in Split Parent Hierarchy
    • Split Job Status
    • Split Parent
    • Split Rule
    • Split Source

Configuring the Registration Item Viewer

You can add the Registration Item Viewer control section with the slider (Slider Icon) icon to the Registration Item object page 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 add the viewer:

  1. Navigate to the object page editor for the Registration Item object.
  2. Click Add Section and select Registration Item Viewer.
  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.
  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 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 page layout.

Supported Fields

Vault supports the following object field types in the Grid Columns field:

  • Date
  • ID
  • Lifecycle State
  • Name
  • Number
  • 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

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

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 you 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.
  • Automatically populates any fields on new Registration Items that are configured to inherit values from the source record.
  • Automatically 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, Vault automatically 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.
  • Automatically removes any duplicate sibling Registration Items.

Depending on your business needs, you can:

  • Add this action as an entry action on any Registration Item lifecycle state
  • Add this action as a user action on any Registration Item lifecycle state
  • Add this action as a record action on the Registration Item object

Configuring the Deep Delete Split Registration Items Action

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 on any Registration Item lifecycle state
  • Add this action as a record action 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

You must ensure users have the appropriate read and create permissions 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.
  • For the Split Rule object: Read permission.
  • For any fields you added to the Fields to Inherit field in Split Rule records: Read permission.
  • For any Registration Item fields you added to the Grid Columns field in the Registration Item Viewer section: Read permission. Users can only see values of fields for which they have Read permission.
  • 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.
  • To delete a Registration Item: Delete permission on the Registration Item (all object types) and Read permission on the Split Parent field.
  • If your Vault utilizes DAC for objects, users can only select Split Rules on Registration Items that they have permission to Read.
  • If DAC 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.
  • If your Vault utilizes Atomic Security on fields, users must have Edit permission on the appropriate lifecycle states for the applicable fields.
  • Vault creates and relates new Registration Items based on Relational Tokens that resolve even when those Relational Tokens reference objects for which users do not have Read permission.

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:

Type Permission Controls
Security Profile Admin: Configuration: All Configuration Ability to add Relational Tokens to Split Rule records.
Security Profile Objects: All Objects: Read Ability to create Split Rules.
Security Profile Admin: Configuration: Objects: Create, Edit Ability to create and modify Vault objects.
Security Profile Admin: Permission Sets: Read, Create, Edit Ability to make changes to permission sets for users.
Security Profile Admin: Configuration: Object Lifecycles: Create, Edit Ability to create and modify object lifecycles.