# Configuring Registration Verification (RIM)

Registration verification ensures that users must complete workflow tasks to verify updates to registrations and registered details before Vault commits the changes to the impacted records. When configured, Vault can enforce registration verification as part of the [Managed Registered Details](/en/lr/43108/ ) process or when users edit registrations and registered details directly.



<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: <a href="/en/lr/71637/">Registration Verification </a> is only available on RIM Registrations Vaults.</p>
    </div>
  </div>
</div>



## Configuring Registration Data Verification {#verification}

Complete the steps below to enable registration data verification:

  1. Enable [system-managed naming](/en/lr/30986/ ) on all registered details objects. Ensure that your naming pattern doesn't exceed 128 characters or record creation could fail.
  2. Update the _Registration_ [object page layouts](/en/lr/26387/ ) to add a related object section for _Unverified Registration Data_. In the _Add Related Object Section_ dialog, add the following condition under _Filter Related List_: **Unverified Registration Data Type equals Unverified Data**.
  3. Optional: Set up either [Dynamic Access Control](/en/lr/33946/ ) or [Custom Sharing Rules](/en/lr/25494/ ) on the _Registration_ object. This allows you to use roles when you configure the workflow. You can also determine which roles can participate in the verification workflow on the **Application Settings** page.
  4. Optional: Set up a group of state types to map to target lifecycle states on the _Registration_ and most registered detail object lifecycles. Setting up state types lets you bypass verification in specified lifecycle states and prevents users from editing records with open verification workflow tasks. See [details about this step][6] below.
  5. Navigate to **Admin > Configuration > Workflows** and open the _Registration Data Verification_ workflow. You must configure this workflow before you can enable the feature. See [details about this step][7] below.
  6. Update permission sets for users or roles that will receive workflow tasks to add the _Object: Unverified Registration Data: Read_ permission. Ensure that users have _Read_ permission on both the _Unverified Data_ object type and the _Summary of Changes_ object type.
  7. Add a [user action](/en/lr/59885/#user-actions) to start the _Registration Data Verification_ workflow on all _Registration_ object lifecycle states that users could modify in the wizard. Adding this action enables Vault to assign the appropriate workflow tasks and send notifications. You can configure [atomic security](/en/lr/47850/#Atomic_Security_Actions) to prevent users from starting the workflow manually, although users may need to do this if an error occurs.
  8. Review your Vault's security configuration and ensure users have the appropriate [permissions][14] to work with this feature.
  9. Enable registration data verification. See [details about this step][10] below.

## Configuring State Types {#configuring-state-types}

Setting up custom state types allows you to specify the lifecycle states in which verification should occur. We recommend configuring a group of state types that are available to all lifecycles. Then, associate one lifecycle state to each of these state types on the _Registration_ object lifecycle and most registered details object lifecycles: State type configuration is not required for the deprecated _Registered Product Variant_ object (`registered_product_detail__rim`), nor is it required for the UDI-specific _Registered Device Identifier_ object (`registered_device_identifier__v`) if your organization does not work with devices.

We recommend configuring the following state types with the naming pattern "{State Name} -- Verification", for example:

  * _Approved - Verification_
  * _Pending Approval - Verification_
  * _Planned - Verification_

After you configuring and associating state types, choose the state types in which Vault should perform verification when you [enable data verification][10] on the **Application Settings** page. See [Managing Object State Types](/en/lr/56431/) for more information about creating state types and [Configuring Object Lifecycles](/en/lr/30683/#state-type) for more information about associating state types to object lifecycle states.

## Configuring the Registration Data Verification Workflow {#workflow-configuration}

RIM Registrations Vaults include the standard _Registration Data Verification_ workflow by default. The workflow includes a basic outline, but you must make the following updates in order to configure the feature fully:

  * For each [_Start_ step](/en/lr/33550/#start) participant control, decide whether to **Allow workflow task owners to select participants**, **Use roles as participants**, or **Use Vault user groups as participants**.
    * When using **Allow workflow task owners to select participants** or **Use Vault user groups as participants**, Vault ignores the optional _Select Verification Groups_ subsetting, if [enabled][10].
    * The **Allow workflow task owners to select participants** option has additional [limitations][13] in certain configurations.
  * Add the roles that users can select to receive workflow tasks.
  * Decide whether you want parallel review tasks or sequential review tasks for different roles.
  * Decide if a single user must complete tasks or if every user in the group must respond.
  * Decide whether to [short-circuit the workflow](/en/lr/33550/#short-circuit) if one user rejects a change.
  * Include two system action steps in the workflow to align with accepted or rejected outcomes. These steps determine whether Vault initiates the job to add or update registrations and registered details at the conclusion of the workflow.

In addition to the updates above, you may further [configure](/en/lr/33550/ ) the workflow to meet your organization's business requirements. See [additional details][13] on configuration parameters.



<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: Registration verification does not apply to additional workflows or lifecycle state change user actions that you configure on the <em>Registration</em> or registered details object lifecycles. Carefully examine all workflows and lifecycle state change user or entry actions on these object lifecycles so that users cannot bypass verification.</p>
    </div>
  </div>
</div>



### Configuring Multi-Record Registration Verification {#multi-record-redirect}
In Vaults created on or before 22R3, the _Registration Data Verification_ workflow is configured for single records, meaning that for each impacted _Registration_ record, Vault generates a verification task.

As of 23R1, this workflow leverages Vault's multi-record workflow capabilities to allow users to verify and apply a verdict on up to 100 _Registration_ and registered details records within the same workflow task. If the workflow includes more than 100 records, Vault creates multiple tasks for each group of 100 records.

To update the workflow to leverage Vault's multi-record workflow capabilities:

  1. Navigate to **Admin > Configurations > Workflows > Registration Data Verification**.
  2. Delete the **Send Rejection Notification** and **Send Accepted Notification Notification** steps. This feature includes notifications, and therefore these steps and their related notifications are no longer in use.
  3. Update the **Delete Unverified and Rejected Data** and **Commit Registration Data** System Action steps' **Next Steps** to **End**. This closes the workflow logic.
  4. In the **Verify Registration Data** Task step, remove **Registration Verification Redirect** from the **Custom Action** drop-down.
  5. In the workflow's **Options** section, convert the workflow to multi-record by deselecting the **Use workflow for single object record** checkbox.
  6. In the workflow's **Details** section, click **Make configuration active**.

### Workflow Configuration Considerations & Limitations {#configuration-considerations-and-limitations}

When configuring the _Registration Data Verification_ workflow, ensure that:

* Workflows only allow users to update fields in lifecycle states for which Vault does not enforce verification.
  * For lifecycle states in which Vault enforces verification, do not include user actions or workflows that allow users to manually move records to new lifecycle states. The _Registration_ or registered details record's **Edit & Verify** option allows users to move records to new lifecycle states instead.
* Workflow tasks are required. Vault requires the verification step to be complete, even when the **Task Requirement** setting is configured as optional.
* Verdicts are configured such that the data is clearly accepted or rejected. Vault ignores any other verdict.
* Workflow task steps do not include [variables](/en/lr/33550/#variables) or [variable controls](/en/lr/33550/#variable-control), or prompts for fields, such as due date fields. These are not included in the dialog when Vault initiates the wizard.

Additionally:
* When the *Start* step's **Allow workflow task owners to select participants** option is configured:
  * The first task following the *Start* step should be configured such that Vault assigns the task to the workflow owner. Otherwise, Vault cannot determine initial participants for the workflow and displays an error to wizard users.
  * Vault hides the *Registration* or registered details record's **Edit & Verify** button.
* The standard workflow's _Commit Registration Data_ (`commit_registration_data__c`) and _Delete Unverified and Rejected Data_ (`delete_unverified_and_rejected_data__c`) steps only reference the verdicts applied during any previous task step with the name `verify_registration_data__c`. When the workflow has additional task and decision steps to verify registration data, these tasks should be distinct (with different `name__c` values), and the `verify_registration_data__c` task should always precede the last decision step in the workflow.

## Enabling Registration Verification {#enable-verification}

To enable registration verification, navigate to **Admin > Settings > Application Settings** and select **Send manage registered details data for verification**. After you set this checkbox, you can also enable additional options to fit your business processes:

* In the **Verification State Types** drop-down, choose specific _Registration_ or registered details object lifecycle state types in which Vault should run the verification workflow. 
  * When an object lifecycle does not include the requisite state type [configuration][6] for all relevant objects, you cannot select any state types.
  * For any state types that you don't select, Vault makes changes immediately after users run the Manage Registered Details wizard or edit registration and registered details, without sending proposed changes for verification. 
  * When this setting is disabled, Vault enforces verification for all state types.
* In the **Select Verification Groups** drop-down, choose which groups can participate in the verification workflow. 
  * When the workflow is configured with the _Allow workflow task owners to select participants_ or _Use Vault user group as participants options_, Vault ignores this setting.
  * When this setting is disabled, Vault uses object record sharing settings to determine participation.

## Related Permissions {#permissions}

Users must be assigned a security profile with _Read_ permission for the _Unverified Registration Data_ object's _Unverified Data_ object type.


 [6]: #configuring-state-types
 [7]: #workflow-configuration
 [10]: #enable-verification
 [11]: #multi-record-redirect
 [12]: #single-record-redirect
 [13]: #configuration-considerations-and-limitations
 [14]: #permissions