Configuring Requirement Generation (Registration & Dossier Management)

Registration & Dossier Management provides users with the ability to define and track what needs to be completed for a registration objective or registration item so that they can register a product or amend an existing registration. Regulatory Affairs users can also create internal non-registration dossiers not typically meant for submission to authorities. For each registration objective or registration item, users can generate Requirements with expected document lists and items based on either a dynamic template of a Requirement Library hierarchy or an existing root Requirement. Users can then create Dossier Binders for the generated top-level Requirement.

You can leverage the various relationships that exist between the associated Product record and other object records in the product hierarchy by defining Relational Tokens and adding them to Requirement Library records. This allows users to generate Requirements specifically for the item to register. For example, instead of generating a generic “Proof of Claims” requirement, you can create a Relational Token named product_claim__c, which Vault will then use to generate three (3) requirements, one (1) for each claim made on the product: “Proof of Long-Lasting Claim”, “Proof of Dermatologically Tested Claim” and “Proof of Hypoallergenic Claim”.

You can also configure your Vault to automatically populate supported fields with values from related source records defined in an Object Mapping linked to the Relational Token when users generate Requirements, EDLs, and EDL Items.

About Requirement Generation

You can configure the Generate Requirements and Update Requirements actions on the Registration object, which lets users automatically generate all Requirements and any EDLs for all Registration Items in a Registration Objective. This allows users to create the same structure of requirements without having to manually recreate the hierarchy of records. Depending on the needs of your organization, you can also configure the actions on the Registration Item object so that users can generate the same structure of requirements for non-registration dossiers.

Users can determine if they want to generate Requirements for every Requirement Library in the hierarchy (including child requirements) based on dynamic template requirement filters or for specific root Requirement Libraries they manually select.

Before users run the Generate Requirements and Update Requirements actions, they can specify a source root Requirement from which to reuse shared requirements, allowing them to generate Requirements based on an existing Requirement. This enables them to reuse shared requirements from a previously submitted dossier that only requires a small change. When a user specifies a source root Requirement, Vault links the generated Requirements to applicable shared source Requirements. Users can later specify if they want to reuse the documents related to the source records when they generate a Dossier Binder from the parent Requirement generated by the Generate Requirements action. When users generate Dossier Binders from parent Requirements created from the Generate Requirements action, Vault automatically reuses documents related to the source records unless the user specifies not to use those source documents.

Requirement Generation Objects

Registration & Dossier Management uses the following core objects to support Requirement generation:

• Requirement Library (requirement__v): This object represents a regulatory activity that needs to be completed or artifacts that need to be collected in order to get approval for a type of registration.
• Requirement (request_requirement__v): This object represents a regulatory activity to be completed for a registration item in a given jurisdiction.
• Registration (registration__v): This object represents proof that validates clearance in a state, country, region, and by Third-Party Certification or Retailer.
  • Registration Objective (registration_objective__v): This Registration object type represents a snapshot of a registration and the related Registration Items at a specific point in time.
• 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.
  • Non-Registration Dossier (nonregistration_dossier__v): This Registration Item object type represents a dossier not typically meant for submission to authorities.
  • Product Registration Item (product_registration_item__v): This Registration Item object type represents a dossier intended for submission to register a product.
• Regulated Category (regulated_category__v): This object represents a category for regulation and contains information about location.

Configuration Overview

Configuring your Vault to generate Requirements involves the following steps:

1. Set up EDL
2. Configure object layouts
3. Optional: Configure the Requirement Hierarchy Viewer
4. Define referenced items
5. Optional: Define an Object Mapping with Field Mappings
6. Optional: Define Relational Tokens
7. Optional: Configure Requirement object types in order to configure the Generate Requirements and Update Requirements actions on both the Registration and Registration Item objects
8. Configure dynamic template requirement filters
9. Configure object actions
10. Optional: Configure dossier document creation from template
11. Configure custom lifecycles
12. Configure custom workflows
13. Configure user permissions

Setting up EDL

You must set up EDL in order for Vault to create EDL and EDL Items when users run the Generate Requirements and Update Requirements actions. See EDL Administration for more details.

If you configure object types on the EDL or EDL Item objects, you must assign all relevant fields included on the base object types to the custom object types you configure.

Each Requirement can link to one (1) EDL and one (1) EDL Item.

Configuring Object Layouts

You must configure object layouts in the following ways:

• For the Requirement Library object:
  • Create an object layout that includes the Regulated Category, EDL, and Token Label fields in a Details section.
  • Optional: Add the Default Order field to allow users to specify a default order for generated Requirements.
  • Insert a related object section for the Requirement Library object. We recommend using the section label “Child Requirements”.
  • Insert a related object section for the Requirement object. We recommend using the section label “Related Requirements”.
  • Insert a related object section for the Regulated Categories object. We recommend using the section label “Regulated Categories”.
• For the Registration object:
  • Create an object layout that includes the following fields in a Details section:
    • Registration
    • Source Dossier: Allows users to select a root Requirement to copy and amend, reusing the applicable shared requirements associated with the specified record.
    • Generate Requirements Job Status: This field automatically updates to reflect the current status of the job after users run the Generate Requirements and Update Requirements actions.
    • Optional: Add the Select Root Requirement field. If users set this field value to “Yes”, Vault will display a dialog when they execute the Generate Requirements user action for a Registration and allow them to select specific root Requirement Libraries. If users set this field to “No” or leave it blank, Vault selects Requirement Libraries based on dynamic template requirement filters you configure for the dynamic template. If you have not defined any Criteria VQL, Vault selects all active Requirement Libraries. You can also configure defaults for this field to ensure users enter the correct data.
  • Insert a related object section for the EDL Item object. We recommend using the section label “Related Documents”.
  • Optional: Insert a related object section for the Requirement object. Do not insert this section if you plan to configure the Requirement Hierarchy Viewer on the Registration object.
• For the Registration Item object:
  • Create an object layout that includes the Event, Location, Product, Registration, and Registration Objective fields in a Details section.
  • Optional: Insert a related object section for the Requirement object. We recommend using the section label “Related Requirements”. Do not insert this section if you plan to configure the Requirement Hierarchy Viewer on the Registration object.
  • Insert a related object section for the Registration Item object. We recommend using the section label “Related Registration Items”.
• For the Requirement object:
  • Add the Source and Use Source fields. The Source field cannot be edited by users.
  • Create and add custom Formula fields to display relevant status icons.

Non-Registration Dossiers

If you also plan to configure the Generate Requirements and Update Requirements actions on the Registration Item object so that users can generate Requirements for non-registration dossiers, make the following updates to the Registration Item object layout:

• Insert a related object section for the EDL Item object. We recommend using the section label “Related Documents”.
• Add the Source Dossier field.
• Optional: Add the Select Root Requirement field.
• Optional: Add the Generate Requirements Job Status field.

Copy & Amend Dossier: Multiple Templates

To support multiple templates so users can copy and amend from a source with a different Requirement Library template than the target dossier, we recommend updating the Requirement Matching Group object layout to include a related object section for the Requirement Library object.

Configuring the Requirement Hierarchy Viewer

You can configure the Registration and Registration Item objects to display related Requirements in a hierarchical structure, allowing users to review and adjust records, nested order, and matched documents before generating a Dossier Binder for a root Requirement. See Configuring the Requirement Hierarchy Viewer for more details.

Defining Referenced Items

For users to be able to generate Requirements, you must define referenced items before they can leverage functionality appropriately, including the Requirement Libraries hierarchy template. You can use Vault Loader to create and update fields on multiple records.

Regulated Categories

You can create Regulated Categories to relate each Requirement Library to a Location. Regulated categories help to organize regulations into logical groupings, such as “cosmetics” or “over the counter (OTC)”.

EDLs & EDL Items

You can define EDLs and EDL Items to link to the applicable Requirement Libraries.

Requirement Matching Groups

Requirement Matching Groups allow you to group descendant Requirement Libraries. For example, if your Vault includes multiple “Proof of Product Claim” Requirement Libraries, each in a different template, you could add them both to the “Proof of Claim” Requirement Matching Group. This allows users to copy and amend a dossier from a source with a different Requirement Library template than the target dossier.

When users select a Source Dossier with a different template from the target dossier, Vault identifies the matching Requirement Libraries based on their shared Requirement Matching Group. For example, when a global team builds a core dossier that is then used as a source for local affiliates, they can use the same source when copying and amending a source dossier.

Requirement Libraries

Requirement Libraries are a hierarchical structure containing levels of parent and child requirements, including some requirements that can act as section groupings. Creating the hierarchical template structure of Requirement Library records allows you to ensure users generate the appropriate Requirements when they generate Requirements. The number of Requirement Libraries to create and the parent-child relationships for your templates varies depending on your organization’s needs. For example, you can create one structure for the “Cosmetic Product Information File (PIF) Template” and another for the “Canada PIF Template”.

For each Requirement Library, you can define the following as needed:

• To associate a descendant Requirement Library with a Requirement Matching Group, select the appropriate group. You cannot populate this field on root records.
• To associate the Requirement Library with a Location, select the appropriate Regulated Category.
• To generate an EDL and EDL Item for the Requirements generated when users run the Generate Requirements and Update Requirements actions, select the EDL checkbox.
• To specify the default order, populate the Default Order field for records within each hierarchical level, with “1” being the top-most record in each section or subsection.
  • If you leave this field blank, any Requirement records generated from that record will sort at the bottom of the list of ordered records in the section it is located within.
  • If the Generate Requirements action creates multiple records from Requirement Libraries with the same Default Order, Vault sorts them based on the related Requirement Library’s name, created date, and ID and then by the Requirement’s name.
  • Vault creates system-managed Requirement Order records to track each Requirement Library’s order.
  • After users run the Generate Requirements and Update Requirements actions, the new Requirements are listed in the Requirement Hierarchy Viewer based on the Default Order of their associated Requirement Libraries in the applicable template. Users can reorder them in the viewer before generating Dossier Binders.

Example

Review the following image for an example of the Requirement Libraries hierarchy you could create to allow users to generate all required Requirements for a Cosmetic PIF. Each item represents a Requirement Library and the parent-child relationships are represented by the nested indentation in the image. In this example, an Admin has included numbered levels in the Name field to help represent the overall structure of the template.

Defining Object Mappings & Field Mappings

You can map field values between a source and target object so that the generated Requirements, EDLs, and EDL Items contain the same values as the source records.

You can leverage Object Mappings to automatically populate values on generated records in the following ways:

• To populate default values on generated Requirements, EDLs, and EDL Items based on values from the source Requirement Libraries (for example, to support automatic document matching).
• To populate values based on the resolution of linked Relational Tokens.

See Defining Object Mappings & Field Mappings for more details.

Defining Relational Tokens

To create multiple Requirements for each instance of a specific product hierarchy relationship, you can optionally define Relational Tokens and reference the Relational Token in the Token Label field of the Requirement Library record. This also allows you to use the name of that token enclosed in curly brackets "{" and "}" (for example: “{product_claim__c}”) in the Name field of Requirement Library records to automatically set the Requirement name based on the definition of the token (for example: “Proof of {product_claim__c}”). You can create recursive Relational Tokens if your product hierarchy has nested levels of the same object.

If token resolution generates multiple Requirements for the same Requirement Library with a defined Default Order, Vault orders those Requirements based on their IDs.

See Defining Relational Tokens for more details about how to create Relational Tokens and then add them to Requirement Library records.

Configuring Requirement Object Types

In order to configure the Generate Requirements and Update Requirements actions on both the Registration and Registration Item objects, you must configure object types on the Requirement object.

You must create at least one (1) custom object type in addition to the base object type for the Requirement object and assign certain fields to all object types. Then, you can configure dynamic template requirement filters on the Requirement Library field for each object type. When you configure Relational Token Setting Components, you will specify which types of Requirement Vault generates when users run the Generate Requirements and Update Requirements actions, depending on if they run the action on a Registration or Registration Item record.

Assigning Fields

After creating custom object types, you must assign the following fields to all Requirement object types:

• Depth in Source Hierarchy
• Parent Requirement
• Registration Item
• Registration Objective
• Requirement Library
• Source
• Use Source

If you do not assign these fields to all object types, the Generate Requirements and Update Requirements actions will fail.

Configuring Dynamic Template Requirement Filters

Configuring dynamic template requirement filters allows you to configure the requirements hierarchy to be dynamic so that users can generate Requirements based on the dynamic template. By applying the appropriate Criteria VQL to the Requirement Library field of the Requirement object, you can ensure that Vault only creates the appropriate Requirements of the specified object type when users run the Generate Requirements and Update Requirements actions. For example, you could add Criteria VQL that filters by the relevant Regulated Categories and the Requirement Lifecycle State on child Requirement Library records to ensure that active requirements that are appropriate for the Regulated Category, such as “Cosmetic”, are created by the action:

id IN (SELECT id FROM regulated_category_requirement_join__cr WHERE regulated_category__c = {{this.request__vr.regulated_category__c}}) AND state__v = 'active_state__c')

Apply Criteria VQL to the Requirement Library field depending on if you configured custom object types for the Requirements object:

• If you configured custom object types: Set up reference constraints on the Requirement Library field for both Requirement custom object types. This defines how Vault creates requirements depending on which object record users run the Generate Requirements and Update Requirements actions. If you do not assign the Requirement Library field to the custom object type you defined in the Relational Token Setting component, Vault applies the Criteria VQL to the base object type. See Setting Up Object Types for more details about assigning fields and setting up reference constraints on object type fields.
• If you did not configure custom object types: Set up a reference constraint on the Requirement Library field on the Requirement object that applies to either the Registration or Registration Item object. This defines how Vault creates requirements when users run the action on either a Registration or Registration Item record, depending on which object you configured the action. See Configuring Reference Constraints for more details about how to configure filters on an object field.

You can only reference the Registration Item field or a field related to the object on which you are applying Criteria VQL.

If you don’t apply any Criteria VQL to the Requirement Library field on the Requirement, Vault automatically creates a Requirement for every Requirement Library unless users set the Select Root Requirement field to “Yes” on the record on which they run the Generate Requirements or Update Requirements action and then select specific root Requirement Libraries in the Select Requirements dialog.

Configuring Object Actions

The following actions support Requirement generation:

• Generate Requirements: Allows users to generate Requirements.
• Update Requirements: Allows users to regenerate Requirements for living dossiers.
• Customize: Allows users to unlink generated Requirements from source EDLs when reusing shared requirements.

Configuring the Generate Requirements Action

The Generate Requirements action allows users to generate a Requirement for every Requirement Library, including child Requirement Libraries based on a dynamic template or existing dossier. You can configure the Generate Requirements action on the Registration and Registration Item objects. We strongly recommend configuring the Generate Requirements action on the Registration object so that users can generate Requirements for typical dossiers intended for submission to authorities, such as country-level dossiers for products. If the needs of your organization require users to also create non-registration dossiers, you can also add the action to the Registration Item object so that users can generate Requirements for dossiers not necessarily intended for submission to authorities, such as global product dossiers.

You can leverage Object Mappings and Relational Tokens to automatically populate fields on generated records.

When the Generate Requirements action runs, Vault does the following:

• Creates Requirements of the specified type based on the value of the Select Root Requirement field on the Registration or Registration Item record that users run the action on:
  • If the field is blank or set to “No”: Creates a Requirement for every active Requirement Library in the hierarchy, including child requirements.
  • If the field is set to “Yes”: Creates a Requirement for root Requirement Libraries the user manually selects in the Select Requirements dialog and any child Requirement Libraries of those root records selected by the user. The list of Requirement Libraries displayed in the dialog is constrained based on the object type you specify for the action and any dynamic template requirement filters you configure for the dynamic template.
• Relates each new Requirement to the Requirement Library record and to the record on which the user ran the action.
• Orders generated records based on the Default Order values of the Requirement Libraries from which they were generated.
• If you set up EDL and users select the EDL checkbox on a Requirement Library before running the action, Vault creates EDL and EDL Items to capture the associated required documents for the registration and associates the EDL and EDL Items to the Requirement.
• If you defined Relational Tokens, Vault automatically creates multiple Requirements for each instance of a specific product hierarchy relationship based on token resolution.
• If you linked any Object Mappings to the action or to defined Relational Tokens, Vault automatically populates those fields on generated Requirements, EDLs, and EDL Items based on source values and token resolution.
• If users specify a root Requirement from which they want to reuse shared requirements and documents, Vault also does the following:
  • Identifies any existing active Requirements related to the specified source root requirement.
  • Links them to the generated Requirements.
  • Populates the Source field on generated records with the name of the source Requirement that is reused for the new records.
  • Selects the Use Source checkbox on all generated records.

Vault also populates several system-managed fields that are used by Vault to link generated Requirements to root Requirements. These fields are not intended to be seen by users:

• Token Resolution Record ID
• Depth in Source Hierarchy

Defining Relational Token Setting Components

You must define Relational Token Setting components linking the Generate Requirements action to a root Relational Token. If you plan to configure the Generate Requirements action on both the Registration and Registration Item objects, you must also specify the types of Requirement records the action creates when users run the action on each object record. If you do not do this, the action will fail. See About RegulatoryOne Component Types for more details about how to create Relational Token Setting components in MDL.

How to Configure the Generate Requirements Action

Depending on your business needs, you can add this action to the Registration and Registration Item objects in the following ways:

• On the Registration object:
  • As an entry action on any Registration lifecycle state. We recommend configuring the action on the applicable Registration lifecycle states to perform conditionally when the record is a Registration Objective type of Registration.
  • As a user action on the Registration object. We recommend not selecting the option to make the action Available in All Lifecycle States and then configuring the action on the applicable Registration lifecycle states to perform conditionally when the record is a Registration Objective type of Registration.
• On the Registration Item object:
  • As an entry action on any Registration Item lifecycle state.
  • As a user action on any Registration Item lifecycle state.

Using Object Mappings to Automatically Populate Fields

When configuring the Generate Requirements action on a lifecycle state, you can link the action to active Object Mappings. This defines how Vault automatically populates mapped fields on generated records with default field values on the source Requirement Library. These Object Mapping fields are optional:

• Requirement to Edl Mapping: Maps fields from the source Requirement Library to the target EDL.
• Requirement to Edl Item Mapping: Maps fields from the source Requirement Library to the target EDL Item.
• Requirement to RIR Mapping: Maps fields from the source Requirement Library to the target Requirement.

Configuring the Update Requirements Action

The Update Requirements action allows users to regenerate a global or core dossier’s Requirements to update them as a company develops new variations of a product, reflecting new information and changes to documentation requirements over time. When a user runs the Update Requirements action, Vault generates Requirements with applicable EDLs and EDL Items based on your dynamic template or the user-specified source dossier. This process is similar to how the Generate Requirements action creates records but excludes Requirements for generation based on any Criteria VQL you’ve configured for the action. For example, you may configure the action to exclude root Requirements in completed or canceled lifecycle states from regeneration.

When a user runs this action, Vault ignores the Select Root Requirement field and does not allow the user to select specific root Requirement Libraries. Instead, the action regenerates Requirements based on your dynamic template or the user-specified Source Dossier, while applying your specified Criteria VQL.

How to Configure the Update Requirements Action

Depending on your business needs, you can add this action to the Registration and Registration Item objects in the following ways:

• On the Registration object:
  • As an entry action on any Registration lifecycle state.
  • As a user action on the Registration object.
• On the Registration Item object:
  • As an entry action on any Registration Item lifecycle state.
  • As a user action on any Registration Item lifecycle state.

Using Object Mappings to Automatically Populate Fields

When configuring the Update Requirements action on a lifecycle state, you can link the action to active Object Mappings. This defines how Vault automatically populates mapped fields on generated records with default field values on the source Requirement Library. We recommend using the same mappings you configured for the Generate Requirements action. You can also specify Criteria VQL to filter which root Requirements the action updates. For example, you can exclude root Requirements in completed or canceled states.

These fields are optional when configuring the action on a lifecycle state:

• Requirement to Edl Mapping: Maps fields from the source Requirement Library to the target EDL.
• Requirement to Edl Item Mapping: Maps fields from the source Requirement Library to the target EDL Item.
• Requirement to RIR Mapping: Maps fields from the source Requirement Library to the target Requirement.
• VQL Criteria: Filters the root Requirements that you want the action to update. This field has a 500-character limit and does not support IN, LIKE, or ORDER BY operators.

Configuring the Customize Action

The Customize action is available to configure on the Requirement object lifecycle. This allows users to unlink a generated Requirement from the EDLs and EDL Items associated with the source Requirement and customize the matched documents for that record. If you have configured object types on the Requirement object, you must assign the action to all applicable object types.

When the Customize action runs, Vault does the following:

• Creates new EDLs and EDL Items for each EDL and EDL Item associated with the source Requirement and relates them to the Requirement on which the action ran.
• Populates the following fields on generated EDLs and EDL Items:
  • Name (copied from source records)
  • Requirement (the Name of the record on which the action ran)
• Populates the following fields on generated EDL Items:
  • EDL (the Name of the applicable parent record)
  • Expected Steady State Count (copied from source records)
• Clears the Use Source checkbox on the Requirement record so that Vault will not include the documents matched to the source EDL Items when users create Dossier Binders that include shared requirements.
• If you configure the action to copy matched documents, Vault includes the documents matched to the source EDL Items and automatically populates the following fields on generated records:
  • Batch Update on EDLs (No, to prevent automatic document matching from reoccurring)
  • Version is Locked on EDL Items (copied from the source record)
• If you defined an Object Mapping with Field Mappings, Vault automatically populates those fields on generated EDL and EDL Item records based on how the linked Relational Token resolved in the source Requirement. Vault does not automatically populate any of the following fields based on token resolution: Name, Requirement, EDL, or Expected Steady State Count.

Users can run the Customize action on active Requirements that meet the following criteria:

• There are no associated active EDLs or EDL Items.
• The Use Source checkbox is selected.
• The Source field is populated with a Requirement with associated EDLs and EDL Items, none of which reference other Requirements.
• The shared Requirement Library is active, has the EDL checkbox selected, and is shared with the source Requirement.

How to Configure the Customize Action

To configure the Customize action:

1. Assign the Customize action to the Requirement object.
   • Optional: Select the Available in All Lifecycle State checkbox to apply atomic action security defaults for the applicable lifecycle states.
2. Add the action as a user action to the applicable states of the Requirement object lifecycle.
   • Optional: Select the Copy Matched Documents checkbox to automatically carry over the matched documents to generated EDL Items. If you do not select the checkbox, generated EDL Items do not include any matched documents.

Configuring Automatic Dossier Document Creation from Templates

You can configure your Vault to allow users to create dossier documents from templates. See Configuring Automatic Dossier Document Creation from Templates for more details.

Configuring Object Lifecycles

You can create custom lifecycles for the Registration and Registration Item objects and add custom lifecycle states to suit your organization’s needs.

Configuring Object Workflows

You can create custom workflows for the Registration and Registration Item objects to suit your organization’s needs. Ensure you have a custom lifecycle initially created.

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 Requirement object: Create permission, including Create permission on any configured object types.
• For the Registration and Registration Item objects: Edit permission on the Generate Requirements Job Status field.
• To delete a Requirement and all of its children, users must have Delete permissions on the Requirement (including any configured object types), EDL, and EDL Item objects.
• When generating Requirement Libraries for a Registration with the Select Root Requirement field value of “Yes”, Vault filters the Requirement Libraries in the dialog based on the user’s Read permissions, including Read permission on any fields included in dynamic template requirement filters.

Customize Action

To run the Customize action, users must have the Application: Vault Actions: EDL Matching: Edit Match Fields permission.

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