# Generating Requirements (Registration & Dossier Management)

[Registration & Dossier Management](/en/lr/71498/) provides you with the ability to define and track what needs to be completed for _Registration Objectives_ and _Registration Items_ so that you can register a product or amend an existing registration. Regulatory Affairs users can also create internal non-registration dossiers not usually meant for submission to authorities. For each registration objective or registration item, you can generate and regenerate requirements with expected document lists and items based on an Admin-defined dynamic template for the product or based on an existing root _Requirement_. You can then create [Dossier Binders](/en/lr/76898/) for the generated top-level _Requirement_. 

Depending on your [Admin's configuration](/en/lr/71505/), object, field, and section labels may appear differently than the labels mentioned in this article.

## About Requirement Generation {#about}

_Requirement Libraries_ are a hierarchical structure containing levels of parent requirements and child requirements, including some requirements that may act as section groupings. A _Requirement_ is a _Requirement Library_ for a specific _Registration Item_. The [_Generate Requirements_][13] action lets you generate all _Requirements_ for _Registration Objectives_ and _Registration Items_. The [_Update Requirements_][12] action lets you regenerate _Requirements_ to reflect changes since you last generated _Requirements_.

When you generate _Requirements_, Vault can leverage the various relationships that exist between the _Product_ record associated with the root _Registration Item_ or _Registration_ and other object records in the product hierarchy. If your Admin has configured your Vault to create multiple requirements for each instance of a specific product hierarchy relationship, some _Requirements_ will repeat for each instance of a specific relationship. For example, a "Raw Material Information" parent _Requirement_ could result in the creation of multiple child _Requirements_ for each _Raw Material Formulation_ record associated with the _Product_ on the _Registration Item_.

### Copy & Amend Dossier {#reusing-shared}

You can copy and amend an existing dossier by selecting it as the source before generating _Requirements_. Before you run the  action, you can specify a source root _Requirement_ in the _Source Dossier_ field on _Registration Objectives_ and _Registration Items_ from which to reuse shared requirements and matched documents. Specifying a source root _Requirement_ allows you to generate _Requirements_ based on that _Requirement_ and reuse the shared requirements and expected documents. This may be helpful if you need to make a small change to a previously submitted dossier. When you later [generate a Dossier Binder](/en/lr/76898/#shared-requirements) from the parent _Requirement_ created from the _Generate Requirements_ action, Vault includes those shared documents unless you specify not to use the source documents by running the [_Customize_ action][7].

#### Example Use Case: Reusing Shared Requirements {#example}

Your organization previously submitted a dossier called "Bellor Lipstick Registration: EU" to register a product in the European Union (EU) and now needs to register the same product in Spain. Since many of the requirements to register the product in Spain are the same requirements used to register the product in the EU, you want to copy and amend the "Bellor Lipstick Registration: EU" dossier to only reuse the applicable shared requirements. To do this, you create a new _Registration Objective_ and name it "Bellor Lipstick Registration: Spain".
 
To reuse shared requirements included in the previously submitted dossier, you select the "Bellor Lipstick Registration: EU" _Requirement_ in the _Source Dossier_ field and then run the _Generate Requirements_ action. Vault generates _Requirements_ for every _Requirement Library_ in the hierarchy that is required to register the product in Spain.
 
Vault identifies which of the _Requirements_ in the "Bellor Lipstick Registration: EU" dossier can be shared with the generated _Requirements_ in the "Bellor Lipstick Registration: Spain" objective. Vault populates the _Source_ fields on the generated records with the names of the "Bellor Lipstick Registration: EU" source _Requirements_ records with which "Bellor Lipstick Registration: Spain" is sharing the requirement so that you can access the relevant _EDL Items_. Vault does not generate _EDLs_ or _EDL Items_ for shared requirements because the existing _EDL Items_ associated with the source records are also applicable for registering the product in Spain. 
 
When you create a "Bellor Lipstick Registration: Spain" Dosser Binder from the top-level _Requirements_ generated for the _Registration Objective_ for Spain, you can specify if each _Requirement_ record in the hierarchy will reuse the shared source documents. If you do use the shared documents, any updates you make to shared documents are reflected each time you create binders for either of the "Bellor Lipstick Registration: EU" and "Bellor Lipstick Registration: Spain" dossiers.

### Living Dossiers {#living-dossiers}

You can use the [_Update Requirements_][12] action to regenerate a global or core dossier's _Requirements_ to reflect new information and changes to documentation requirements over time. This may be helpful when a company develops new variations of a product with new information and documentation requirements. For example, if your organization maintains an Ingredient List Number (ILN) dossier that includes requirements for the products that reference the ILN, you must add the documentation for new products to the ILN's dossier, such as a new shade of an existing product.

## Defining Referenced Items {#reference-items}

Before generating _Requirements_, you can define _Regulated Categories_, _EDLs_, _EDL Items_,  and _Requirement Libraries_ by creating new records or updating existing records.

### Regulated Categories {#regulated-categories}

You can define _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 {#edls}

You can define [_EDLs_ and _EDL Items_](/en/lr/32749/) to link to the applicable _Requirement Libraries_.

### Requirement Libraries {#define-req}

You can define _Requirement Libraries_ from which you'll generate _Requirements_. For each _Requirement Library_, you can define the following as needed:

* To generate an [_EDL_ and _EDL Item_](/en/lr/32749/) when generating _Requirements_, select the **EDL** checkbox.
* To associate the _Requirement Library_ with a _Location_, select the applicable **Regulated Category**.
* To specify the default order of generated _Requirements_ in the dossier, populate or update the **Default Order** field. You can adjust the order of generated _Requirements_ in the [Requirement Hierarchy Viewer][10] before generating [Dossier Binders][8].

## Generating Requirements {#generating}

Depending on your Admin's configuration, you may be able to generate _Requirements_ by running the _Generate Requirements_ action on the following records:

* **Registration Objectives**: Creates requirements for typical dossiers that you plan to submit to authorities, such as country-level dossiers for products.
* **Events**: Creates *Requirements* for all *Registration Objectives* associated with an *Event* for typical dossiers that you plan to submit to authorities, such as country-level dossiers for products. 
* **Registration Items**: Creates requirements for internal non-registration dossiers not usually meant for product registration that you will not submit to authorities, such as global product dossiers.

When you run the _Generate Requirements_ action, Vault does the following:

* Creates a _Requirement_ of an Admin-defined type for either:
    * Specific root _Requirement Libraries_ you manually select.
    * Every active _Requirement Library_ in the hierarchy (including child requirements) that matches an Admin-defined filter.
* Relates each generated _Requirement_ to the _Requirement Library_ and to the record on which you ran the action.
* Sorts the generated _Requirements_ in the dossier based on the [_Default Order_ values of the related _Requirement Libraries_][1]. If the action creates multiple records from _Requirement Libraries_ in the same section with the same _Default Order_, Vault orders them based on the related _Requirement Library's_ name, created date, and _ID_ and then by the _Requirement's_ name.
* If you selected the [_EDL_ checkbox on a _Requirement Library_][1], Vault creates [_EDLs_ and _EDL Items_](/en/lr/32749/) to capture the associated required documents for the registration and associates the _EDL_ and _EDL Items_ to the _Requirement_. Each _Requirement_ can link to one (1) _EDL_ and one (1) _EDL Item_.
* If configured by your Admin, Vault populates any Admin-mapped fields on all generated _Requirements_, _EDLs_, and _EDL Items_.
* If you specify a root _Requirement_ from which you want to reuse shared requirements and documents, Vault also does the following:
    * Identifies requirements matched to the source root record, including its child _Requirements_.
    * Links them to the generated _Requirements_.
    * Populates the _Source_ field on these records so you can trace the source requirements.
    * Selects the _Use Source_ checkbox on all generated records.

### How to Generate Requirements {#how-to}

Depending on your Admin's configuration, you may be able to run the _Generate Requirements_ action on a [_Registration Objective_, _Registration Item_][15], or [_Event_][16].

#### Registration Objectives & Registration Items {#ro-ri}

To run the action on a _Registration Objective_ or _Registration Item_:

1. Navigate to the applicable _Registration_ or _Registration Item_.
2. Optional: Click **Edit** to modify the record:
  * Optional: Update the **Select Root Requirement** field to **Yes** if you want to select specific root requirements. If you select **No** or leave this field blank, Vault generates _Requirements_ based on the Admin-defined dynamic template.
  * Optional: In the **Source Dossier** field, select an active root _Requirement_ to reuse applicable shared requirements associated with the specified record. The source root record must have the same _Requirement Library_ as the record for Vault to generate _Requirements_. If you leave this field blank, Vault will not reuse any shared requirements for the _Requirement_.
  * Click **Save**.
3. From the **All Actions** menu, select **Generate Requirements**.
4. If you selected **Yes** for the **Select Root Requirement** field before running the action on a _Registration Objective_ or _Registration Item_, Vault displays the _Select Requirement_ dialog listing root _Requirement Libraries_, which may be filtered based on Admin-defined criteria and your permissions. 
   1. Optional: Apply **Filters** to refine the list. 
   2. Select up to 100 root _Requirement Libraries_.
   3. Click **Continue**.

#### Events {#event}

To run the action on an _Event_:

1. Navigate to the applicable _Event_.
2. Optional: To reuse shared requirements for any associated _Registration Objective_:
   1. Navigate to the applicable associated _Registration Objective_.
   2. Click **Edit** to modify the record.
   3. In the **Source Dossier** field, select an active root _Requirement_ to reuse applicable shared requirements associated with the specified record. The source root record must have the same _Requirement Library_ as the record for which Vault will generate _Requirements_. If you leave this field blank, Vault will not reuse any shared requirements for the _Requirement_.
   4. Click **Save**.
3. For all applicable associated _Registration Objectives_, select an active root _Requirement_ in the **Source Dossier** field to reuse applicable shared requirements associated with the specified record. The source root record must have the same _Requirement Library_ as the record for which Vault will generate _Requirements_. If you leave this field blank on any associated _Registration Objective_, Vault will not reuse any shared requirements for the _Requirement_ for that _Registration Objective_.
4. From the **All Actions** menu of the _Event_, select **Generate Requirements**.

#### After Requirement Generation

When notified that _Requirement_ generation is complete, you can review the generated requirements. If applicable, you can:

* Manually add additional _EDL Items_.
* And documents using the [Requirement Hierarchy Viewer][10].
* [Customize matched documents][7] for shared requirements.
* [Automatically create and add dossier documents from templates][11].

Vault adds relevant _EDL Items_ to the _Expected Documents_ section based on your Admin's configuration. If you selected an existing _Requirement_ in a _Source Dossier_ field before running the _Generate Requirements_ action, Vault selects the _Use Source_ checkbox on generated _Requirements_ and does not add _EDL Items_ for any _Requirement_ linked to a source. This is because the _EDL Items_ related to the source _Requirement_ are shared with the generated _Requirement_.

### Automatic Requirement Creation {#auto-creation}

Depending on your Admin's configurations, your Vault may generate all requirements based on Admin-defined criteria when the _Registration_, _Event_,  or _Registration Item_ enters a specific lifecycle state rather than, or in addition to, the action being available to you in the **All Actions** menu. Change the state of the record from the **Workflow Actions** menu to trigger the action.

### Notifications {#generate-notifications}

When Vault finishes generating _Requirements_, you'll receive an email and a Vault notification. The notification lets you know if the generation was successful or if there were any errors.

### Limitations {#generate-limitations}

The following limitations apply to the _Generate Requirements_ action:

* The action creates up to 4,000 _Requirements_, up to ten (10) levels deep.
* If you select a source root _Requirement_ in the _Source Dossier_ field from which to reuse shared requirements, Vault supports up to six (6) hierarchical levels from a primary source root.
* When running the action on an _Event_, the action fails if there are more than 10,000 associated _Registration Objectives_.
* Vault supports up to 1,000 _Registration Objectives_ for a given _Registration_.

## Updating Requirements {#update}

When configured by your Admin, you can regenerate _Requirements_ by running the _Update Requirements_ action. This action generates _Requirements_ from the Admin-defined dynamic template or the specified _Source Dossier_ and reflects all changes to applicable _Requirement Libraries_ since you last generated _Requirements_. When you run the _Update Requirements_ action, Vault creates records similar to how it creates records when you run the [_Generate Requirements_ action][13], but excludes root _Requirements_ based on Admin-defined criteria. For example, your Admin may have configured the action to exclude root _Requirements_ in completed or cancelled states. When you run this action, you cannot select root _Requirements_, even if you selected _Yes_ for the _Select Root Requirement_ field.

To update _Requirements_:

1. Navigate to the applicable active _Registration Objective_, _Event_, or _Registration Item_.
2. If the **Source Dossier** field is populated on an applicable record, ensure it references an active record.
3. From the **All Actions** menu, select **Update Requirements**.

When notified that _Requirement_ generation is complete, you can review the generated requirements. If applicable, you can:

* Manually add additional _EDL Items_.
* And documents using the [Requirement Hierarchy Viewer][10].
* [Customize matched documents][7] for shared requirements.
* [Automatically create and add dossier documents from templates][11].

### Automatic Requirement Updates {#update-auto-creation}

Depending on your Admin's configurations, your Vault may automatically update requirements based on Admin-defined criteria when the _Registration_, _Event_,  or _Registration Item_ enters a specific lifecycle state rather than, or in addition to, the action being available to you in the **All Actions** menu. Change the state of the record from the **Workflow Actions** menu to trigger the action.

### Notifications {#update-notifications}

When Vault finishes updating _Requirements_, you'll receive an email and a Vault notification. The notification lets you know if the generation was successful or if there were any errors.

### Limitations {#update-limitations}

This action has the same limitations as the [_Generate Requirements_ action][14].

## Customizing Matched Documents for Shared Requirements {#customizing}

If you don't want to reuse the documents associated with any shared requirements, you can unlink a _Requirement_ from the shared source _EDLs_ and _EDL Items_ by running the _Customize_ action. When you run the _Customize_ action on a generated _Requirement_, Vault generates _EDLs_ and _EDL Items_ for each _EDL_ and _EDL Item_ associated with the source _Requirement_. Vault adds the generated _EDL Items_ to the _Expected Document_ section of the applicable _Registration_ or _Registration Item_ and populates certain fields on the generated records copied from the source records or based on Admin-defined mappings.

Depending on your Admin's configuration, the _Customize_ action may also do the following:
* Carry over documents matched to the source _EDL Items_ to the generated _EDL Items_. When this happens, the generated _EDL Items_ are matched to the same documents matched to the source _EDL Item_. Vault populates the _Batch Update_ field with _No_ on generated _EDLs_ to prevent [continuous matching](/en/lr/32749/#continuous) on the _EDL Items_ related to each _EDL_.
* [Match documents to _EDL Items_](/en/lr/32749/#matching) based on the _Matching EDL Item Fields_ setting for the source parent _EDL_. This allows you to auto-match documents that differ from the source dossier.

You 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 Customize Matched Documents {#how-to-customize}

To customize matched documents for shared requirements:

1. Navigate to the _Requirement_ section of the _Registration_ or _Registration Item_ on which you generated _Requirements_.
2. Find the active _Requirement_ you want to unlink from the shared _EDLs_ and _EDL Items_ and select **Customize** from the record's **Actions** menu.
3. When notified that the action is complete, navigate to the _Expected Documents_ section of the _Registration_ or _Registration Item_ to review the generated _EDL Items_. Certain fields may be populated based on your Admin's configuration.
4. Optional: Open the generated _EDL Items_ and [manually match the appropriate documents](/en/lr/32749/#matching).
 
Vault clears the _Use Source_ checkbox on the _Requirement_ after you run the _Customize_ action since that record is no longer linked to documents matched to the source _EDL Items_. You cannot select the _Use Source_ checkbox on any _Requirement_ linked to an active _EDL_ or _EDL Item_.

### Automatic Requirement Customization {#auto-custom}

Depending on your Admin's configuration, your Vault may customize matched documents for shared requirements when the _Requirement_ enters a specific lifecycle state rather than, or in addition to, the action being available to you in the **All Actions** menu. Change the state of the record from the **Workflow Actions** menu to trigger the action.

### Notifications {#customize-notifications}
When Vault finishes generating _EDLs_ and _EDL Items_, you'll receive a Vault notification. The notification lets you know if the action was successful or if there were any errors. When the action is successful, the notification includes details about which fields Vault populated on the generated records, including any Admin-mapped fields.

### Limitations {#customize-limitations}

The [_Customize_ action][7] fails if the source _Requirement_ is related to more than 100 _EDLs_ or 100 _EDL Items_ or if any of the source _EDL Items_ are matched to more than 500 documents.

## Creating & Updating Requirements {#create}

You can manually create and update _Requirements_:

1. Open an existing _Requirement_ record or navigate to **Registrations > Requirement** to create a new record.
    * To create a new record:
        1. Click **Create**.
        2. Select the type.
        3. Click **Continue**.
        4. Enter a **Name**.
2. Add or update the applicable details. You must select either a **Registration Item** or **Registration Objective**.
    * Selecting a **Registration Objective** populates the _Requirement_ field. If you are creating a root _Requirement_, this field must reference a root _Requirement Library_ record.
3. Click **Save**.

## Deleting Requirements {#delete}

You can delete a _Requirement_ by selecting **Delete** from the record's **All Actions** menu, which also deletes all child _Requirements_  and any related _EDLs_ and _EDL Items_.

## Automatically Creating Dossier Documents from Templates {#documents-from-templates}

After generating _Requirements_, you can use the _Auto create document from template_ action to generate documents from templates. See [Creating Dossier Documents from Templates Automatically](/en/lr/679926/) for more details.

## Using the Requirement Hierarchy Viewer {#viewer}

If configured by your Admin, you can access the Requirement Hierarchy Viewer on _Registration Objectives_ and _Registration Items_. The viewer displays all active related _Requirements_ in a hierarchical structure, allowing you to review and adjust records, nested order, and matched documents before generating a [Dossier Binder][8]. See [Using the Requirement Hierarchy Viewer](/en/lr/623829/) for more details.

## Creating Dossier Binders {#dossier-binders}

After generating _Requirements_, you can create a Dossier Binder for the top-level _Requirement_. See [Working with Dossier Binders](/en/lr/76898/) for more details.

 [1]: #define-req
 [2]: #registration-item
 [3]: #how-to
 [4]: #auto-creation
 [5]: #example
 [7]: #customizing
 [8]: #dossier-binders
 [9]: #requirements
 [10]: #viewer
 [11]: #documents-from-templates
 [12]: #update
 [13]: #generating
 [14]: #generate-limitations
 [15]: #ro-ri
 [16]: #event