> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/assistance/in-app-guidance/validators.md).

# Creating validators

Validators check what someone types into a form field in a business application, at the moment they type it, and record whether the entry matched the rule.

A validator is a set of rules attached to one form in a business application. It checks what someone types into a form field and tells them, on the spot, whether the entry matches the rule. It runs in the browser, layered over the application, so the application's own code and error messages stay untouched.

Inside a validator sits one validation for each field being checked. A validation is a single rule plus the hint the person filling in the form reads. The rule is either a pattern, generated from a plain-language description, or a check that the field is not left empty. One validator holds as many validations as the form needs, published together.

A validator also points at the form's existing submit button, called the completion button. That is how Userlane knows a form was sent, which makes it possible to report on entries as a submission.

<div align="left" data-with-frame="true"><figure><img src="https://259567114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF6bxg8i3T6U4vZ3k7PHi%2Fuploads%2FqReE7oJOgFETgdlH607q%2FValidators1.png?alt=media&#x26;token=c4d70b1e-203a-45a2-81cf-c8c423565b3e" alt="A form field with a validator hint shown beside it" width="470"><figcaption><p>A validator hint on a form field.</p></figcaption></figure></div>

## When to use a validator

A validator fits an input field where the expected format is not obvious, and the application says nothing useful about it. Common examples are reference codes, date formats, internal identifiers, and address fields with local rules. The hint appears before the person types, so the error never happens.

A validator also fits the case where nobody is certain a data quality problem exists. **Measure** mode records the result without showing anything, producing evidence before anyone changes how the form behaves.

## How validators work

A validator runs in one of three modes, ordered from least to most interruption for the person filling in the form.

<table><thead><tr><th width="118.23046875">Mode</th><th width="184.57421875">What it does</th><th width="242.7578125">What the person filling in the form sees</th><th>What gets recorded</th></tr></thead><tbody><tr><td><strong>Measure</strong></td><td>Runs every rule and records the result. Changes nothing on the page.</td><td>Nothing.</td><td>Whether each entry matched, and that the form was submitted.</td></tr><tr><td><strong>Visible</strong></td><td>Adds inline feedback on each field.</td><td>The hint when the field is selected, and a colored border after moving on.</td><td>The same as <strong>Measure</strong>.</td></tr><tr><td><strong>Warning</strong></td><td>Adds a message at the submit button when fields still do not match.</td><td>Everything <strong>Visible</strong> shows, plus a message listing the fields that need attention, with the choice to correct them or submit anyway.</td><td>The same as <strong>Visible</strong>, plus how often the message appeared and how often someone submitted anyway.</td></tr></tbody></table>

You choose the mode at creation and can change it later. Changing it keeps the history, so the record before and after stays comparable.

**Warning** mode never prevents a submission. That is deliberate: Userlane guides, and the decision stays with the organization running the application.

### What is checked, and what is recorded

The rule is evaluated in the browser. What the person typed is never sent to Userlane. Only the result is recorded: whether the entry matched, which validation checked it, and when.

Reporting shows how often entries matched, how often the warning message appeared, and how often someone submitted anyway, broken down per validation. The match rate also feeds the Risk dimension of HEART[^1].

## Create a validator

{% stepper %}
{% step %}

#### Open Validators in the Editor

Open the Editor[^2] on the application page that holds the form, then open **Validators**.
{% endstep %}

{% step %}

#### Choose the mode

Select **Create**. In **Create a new Validator**, choose the mode, then select **Create**.
{% endstep %}

{% step %}

#### Select the field to check

On the page, select the field the validator should check.
{% endstep %}

{% step %}

#### Describe the rule

In **Describe the rule to AI**, write in plain words what the entry has to follow. Select **Add field**, then select **Continue**. For writing or checking a pattern by hand, see [Regex patterns for input validation](/assistance/in-app-guidance/validators/regex-patterns-for-input-validation.md).
{% endstep %}

{% step %}

#### Record the completion button

Userlane asks for the button people press to submit the form, for example **Save** or **Submit**. Select that button on the page.
{% endstep %}

{% step %}

#### Finish the setup

The Editor panel opens on the left. Name the validator, set the language, and change the mode or the completion button if needed. Add any further fields to validate, then set the [audience](/administration/audiences.md) on the **Segmentation** tab.
{% endstep %}

{% step %}

#### Preview and publish

Preview the validator, save it, then publish. Publishing the validator publishes every validation inside it.
{% endstep %}
{% endstepper %}

{% hint style="success" %}
**Expected result.** The validator appears on the form for everyone it targets, in the mode selected, and starts producing a compliance record[^3] for every entry.
{% endhint %}

## Relevant articles

{% content-ref url="/pages/qR8g756lNxBfOkNQzq3W" %}
[Regex patterns for input validation](/assistance/in-app-guidance/validators/regex-patterns-for-input-validation.md)
{% endcontent-ref %}

{% content-ref url="/pages/1S0Ysrf45iMPMs4rp5yk" %}
[Creating guides](/assistance/in-app-guidance/creating-guides.md)
{% endcontent-ref %}

{% content-ref url="/pages/TBF4QYHDMWQghy26u8xI" %}
[HEART](/intelligence/heart.md)
{% endcontent-ref %}

{% content-ref url="/pages/BkK6BtMQAoCXdpgXSBa5" %}
[Targeting](/assistance/content-operations/targeting.md)
{% endcontent-ref %}

{% content-ref url="/pages/14ViydxzHwBkmZMnQj6h" %}
[AI features: what data is processed and where](/security-and-privacy/ai-features-what-data-is-processed-and-where.md)
{% endcontent-ref %}

## FAQ

<details>

<summary>Can a validator stop someone submitting a form?</summary>

No. A validator in **Warning** mode shows a message listing the fields that do not match, and the person can still submit the form.

</details>

<details>

<summary>Does Userlane see what people type into a validated field?</summary>

No. The rule is evaluated in the browser and only the result is recorded. The entered value is never sent to Userlane.

</details>

<details>

<summary>Can one validator cover several fields?</summary>

Yes. A validator holds one validation for each field being checked, and all of them are published together.

</details>

<details>

<summary>What is the difference between a validator and a guide step that checks input?</summary>

A validator is always present on the form and checks the field whenever anyone fills it in. A guide step checks input only while someone is following that guide.

</details>

<details>

<summary>Does Measure mode show anything to the person filling in the form?</summary>

No. **Measure** mode records whether entries matched and changes nothing on the page.

</details>

<details>

<summary>Can the mode be changed after a validator is published?</summary>

Yes. The mode can be changed at any time, and the record from before the change is kept.

</details>

[^1]: HEART is Userlane's five-dimension model for scoring how well an application works for the people using it, on a scale of 0 to 100.

[^2]: The Editor is the workspace where Userlane content is built, separate from the portal where content is targeted and analytics are viewed.

[^3]: A compliance record is what Userlane stores each time an entry is checked: whether it matched the rule, which validation checked it, and when.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.userlane.com/assistance/in-app-guidance/validators.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.