# Configuring Local Impact Assessments (Registration & Dossier Management) Registration & Dossier Management provides users with the ability to assess if a new registration objective can be accomplished by amending an existing registration or if a new registration is required for a location's specific regulations. Users can search existing registrations for matches and Vault identifies which of the matching registrations can be used to register the product or if any matches must be amended before they can be used to register the product. Users can then select the most appropriate registration, initiating the appropriate registration process. Vault uses _Regulated Category Impacts_ to match _Registrations_ and _Registration Objectives_ to _Registration Items_ based on fields in that record matching to fields in existing _Registration Items_. Vault then identifies the _Registrations_ related to those matching _Registration Items_. If the _Regulated Category Impacts_ reference optional Relational Tokens that are linked to Object Mappings with Field Mappings for those fields, Vault populates on _Registration Item_ fields based on Relational Token resolution. After configuring your Vault for Local Impact Assessments, you can configure Global Change Impact Assessments .
## Configuration Overview {#overview} Configuring your Vault to use Local Impact Assessments involves the following steps: 1. [Configure objects and object layouts][2] 2. [Populate _Registration Items_ with the appropriate values][3] 3. [Create Registration Attributes][5] 4. [Create _Regulated Category Attribute Impacts_][8] to define how Vault identifies matches and which matches require amendments 5. [Configure actions][9] 6. [Define Local Impact Assessment Lifecycle Rules][21] 7. [Configure user permissions][14]
## Configuring Local Impact Assessment Objects {#configuring-objects} You must configure several objects to support Local Impact Assessments: * Ensure that the _Name_ field on the _Registration_ object is system-managed on all object types. * Assign the following fields to all relevant _Registration Item_ object types: * _Generate Registration Data Job Status_ * _Local Impact Assessment Job Status_ * _Create Registration and Obj Job Status_ * Add the following fields to the _Registration Item_ object layout for all applicable object types: * _Eligible for Impact Assessment_ * [_Registration_][3] (`parent_registration__v`) * [_Regulated Category_][3] (`regulated_category__v`) * _Regulatory Process Type_ * Optional: Add the following fields to allow users to track the status of relevant jobs run by the associated [object actions][9]: * _Generate Registration Data Job Status_ * _Local Impact Assessment Job Status_ * _Create Registration and Obj Job Status_ ### Adding Matching Control Fields {#control-fields} You must add the _Matching Registration_ and _Matching Registration Objective_ control fields to the _Registration Item_ object layout so that users can see relevant matches when they run the _Local Impact Assessment_ action. ##### Defining an Object Mapping with Field Mappings {#object-mapping} You can define an Object Mapping with Field Mappings to map fields from the _Registration Item_ source object to the _Registration_ target object and then select that Object Mapping in the _Matching Registration_ control field. These Field Mappings appear as default filters in the _Search: Registration_ dialog when users select an unmatched _Registration_ . The dialog does not support mapping Long Text fields and always includes the following default filter: _Type_ equals _Registration Objective_. See Defining Object Mappings & Field Mappings for more details about how to create an Object Mapping. ##### Configuring Matching Control Fields {#configure-control-fields} To add these fields: 1. Navigate to **Admin > Configuration > Objects > Registration Item > Layouts**. 2. Open the applicable layout. 3. Select the **Matching Registration** control field with the slider (Slider Icon) icon. 1. Optional: Enter **Help** text to customize the label and tooltip text that appears to users for this field. 2. Optional: For **Registration Grid Columns**, select up to ten active [supported][16] _Registration_ object fields to display to users in the _Search Registration_ dialog . The _Name_ field always displays as the first column, so you do not have to add it. Drag and drop the fields to determine the order the columns display to users. 3. Optional: Select **Lifecycle States to Ignore** to exclude _Registrations_ in certain lifecycle states from appearing to users in the _Search: Registration_ dialog to select an unmatched record for a _Registration Item_. This drop-down includes all active lifecycles on the _Registration_ object. 4. Optional: Select **Object Mapping for Default Registration Filtering**. This drop-down includes all active [Object Mappings][22] that map the _Registration Item_ source object to the _Registration_ target object to allow users to filter search results in the _Search: Registration_ dialog based on the selected mapping. 5. Click **Done**. 4. Add the **Matching Registration Objective** control field with the slider (Slider Icon) icon. You can define [Local Impact Assessment Lifecycle Rules][21] to specify certain lifecycle states Vault ignores when populating this field with matching records. 1. Optional: Enter **Help** text that displays to users for this field. 2. Click **Done**. 5. Click **Save**. #### Supported Fields & Field Types {#supported-fields} Vault supports the _Lifecycle State_ (`state__v`) field and the following object field types in the _Registration Grid Columns_ field: * Date * Name * Number * Object (excluding references to the _Document_ and _User_ objects) * Picklist * Text * Yes/No * Lookup (so long as the type is a supported type listed above) ### Configuring Registration Object Types {#registration-object-types} If you set up object types for the _Registration_ object, you must assign the fields you include in the [_Registration Grid Columns_ field][19] for the _Matching Registration_ control field to the applicable _Registration_ object types. Vault does not display field values to users for any fields you do not assign to the applicable object types. If you configure the [_Create Registrations and Objectives_ action][12] on the _Event_ object, you must assign the _Event_ field to the _Registration Objective_ object type. If you do not do this, the action will fail when run by users. ### Configuring the Regulated Category Object Layout {#rc-page-layout} You can insert a related object section to the _Regulated Category_ object for the _Regulated Category Attribute Impact_ object so users can see all _Regulated Category Attribute Impacts_ related to each _Regulated Category_. ## Populating Registration Items {#populating-records} You must ensure that the _Eligible for Impact Assessment_ field is populated appropriately on all relevant _Registration Items_ in your Vault. When users run actions on a source _Registration Item_ or _Event_ to conduct Local Impact Assessments, Vault compares that record to existing _Registration Items_ and identifies matches based on _Regulated Category Attribute Impacts_. Vault only evaluates existing _Registration Items_ if the _Eligible for Impact Assessment_ value is _Yes_. In addition, the following fields must be populated on all _Registration Items_ in your Vault in order for the Local Impact Assessment feature to perform correctly: * **Registration** (`parent_registration__v`): When Vault matches a source _Registration Item_ to an existing _Registration Item_, it identifies its parent _Registration_ as a potential match to the source _Registration Item_. * **Regulated Category** (`regulated_category__v`): When identifying matches, Vault evaluates all _Registration Items_ with the same _Regulated Category_.
### Bulk Updating Registration Items {#bulk-updating} To bulk update all _Registration Items_ in your Vault, we recommend either of the following options: * Use Vault Loader to update the fields on all _Registration Items_. * Configure a temporary workflow to update the fields on all _Registration Items_, then inactivate the workflow. ## Creating Registration Attribute Components {#creating-registration-attributes} You must create Registration Attribute components and link them to _Regulated Category Attribute Impacts_, which determine how Vault identifies _Registration_ matches when the [_Local Impact Assessment_ action][11] runs. If you link a Registration Attribute to a Relational Token with a defined Object Mapping, Vault populates the mapped fields on _Registration Items_ based on token resolution when the [_Generate Registration Data_ action][10] runs. See Defining Registration Attributes for more details. ## Creating Regulated Category Attribute Impacts {#creating-impacts} You must create _Regulated Category Attribute Impacts_ and relate them to pre-defined [Registration Attributes][5] to determine which fields Vault evaluates when matching a source _Registration Item_ to existing _Registration Items_. Vault evaluates existing _Registration Items_ with [_Eligible for Impact Assessment_ values][3] of _Yes_ and the same _Regulated Category_ as the _Regulated Category Attribute Impact_. To create a _Regulated Category Attribute Impact_: 1. Navigate to **Business Admin > Objects > Regulated Category Attribute Impacts**. 2. Click **Create**. 3. Enter a **Name** such as "Canada - Formulation" for an impact that applies to formulation changes in Canada. 4. Select a **Regulated Category Attribute Impact Type**. Select **Amendable** if this attribute requires an amendment to an existing registration. Select **Unique** if this attribute requires a new registration. If you have configured custom values for this picklist and select a custom value for this field, Vault will ignore this _Regulated Category Attribute Impact_ when running the _Local Impact Assessment_ job. 5. For **Registration Attribute**, enter the label of a [Registration Attribute][5] to identify the _Registration Item_ field this _Regulated Category Attribute Impact_ applies to. 6. Select a **Regulated Category** to restrict this _Regulated Category Attribute Impact_ to evaluate only _Registration Items_ with the same _Regulated Category_. 7. Click **Save**. ## Configuring Object Actions {#configuring-actions} Registration and Dossier Management Vaults include several asynchronous actions to support Local Impact Assessments: * [**Generate Registration Data**][10]: Available to configure on the _Registration Item_ and _Event_ objects, this action populates _Registration Item_ fields with the applicable values. When configured on the _Event_ object, this action generates data for all associated _Registration Items_. * [**Local Impact Assessment**][11]: Available to configure on the _Registration Item_ object, this action populates the _Matching Registration_, _Matching Registration Objective_, and _Regulatory Process Type_ fields. * [**Create Registration and Objective**][12]: Available to configure on the _Registration Item_ object, this action creates a new or relates an existing _Registration_ and _Registration Objective_ for the source _Registration Item_. * [**Create Registrations and Objectives**][12]: Available to configure on the _Event_ object, this action creates new or relates existing _Registrations_ and _Registration Objectives_ for all _Registration Items_ associated with the source _Event_. When running these actions, Vault only evaluates existing _Registration Items_ with [_Eligible for Impact Assessment_ values][3] of _Yes_. To configure these actions, you must first assign them to the applicable objects. Depending on your business needs, you can configure these actions as: * User actions on the object * Entry actions on the object's lifecycle state
### Generate Registration Data {#generate-registration-data}
Before configuring this action, you must link this action to a root Relational Token by defining a Relational Token Setting component . If you do not do this, the action will fail when run by users. The _Generate Registration Data_ action allows users to populate blank fields on _Registration Items_ based on Relational Tokens linked to the applicable [_Regulated Category Attribute Impacts_][8]. When the _Generate Registration Data_ action runs, Vault populates specified fields with no existing values on source _Registration Items_ based on Relational Token resolution. Vault only populates blank fields. If any specified field is already populated, Vault preserves the existing value. Vault also updates the _Generate Registration Data Job Status_ field to the current status of the job. When configuring the action on an _Event_ lifecycle state, you can populate the **VQL Criteria** field to define which _Registrations_ the action processes when it runs on an _Event_. For example, you can exclude _Registrations_ in completed or cancelled states. This field does not support `IN`, `LIKE`, or `ORDER BY` operators.
### Local Impact Assessment {#local-impact-assessment} The _Local Impact Assessment_ action allows users to identify any existing _Registrations_ and _Registration Objectives_ that match a source _Registration Item_ and determine if those matching _Registrations_ require an amendment. To do this, Vault identifies all _Registration Items_ in your Vault with [_Eligible for Impact Assessment_ values][3] of _Yes_ and matches fields based on the applicable [_Regulated Category Attribute Impacts_][8] to identify incomplete parent _Registration_ matches. Vault also identifies any amendment requirements based on the _Regulated Category Attribute Impact Type_ values (_Unique_ or _Amendable_) of the fields specified in the relevant _Regulated Category Attribute Impacts_. You can define [Local Impact Assessment Lifecycle Rules][21] so that Vault ignores matching _Registrations_ in specified lifecycle states when populating the _Matching Registration Objective_ control field. When the _Local Impact Assessment_ action runs, Vault does the following: * Populates the _Matching Registration_ and _Matching Registration Objective_ fields on the source _Registration Item_ based on the applicable scenario: * **Blank**: No matching _Registration_. * **[Registration]**: The label of the matching _Registration_. Users can click on this hyperlink to view the record's details. * **[Registration Objective]**: The label of the matching _Registration Objective_. Users can click on this hyperlink to view the record's details. * **Matching Registrations Found**: There are multiple existing matching _Registrations_. Users must click on this hyperlink value to see the _Search Registrations_ dialog, which lists all matches (each representing a _Registration Request_). * Populates the _Regulatory Process Type_ field on the source _Registration Item_ based on the applicable scenario: * **New**: No existing parent _Registrations_ match, and a new registration is required. There are zero existing _Registration Items_ with matching _Unique_ or _Amendable_ fields. * **Amendment**: One or more matching parent _Registration_ exists and requires an amendment. There is one or more existing _Registration Items_ with at least one matching field equal to _Amendable_. * **No Action Required**: One or more matching _Registrations_ exists and does not require an amendment. There is one existing _Registration Item_ with all matching fields equal to _Unique_ and _Amendable_ fields. * Creates _Registration Requests_ for every matching _Registration_. These records are represented in the _Search Registration_ dialog that users see when clicking on the _Matching Registrations Found_ hyperlink populated in the _Matching Registrations_ field. If Vault creates only one _Registration Request_, the _Is Selected_ field value on that record is _Yes_. If there are multiple _Registration Requests_, Vault does not populate that field until the user selects a _Registration_. If users rerun the _Local Impact Assessment_ on a _Registration Item_, Vault first deletes any _Registration Requests_ previously created for the source _Registration Item_ before creating new records. * Updates the _Local Impact Assessment Job Status_ field to the current status of the job. ### Create Registrations & Objectives {#create-registrations}
The _Create Registration and Objective_ and _Create Registrations and Objectives_ actions allow users to begin the appropriate registration process for a _Registration Item_ or all _Registration Items_ associated with an _Event_. When you configure either action as a [user action on a lifecycle state][20], you can optionally define which types of records Vault generates when users run the action. You can define [Local Impact Assessment Lifecycle Rules][21] so that Vault ignores matching _Registrations_ in specified lifecycle states when populating the _Matching Registration Objective_ control field. When the _Create Registration and Objective_ and _Create Registrations and Objectives_ actions run, Vault does the following: * Updates the _Create Registration and Obj Job Status_ field to the current status of the job. * If the _Regulatory Process Type_ is _New_, Vault searches for an active _Registration Item_ in the [applicable lifecycle states][21] with the same _Regulated Category_ and attributes. When applicable, Vault assigns the same _Registration Objective_. If multiple _Registration Items_ exist with the same [attributes][5], Vault assigns the _Registration Objective_ with the highest _Objective Number_. If multiple records have the same _Objective Number_, Vault assigns the most recently created record. * If there are no matching _Registration Objectives_, Vault creates and relates the applicable _Registrations_ based on the _Registration Requests_ created when the _Local Impact Assessment_ job ran. If the action runs as a user action and you've [configured object types for the user action][20], Vault generates records of the specified _Registration_ object type. Vault creates and relates records based on the values in the _Matching Registration_ and _Matching Registration Objective_ fields on the _Registration Items_:
If Matching Registration is… And Matching Registration Objective is… Outcome
Blank Blank Vault creates and relates a new parent Registration to a new Registration Objective and relates the source Registration Item to the Registration Objective.
[Registration] Blank Vault creates a new child Registration Objective and relates it to the matching parent Registration and the source Registration Item. The existing Registration is up-versioned.
[Registration] [Registration Objective] Vault relates the source Registration Item to the matching parent Registration and child Registration Objectives. The existing Registrations are up-versioned.
Matching Registrations Found Any No records are created. Because multiple matching Registrations were found, users must first select an applicable Registration.
If the user did not previously run the _Local Impact Assessment_ job to populate the _Matching Registrations_ and _Matching Registration Objective_ fields for a _Registration Item_, Vault creates and relates new _Registrations_. #### How to Configure the User Action {#create-how} When configuring the user action on an object's lifecycle state, you can specify which _Registration_ [object types][17] Vault generates when the action runs, allowing users to differentiate between generated registrations. To do this, select values for the following optional fields when configuring the action on specific lifecycle states: * **Registration Object Type**: Select the name of an active object type to specify which object type of _Registrations_ Vault generates when the action runs. * **Registration Objective Object Type**: Select the name of an active object type to specify which object type of _Registrations_ Vault generates when the action runs. * **VQL Criteria**: When configuring the action on an _Event_ lifecycle state, enter Criteria VQL to define which _Registration Items_ the action processes when the action runs on an _Event_. For example, you can exclude _Registration Items_ in completed or cancelled states. This field does not support `IN`, `LIKE`, or `ORDER BY` operators. For the selected object types, ensure you [assign all relevant fields][17], including the _Type_ field. For _Registration Objectives_, this also includes the _Registration_ and _Version_ fields. If you do not want Vault to assign a specific object type to generated _Registrations_, leave the applicable field blank. Vault will generate those records in the default _Registration_ object type. ## Defining Local Impact Assessment Lifecycle Rules {#lia-lc-rules} You can define Local Impact Assessment Lifecycle Rules component types to specify which _Registration_ lifecycle states Vault ignores when populating the [_Matching Registration Objective_ control field][19] when users run the _Local Impact Assessment_, _Create Registration and Objective_, and _Create Registrations and Objectives_ actions. For example, you can create a rule that specifies Vault ignores matching _Registration Objectives_ in _Cancelled_ state since the work on those objectives is complete.
To define lifecycle rules: 1. Navigate to **Admin > Configuration > Local Impact Assessment Lifecycle Rule**. 2. On the _All Local Impact Assessment Lifecycle Rules_ page, click **Create**. 3. Enter a unique **Name**. Vault adds the `__c` suffix to the _Name_ you enter. 4. Select a **Lifecycle**. This drop-down displays active lifecycles on the _Registration_ object. 5. Select a **Lifecycle State**. This drop-down displays active lifecycle states for the specified lifecycle. 6. Select a **Type** to specify that the rule applies to parent *Registrations*, child *Registration Objectives*, or both. When ignoring a parent *Registration*, Vault ignores all of its related child records. 7. Click **Save**. 8. Repeat these steps for each lifecycle state you want Vault to ignore. ## Configuring User Permissions {#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 following permissions : * For the _Registration_ object: _Create_ permission. Users must also have _Read_ permission on the fields you added as _Registration Grid Columns_ on the _Matching Registration_ control field. If any of the _Registration Grid Column_ fields are object references, users must also have _Read_ permission on those objects. * For the _Registration Item_ object: * _Edit_ permission on the _Create Registration and Obj Job Status_, _Generate Registration Data Job Status_, and _Local Impact Assessment Job Status_ fields. * _Read_ permission on all fields specified in [Registration Attribute components][5]. * To run the _Create Registration and Objective_ and _Create Registrations and Objectives_ actions, users must also have _Read_ permission on the _Regulated Category_ field. * For the _Registration Request_ object: _Edit_ permission, including _Edit_ permission on the _Is Selected_ field. * If your Vault utilizes DAC for objects or Atomic Security on the _Registration_ object, users can only see _Registration_ matches and _Registration_ fields they have permission to _Read_. ## Related Permissions {#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 Workflows: Create, Edit Ability to create and modify new object workflows.
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 Application: Vault Owner Actions: Vault Owner Actions: Vault Loader Ability to view and use the Loader tab.
Security Profile Application: Vault Owner Actions: Vault Owner Actions: Record Migration Ability to load object records (through Vault Loader or Vault API only) in a lifecycle state other than Starting State.
[2]: #configuring-objects [3]: #populating-records [4]: #bulk-updating [5]: #creating-registration-attributes [6]: #registration-attribute-fields [7]: #supported-field-types [8]: #creating-impacts [9]: #configuring-actions [10]: #generate-registration-data [11]: #local-impact-assessment [12]: #create-registrations [13]: #limitations [14]: #user-permissions [15]: #related-permissions [16]: #supported-fields [17]: #registration-object-types [18]: #ri-page-layout [19]: #control-fields [20]: #create-how [21]: #lia-lc-rules [22]: #object-mapping