# Configuring Statement Validation (Veeva Claims)

[Veeva Claims](/en/lr/54331/) provides users with the ability to automatically check the full text content of a claim statement against a list of flagged words and phrases when you create claims statements. Certain words or phrases are "high risk" when used in product statements and need to be "flagged". Usage of such words or phrases in statements may leave consumer goods organizations exposed to legal and regulatory risks.

Depending on your configuration, Vault checks either the _Statement_ in each _Statement_ or _Claim_ against the list of Admin-defined _Flagged Words or Phrases_, but the process will not check both objects. Based on the results, Vault populates the _Statement Validation Status_ field on each applicable record. Vault also creates relationships between the _Flagged Words or Phrases_ and the matching _Statements_ or _Claims_. These relationships allow you to see which problematic words or phrases are found in each claim. If your Vault includes a [statement library](/en/lr/54344/#statements), Vault validates text on _Statements_ only because _Claims_ are created from _Statements_.

Your organization can maintain its own list of flagged or prohibited words. You can also use entry criteria to enforce policies around limitations of use of such language in the claim statements. Statement validation is available in all Veeva Claims Vaults, but you must define _Flagged Words or Phrases_ so that Vault knows which terms to check for statement validation.

The _Statement_ and _Claim_ objects include the following fields to support Statement Validation:

* **Statement Validation Required?** (`validation_required__v`): This field controls whether or not Vault will validate the claim statement.
* **Statement Validation Status** (`validate__v`): This field indicates the result of validation. See the [list of statuses.](/en/lr/55515/#status) This field is not editable.

## Configuration Overview {#overview}

Configuring your Vault to use Statement Validation involves the following steps:

1. [Define flagged words and phrases][1]
2. [Enforce statement validation][2]
3. [Configure user permissions][3]

<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>: Depending on your Vault’s creation date and which features are currently enabled and configured, some of the steps described in this article may be unavailable or already complete in your Vault.</p>
    </div>
  </div>
</div>



## Defining Flagged Words & Phrases {#define}

To define a word or phrase for statement validation, you must create the applicable _Flagged Words or Phrases_. To do this:

1. Navigate to **Business Admin > Objects > Flagged Words or Phrases**.
2. Click **Create**.
3. Enter the **Flagged Word or Phrase**, for example, "treat" or "cure". This is the value that Vault will match within statements on _Statements_ or _Claims_. This field is limited to 1,500 characters and is not case-sensitive.
4. Enter a **Reason** why this word or phrase is flagged. This reason appear to users when validating statements. This field is limited to 1,500 characters.
5. Enter **Alternative Suggestions**. These suggestions appear to users when validating statements.
6. Optional: Update the **Status** to **Inactive**. By default, new records are active. If you do not want it to become effective immediately, you can make it inactive.
7. Click **Save**. To create another flagged word or phrase, click **Save + Create**.

## Enforcing Statement Validation on Statements or Claims {#enforce}

When your lifecycle configuration includes [entry criteria](/en/lr/59885/), Vault checks a record before allowing it to enter a specific state. You can ensure that claims with high-risk statements are not approved using entry criteria. For example, you can create an entry criteria on the _Approved_ state of the _Claims Lifecycle_ to check that _Statement Validation Status_ equals _Validated. No Prohibited Word Found_ before allowing a record to enter _Approved_ state. For Vaults using a statement library, you can enforce the same entry criteria in the _Statement Lifecycle_.

<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>: Entry criteria prevent records from entering a specific lifecycle state. They have no effect on records that are already in a given state. In the above example, no invalid records could enter <em>Approved</em> state, but there may already be records in that state.</p>
    </div>
  </div>
</div>



## Configuring User Permissions {#user-perm}

You must ensure users have the appropriate read and create [permissions](/en/lr/22824/) to access the appropriate objects and object fields in addition to the permissions outlined below:

* _Read_ permission on the _Claim Prohibit Join_, _Flagged Words or Phrases_, and _Statement Prohibit Join_ objects.
* _Create_ and _Edit_ permission on the _Claim_ and _Statement_ objects.

## 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](/en/lr/22824/):

<table>
  <tr>
    <th><strong>Type</strong></th>
    <th><strong>Permission</strong></th>
    <th><strong>Controls</strong></th>
  </tr>
  <tr>
    <td>Security Profile</td>
    <td>Admin: Configuration: Object Lifecycles: Edit</td>
    <td>Ability to modify object lifecycles in order to set up entry criteria.</td>
  </tr>
  <tr>
  <tr>
    <td>Security Profile</td>
    <td>Admin: Security: Permission Sets: Edit</td>
    <td>Ability to modify permission sets for users.</td>
  </tr>
    <td>Security Profile</td>
    <td>Objects: Claim: Create, Edit</td>
    <td>Ability to create and modify <em>Claims</em>.</td>
  </tr>
  <tr>
    <td>Security Profile</td>
    <td>Objects: Claim Prohibit Join: Read</td>
    <td>Ability to see details for a claim's related <em>Flagged Words or Phrases</em>; you do not need <em>Create</em>, <em>Edit</em>, or <em>Delete</em> permission on this object because those actions happen automatically through the <em>System</em> user.</td>
  </tr>
    <tr>
    <td>Security Profile</td>
    <td>Objects: Flagged Words or Phrases: Create, Edit, Delete</td>
    <td>Ability to make changes to <em>Flagged Words or Phrases</em>.</td>
  </tr>
  <tr>
    <td>Security Profile</td>
    <td>Objects: Statement: Create, Edit</td>
    <td>Ability to create and modify <em>Statements</em>.</td>
  </tr>
  <tr>
    <td>Security Profile</td>
    <td>Objects: Statement Prohibit Join: Read</td>
    <td>Ability to see details for a statement's related <em>Flagged Words or Phrases</em>; you do not need <em>Create</em>, <em>Edit</em>, or <em>Delete</em> permission on this object because those actions happen automatically through the <em>System</em> user.</td>
  </tr>
</table>

[1]: #define
[2]: #enforce
[3]: #user-perm