# Adding Custom Fields {% hint style="info" %} In older versions of Converia, custom fields are still referred to as EAV fields. {% endhint %} ### General Information Custom fields (formerly EAV fields) are additional fields that can query further information during participant registration, submission of contributions, and in personal data (C3). Typically, each custom field requires **a data field** and **two associated form references**. In total, you need **three entries** for a functioning additional field: one form reference in the frontend to display a fillable form field, and one form reference in the backend to retrieve the information in the backend. ## Creating a Custom Field (EAV Field) New *Custom Fields* can be created by adding an entry via *Add data field*.

**Name** The *Name* is used to uniquely identify and assign the Custom Field and the associated field references in the system. **Reference** The *Reference* depends on whether the Custom Field is intended for the registration or personal data (in this case: type = PERSON) or for the submission of contributions (in this case: type = PAPER). **Data type** Selecting the *Data type* determines what type of information is stored in the Custom Field. {% hint style="warning" %} It is important to select the correct *Data type*, otherwise the information in the additional field will not be saved correctly or at all. {% endhint %}

Type: PERSON	Type: PAPER	Custom Fields
Person - Numerical value (Integer)	Paper - Numerical value (Integer)	Select, checkbox, file (=Upload), Radio	Numerical value/ Selection
Person - Text single-line (Varchar)	Paper - Text single-line (Varchar)	TText (single line)	Short text (max. 250 char.)
Person - Text multi-line (Text)	Paper - Text multi-line (Text)	Text (multi line)	Text

{% hint style="danger" %} A file upload in the frontend registration (step personal data) is currently not implemented or possible! {% endhint %} ### Adding *Form references*

Adding Form references — Fig. 2: Adding *Form references*

Sobald das Feld angelegt wurde, fehlen noch die **Formularbezüge**. In der Regel ist immer ein Formularbezug im Backend (*BE Person* / *BE Paper*) nötig und ein Formularbezug im Frontend an der gewünschten Stelle. Für ein Zusatzfeld müssen also **zwei** identische Felder erstellt werde**n.** As soon as the field has been created, the **Form references** are still missing. As a rule, a form reference is always required in the backend (BE Person / BE Paper) and a form reference in the frontend at the desired location. **Two** identical fields must therefore be created for an additional field. ### Configuring form references

**Name of the field** For the sake of clarity, the field name should be the same as for the Custom field. In this case, it would be “Transport”. #### Displayed name**/** Description The *Displayed name* is always displayed above the additional field in the frontend, while the *Description* is displayed below. If the event is multilingual, the *Displayed name* and *Description* must be entered in all languages.

Fig. 4: The newly created custom field in the registration (frontend)

**Form** The **correct form** must be selected here. {% hint style="success" %} It is always advisable to start with the front-end form. The settings and view can then be conveniently checked there. If everything is as expected, the entries for the backend can be duplicated. {% endhint %} **Element type** When choosing the *element type*, consider the specific needs of your form and ensure it aligns with the intended functionality. Select the appropriate checkboxes to determine whether the field should be mandatory for the user and if it should be visible in the form. **Note:** The types "Headline" and "Paragraph" do not require a link in the backend form as they provide structure rather than data input. These only need a field in the frontend form to describe and divide other fields. After selecting the *element type*, ensure it is compatible with the chosen [**data type**](https://manual.converia.de/administration/zusatzfelder-anlegen#speicheradapter) or adjust it accordingly. **Element types: Exception for Headline and Paragraph** The field types *Headline* and *Paragraph* are not input fields but serve to describe and divide additional fields.

Fig. 5: Selecting the correct data field

*Headline* and *Paragraph* should only be a single entry on a form and should not have a field reference or data field assignment, as this may cause errors when saving. ## Linking to the Frontend Once the EAV field has been created with the field reference to the BE field, the link to the frontend must be established. To do this, go back to the EAV homepage by selecting *Back to list*. The previously created form can be accessed via the ⚙ (e.g., *BE Person*).

In this form, the field just created can be found. This entry can be duplicated. The duplicate (identified by the suffix *\_copy*) can be further edited. It is important that **the original field and the duplicate have the same content** to avoid distortions and misrepresentations in the system. The only part that is changed in the duplicate is the **form**. Here, the desired location in the frontend is selected, in this example *FE Registration step 3 participant details*.

**Possible locations for an additional field in the frontend are:** | Type: PERSON | Type: PAPER | | --------------------------------- | ---------------------------- | | Registration - Step personal data | Submission - step 1 general | | Submission - step 3 author data | Submission - step 2 abstract | | C3 - personal data | Session submission - step 1 | #### The completed Custom Field Once everything is correctly configured, the completed additional field appears in both the frontend and backend. In step 3 of the registration, it looks as follows:

Fig. 9: The completed Custom Field (registration)

In the backend, all custom fields of type PERSON can be found in the personal data under the tab ***Additional Fields***.

For the type PAPER, the additional fields can be found in the contribution details under the tab ***Configurable Fields***.

### Validators for Additional Fields So far, there are four validators for additional fields: 1. **File size** for file upload 2. **File type** for file upload 3. Number of **characters** for text fields 4. Number of **words** for text fields {% hint style="info" %} Validators can be created by our developers on request. {% endhint %}