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 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 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.
Note: In Vaults created prior to 21R2, the Registration Item object may be labeled Request.
Configuration Overview
Configuring your Vault to split Registration Items involves the following steps:
- Optional: Define Object Mappings with Field Mappings to specify how certain fields on generated Registration Items are populated based on how the applicable Relational Token resolves
- Define applicable Relational Tokens that determine how Vault creates and relates new Registration Items
- Create Split Rules that users can select to specify how to split a source Registration Item
- Configure the Registration Item object
- Optional: Configure the Registration Item Viewer on the Registration Item object so users can see the hierarchical structure of split records
- Configure actions on the Registration Item object
- Configure user permissions
Note: Depending on your Vault’s creation date and which features are currently enabled and configured, some of the steps described in this article may be unavailable or already complete in your Vault.
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 in 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 (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 field on the Registration object.
See Defining Object Mappings & Field Mappings for more details.
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. 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, 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 run the Split Registration Items action. For example, splitting by Product.
To create a new Split Rule:
- Navigate to Business Admin > Objects > Split Rules.
- Click Create.
- Enter a Rule Name. Ensure you describe the rule appropriately because this is the name users see for selection when selecting a Split Rule.
- 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 automatically 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 that reference other Registration Item fields, you must also include the referenced Registration Item fields as Fields to Inherit.
- If you want the generated Registration Items to be the same object type as the source record, include
- Enter the Name of an active Relational Token to define how Vault generates new Registration Items from the source Registration Item.
- 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.
- Click Save.
Note: If you add a Field to Inherit and select a Relational Token that includes an Object Mapping with a Field Mapping for the same inherited field, users will get an error when they run the Split Registration Items action due to conflicting field mappings and Vault will not create any new Registration Items.
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 layout
- 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:
- Depth in Split Hierarchy
- Depth in Split Parent Hierarchy
- Split Job Status
- Split Parent
- Split Rule
- Split Source
Note: The Output Structure field is automatically populated with the Flat value on all Split Rule records created prior to 22R1. You can update this value as needed.
Configuring the Registration Item 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:
- Navigate to Admin > Configuration > Objects > Registration Item > Layouts > [Layout].
- Insert the Registration Item Viewer control section with the slider () icon.
- Optional: Enter a Section Label.
- 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.
- Optional: Enter Section Help that users will see in this section.
- Optional: Select the Expand the section by default checkbox so that the section is always open when users open Registration Item object records.
- Optional: Select the Shade hierarchical levels checkbox to help distinguish the hierarchical composition of the Registration Item object records.
- Optional: Select the Highlight row on hover checkbox to highlight the row that users hover on.
- 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.
- Click Done.
- Click Save when you are finished updating the Registration Item layout.
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
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.
Note: We recommend that you do not configure more than a single entry action on any Registration Item object lifecycle state, which may result in unexpected values in the corresponding job status fields when those actions complete.
Configuring the Split Registration Items Action
Note: Before configuring this action, you must define a Relational Token Setting component that links this action to a root Relational Token. If you do not do this, the action will fail.
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.
- 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.
- Read permission on any fields you added to the Grid Columns field in the Registration Item Viewer section. 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 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.
- If your Vault utilizes DAC 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 on fields, users must have Edit permission on the appropriate lifecycle states for the applicable fields.
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:
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. |