# Configuring Reference Constraints
When you create a field that results in a document reference, object reference, or parent relationship, you can also constrain the available records. You can set up either static or dynamic reference constraints on parent and reference fields.
## Static Reference Constraints
Static reference constraints allow you to apply a constraint on a reference field with a defined value during configuration. This restricts the list of available records in a referenced field based on the defined value.
## Dynamic Reference Constraints
Dynamic reference constraints allow you to apply a constraint on reference fields based on values that aren't defined until a user provides input. This restricts the list of available records in a referenced field based on a controlling field. Object references support dynamic constraints by object reference or picklist fields, while document references only support dynamic constraints by object reference fields. When you apply a dynamic reference constraint, Vault displays text in the referenced field specifying the dependency on the controlling field and does not allow you to enter a value.
You can only set up dynamic reference constraints using a VQL query. The constraint criteria may contain a simple query condition or complex relationship query condition. Additionally, the criteria VQL for dynamic reference constraints must contain the token for a valid configuration.
## How to Constrain Related Records {#constrain}
To set up a constraint:
1. Open an existing document reference, object reference, or parent field in edit mode. You cannot filter when initially creating the field.
2. Scroll down to the **Constrain Referenced Document** or **Constrain Records in Referenced Object** section.
3. Use a VQL query to define the conditions in the **Criteria VQL** field.
4. Optional: Click **Validate** to confirm if your criteria VQL is valid.
5. Optional: Click **Preview** to see how field selection will look once your filter rule is in place. This option is not available for dynamic constraints.
6. Click **Save**.
### Limitations
When you set up a constraint, Vault only applies filters going forward. If an object record is already saved with now unavailable values, Vault does not update that record. Additionally, Vault does not apply reference constraints to object records created in migration mode. However, if a user later edits a controlled or controlling field in the record, the user will need to select a valid option.
When a document reference field links to the latest version and has the `status__v = STEADYSTATE()` reference constraint, up-versioning the referenced document will violate the constraint.
For a document reference field bound to the latest steady state version, a document is selectable if any previous steady state version matches the reference constraint criteria. However, after saving, the field displays the document's latest steady state version even if that version does not match the criteria. For example, if a document has a past steady state version of 1.0 and latest steady state version of 1.2, the document is selectable for a constraint of `minor_version_number__v = 0`. The saved field will then display the latest steady state version, 1.2.
Note: Use caution when editing pre-configured constraints on standard reference fields. Vault does not display a warning message when editing default constraints and you may inadvertently break existing configurations.
### Example: Static Reference Constraint on Relationship Records
RIM Vaults use an object called _Controlled Vocabularies_ to represent various entities, including _Species_, _Application Types_, and _Submission Types_. One of the fields on the object is _Type_, which identifies whether the record is a species, application type, etc. Since these records all share similar fields (_Name_, _Abbreviation_, _Health Authority Code_, _Health Authority Source_, etc.), using the single object is more efficient. However, filtering records by _Type_ still matters. Organizations don't want users to accidentally associate a _Submission Type_ record with an application. To facilitate this, an Admin can set up filters on actual object reference fields. The _Application_ object includes an object field called _Application Type_, pointing to the _Controlled Vocabularies_ object. That field is filtered to only show records where the _Type_ value is _Application Type_.
`controlled_vocabulary_type__rim = 'application_type__rim'`
### Example: Static Reference Constraint on Parent Relationship Records
Promomats vaults provide the _Product_ object to maintain records of various products used for promotional and marketing purposes. One of the fields in the _Product_ object is _Therapeutic Area_, which identifies whether the record belongs to a specific area of study such as oncology, neurology, pediatrics, etc. The custom _Marketing Campaign_ object is a related child object of _Product_. When users create a new _Marketing Campaign_, an organization may want to only allow creating marketing campaigns around products focused specifically on neurology. To facilitate this, an Admin can set up filters on the _Product_ parent field within _Marketing Campaign_ to only show records where the _Therapeutic Area_ value is _Neurology_.
`therapeutic_area__c = 'neurology__c'`
### Example: Static Reference Constraint on Document State and Type {#static-on-doc-state-type}
In some PromoMats Vaults, the _Product_ object contains a _Logo_ document reference field that points to the document with the product logo. To ensure users can only select product logos when editing the _Logo_ field, an Admin could create a _Logo File_ document type and add a filter to the _Logo_ field that excludes all other document types. Additionally, setting the _Document Version Reference_ to _Latest version_ may include newer versions of the logo that aren't yet approved for public use. To prevent users selecting unapproved versions of the logo, an Admin could set up filters on the _Logo_ field to ensure that users can only select from documents in the _Steady_ state.
`TONAME(type__v) = 'logo_file__c' AND status__v = STEADYSTATE()`
### Example: Dynamic Reference Constraint on Relationship Records
In some Promomats Vaults, the _Marketing Campaign_ object may reference the _Country_ and _Region_ fields to identify where the campaign will take place. To create a more relevant list of countries for a user to choose from, an Admin can apply a dynamic constraint on the _Country_ field so the list of records are constrained by region the user selects. For example, if a user selects the Europe region, the _Country_ field only displays countries in the European region. See details about dynamic reference constraint queries.
`region__v = {{this.region__v}}`
### Example: Dynamic Reference Constraint on Many-to-Many Relationships
Some Promomats Vaults use the _Survey_ object to maintain records of survey data used to gather information. This object may reference the _Product_ and _Therapeutic Area_ objects, which identifies the information the survey data was collected for. If a relational object is used to join the references between _Product_ and _Therapeutic Area_, an Admin can apply a dynamic reference constraint on the _Product_ field in the _Survey_ object so the list of product records are constrained by the selected _Therapeutic Area_. This is especially useful for objects with various records with several references. See details about dynamic reference constraint queries.
`therapeutic_area__c = {{this.therapeutic_area__c}}`
### Example: Dynamic Reference Constraint on Documents
In the [static example][1] of a _Logo_ field, users would still see _Steady_ state _Logo File_ type documents for products other than the one being configured. To avoid this, an Admin could use a dynamic filter to exclude documents where the _Product_ field value does not match the current _Product_ object record. See details about dynamic reference constraint queries.
`TONAME(type__v) = 'logo__c' AND status__v = STEADYSTATE() AND product__v = {{this.id}}`
If a document reference field uses the _Latest steady state version_, you will get a warning when you use the VQL query `status__v`. The document reference field will filter to display only documents with a steady state (_Approved_, _Approved for Use_, etc.). Therefore, using a constraint on the status will return no results.
The reference constraint may behave unexpectedly if all of the following conditions are met:
1. The document has more than one steady state version
2. These steady state versions have different document metadata
3. The constraint is based on this document metadata
Users may be able to select an invalid document if a reference constraint is used when all conditions occur at once. This problem can happen because when a user selects a document in this situation, the latest steady state may not meet the constraint's criteria while an older steady state does meet the criteria.
[1]: #static-on-doc-state-type