# Error Management

{% hint style="info" %}
Behaviors listed on this page are a*utomatically handled by ROMA (Design + Content).*
{% endhint %}

## Inform users

*When the form cannot be saved due to wrong inputs from the user.*

* Alert Error (red) with number of errors + list of inputs in errors (in the form order) + anchor to each input
* The form stays in creation mode

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FonlU4BUblHZyzbWnxD5R%2Fformwitherror.svg?alt=media&#x26;token=3d16f396-713a-4391-b416-b2c13f6d2051" alt=""><figcaption><p>A form with errors</p></figcaption></figure>

{% hint style="info" %}
Error for empty fields is automatically managed, content can not be changed ("Required Field")&#x20;
{% endhint %}

{% hint style="info" %}
For Forms using "Save as draft", it is only possible to save valid values, even just as draft. Otherwise, for unvalid values, error management remains the same
{% endhint %}

## Users correct errors

*When the user tries to correct a field in error state after an unsuccessful save*

* `onBlur` Input in error state changes to default state
* `onChange` Input stays in default state **unless** there is a "front error" (invalid characters; ...). Then, the input changes back to error state

## Technical error

*When a technical error occurs while the user tries to save the form.*

* Snackbar with following content : \[*An error occurred on our end. Try refreshing the page*.]
* The form stays in creation mode

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FvNN0OafNG0ExjENQSQn8%2Fsnackbar.svg?alt=media&#x26;token=722bb26b-5bba-4780-8c46-587ba140b8ea" alt=""><figcaption></figcaption></figure>

Forms are one of the few cases where a snackbar informs users of a technical error, not a [empty state](https://design.mirakl.com/patterns/loading#loading-error). It allows to retry sending form without losing current page and its informations.

## <mark style="color:blue;">Frequently Asked Questions</mark>

> If my field already has a helptext but is in error when users tries to save the form : what should I do ?&#x20;

**A field can only have one helptext**. Thus, when an error occurs on a field that already had a helptext, the error state takes over it.&#x20;

> Can we notify users they made a mistake before they even try to save the form

We don't allow "*as-you-type*" error management. Always let users validate their form before notify errors. It will let them correct themselves before even trying to send form.

> How do we manage Error Management with a confirmation modale to a form ?&#x20;

Sometimes we add a confirmation modale to a form. It helps users to be more cautious about sensitive actions.\
In this case, Error Management (back and front errors) are both launched when user clicks on `Primary Button` of the modale.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FysG8l5inJb9QFGvTAEsL%2Ferror-modale.png?alt=media&#x26;token=15fef855-f061-4a94-aabb-6209ad61f607" alt=""><figcaption></figcaption></figure>

## Key Take Away

{% hint style="success" %} <mark style="color:green;">**Do**</mark>

* Inform and guide users. They should be able to understand by themselves how to correct their form.
* Use field component on their `Error Variant`
* Add an anchor to each imput for users to access directly from the alert
  {% endhint %}

{% hint style="danger" %} <mark style="color:red;">**Don't**</mark>

Custom Error management : it must remain the same to every form
{% endhint %}

{% hint style="info" %}
Learn more about [Error Management guidelines and content](https://design.mirakl.com/design/patterns/errors) through the plateform
{% endhint %}