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 a set of 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 action 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 Generate Requirements action 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 requirement filters or if they want to generate Requirements only for specific root Requirement Libraries they manually select.

Before users run the Generate Requirements action, 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 requires only 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. A Registration Objective type of Registration represents a snapshot of a registration and the applicable 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.
  • 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 page 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 action on both the Registration and Registration Item objects
  8. Configure requirement filters
  9. Define Relational Token Setting components
  10. Configure the object actions
  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 action. 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 Page Layouts

You must configure object page layouts in the following ways:

  • For the Requirement Library object:
    • Create an object page 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.
    • Add a related object section for the Requirement Library object. We recommend using the section label “Child Requirements”.
    • Add a related object section for the Requirement object. We recommend using the section label “Related Requirements”.
    • Add a related object section for the Regulated Categories object. We recommend using the section label “Regulated Categories”.
  • For the Registration object:
    • Create an object page layout that includes the following fields in a Details section:
      • Registration
      • Source Dossier: Allows users to select a root Requirement to reuse 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 action.
      • 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 Criteria VQL requirement filters you configure. 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.
    • Add a related object section for the EDL Item object. We recommend using the section label “Related Documents”.
    • Optional: Add a related object section for the Requirement object. Do not add this section if you plan to configure the Requirement Hierarchy Viewer on the Registration object.
  • For the Registration Item object:
    • Create an object page layout that includes the Event, Location, Product, Registration, and Registration Objective fields in a Details section.
    • Optional: Add a related object section for the Requirement object. We recommend using the section label “Related Requirements”. Do not add this section if you plan to configure the Requirement Hierarchy Viewer on the Registration object.
    • Add 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 action on the Registration Item object so that users can generate requirements for non-registration dossiers, make the following updates to the Registration Item object page layout:

  • Add 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.

Requirement Hierarchy Viewer

You can configure the Registration and Registration Item objects to display related Requirements in a hierarchical structure, allowing users to review the 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.

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)”.

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 structure of Requirement Library records allows you to ensure users generate the appropriate Requirements when the Generate Requirements action runs. The number of Requirement Libraries to create and the parent-child relationships varies depending on your organization’s needs.

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

  • 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 action, 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 Requirement 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 action, 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.

You can use Vault Loader to create and update fields on multiple Requirement Library records.

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.

Requirements 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 Item records contain the same values as the source record on fields that include 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 action 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 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 action, 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 Request Requirement
  • Registration Item
  • Registration Objective
  • Requirement Library
  • Source
  • Use Source

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

Configuring Requirement Filters for Dynamic Templates

Configuring 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 creates only the appropriate Requirements of the specified object type when users run the Generate Requirements action. 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 only 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 action. 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 only 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 reference only 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 action and then select specific root Requirement Libraries in the Select Requirements dialog.

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.

Configuring Object Actions

You must configure the Generate Requirements action so users can generate Requirements. You can optionally configure the Customize action so users can 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. 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.

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 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 requirement filters you configure.
  • 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 defined an Object Mapping with Field Mappings, Vault automatically populates those fields on generated Requirement, EDL, and EDL Item records based on 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

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

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 associated 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 only 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.

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.

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 Criteria VQL requirement filters.

Customize Action

To run the Customize action, users must have the Application: Vault Actions: EDL Matching: Edit Match Fields 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: 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.