# Fields

> Create and configure fields in the IS Tools data model editor. Set type, mandatory, unique, and delete constraint. Includes linked drop-down configuration.

[Application configuration](application_configuration.md) > [Data model editor](data_model_editor.md) > Fields

A field in a table specifies the type of data that can be stored in all records of the same table. For instance, the table called _"Contacts"_ may define fields like _"Last name"_, _"Mobile number"_ and _"Date of birth"_, where data of the type [Text](field_types.md#_text), [Number](field_types.md#_number) and [Date](field_types.md#_date) will be stored, respectively. In other words, data is arranged in fields, which correspond to columns in a [Table](tables.md). Each field is configured by an application administrator.

> **Tip:**
> 
> If you want to see and test your fields in a quick way, select the table they belong to, and click the ![OpenTableRecords](_images/OpenTableRecords.png) **Open table records** icon, to open up an administrative form where you can manage all records and fields instead of using an [application form](application_forms.md).

The **Data model editor** allows the application administrator to perform the following actions related to fields:

## Create a field

Select the table in the **Tables** tab, then click the ![BlackPlusIcon](_images/BlackPlusIcon.png) icon in the **Fields** tab. By default, a new field is named _"New field n"_ (where _"n"_ is a progressive number). Type a new name in the currently selected line of the **Name** column (field names must be unique within the same table).

Then, select the [type of field](field_types.md) you need in the next column.

Other settings are:

-   **List/Parent table**:

    -   For [Drop-down](field_types.md#%3Cem%3Edrop_down) fields, this setting must be used to select an existing Read how to [List](lists.md#_create_a_list_and_items) (i.e., the list of items shown to the users in application forms) and associate it to the Drop-down field. The same list may be shared by multiple Drop-down fields, if desired (e.g., a list with values \_"Yes" and _"No"_ can be associated to many Drop-downs).

    -   For [Relation](field_types.md#%3Cem%3Erelation) fields, this setting must be used to choose the table with which the current table will have a relation; for example, the Relation field \_"Main order" is created for the table _"Suborder"_, to have a relation with the table _"Order"_ chosen as parent table, meaning that a suborder will belong to an order.

-   **Mandatory**: Ticking this checkbox, forces the user to enter a value in this field when records are created or edited; i.e., the field cannot be stored as empty. This setting is not available for fields of type **Checkbox** and **File**.

    > **Note:**
    > 
    > Mandatory fields are also mandatory in Imports, and they are automatically added when creating an [import configuration](import_templates.md) of type **INSERT**. An import Excel file that lacks a value for a mandatory field will fail.

    > **Note:**
    > 
    > It is possible to set a field as **Mandatory** even if a table already has records with no data on this field, but be aware that it will not be possible for users to save these records until a value is set.

-   **Unique**: Ticking this checkbox will ensure that the system will verify that the value entered in the field of a record is unique with respect to the same field in other records of the same table (either during its creation or subsequent editing). However, to leave the field with no value (i.e., empty) is allowed. This setting is not available for fields of type [File](field_types.md#_file) and [Note](field_types.md#_note).

    > **Note:**
    > 
    > This setting is not applied retroactively. If two or more records already have the same value in the same field when the field is set to unique, these values will remain unchanged (and therefore non-unique). The uniqueness of a field is verified and indicated by the system with a pop-up message, only when the value of the field is about to be saved in the application form.
    > 
    > Unique fields must also have a unique value in imports. An Excel [import file](prepare_import_run.md) that contains duplicate values for a field set as unique will fail, i.e., will not insert the duplicate and will indicate this as a remark/warning in the import log.

-   **On delete**: For [Relation](field_types.md#relation) fields, this setting offers three distinct options:

    -   **Clear**: Lets you delete the parent record even if relationships exist, leading to orphan records (replaces the previous Null checkbox feature).

    -   **Restricted delete**: Prevents the parent record from being deleted if relationships exist. For example, having a Relation field with this checkbox ticked, from the Table _"Student"_ towards the Table _"Teacher"_, will make it impossible for users to delete Teachers that have Students, displaying the warning pop-up _"Cannot delete record, child record exists"_.

        > **Tip:**
        > 
        > You may use **Restricted delete** together with **Mandatory**, in case you want to force users to always have a Parent record associated the Child record. This way, it wouldn’t be possible to delete the Parent record nor to save an empty the Relation field of the Child record.

    -   **Cascade delete**: Automatically deletes all child records when the parent record is deleted.

        > **Caution:**
        > 
        > Records removed via ‘Cascade delete’ cannot currently be viewed in the [Activity log](activity_log.md) form once deleted.

-   **Groups**: If not set, the default group will be assigned. Create more [groups](field_groups.md) if necessary.

There are more properties that are initially hidden, but can be shown by clicking on the ![NDMEhiddenSettings](_images/NDMEhiddenSettings.png) icon found at the left top of the **Name** column:

-   **Id**.

-   **Description**: A text may be typed to explain the purpose of the field.

-   **Table**. The table it belongs to. Cannot be edited.

-   **Filter by**: In case you need to restrict the data displayed in [Drop-down](#_link_a_drop_down_field) or [Relation](#_link_a_relation_field) fields.

-   **Read log**: Check this box to keep a history of who see this field, where and when, via the [Extended logs](extended_logs.md) form.

Note that unsaved items are indicated with an asterisk (\*) at the left of each field with changes. These characters will disappear after clicking the **Save** button.

> **Tip:**
> 
> Clicking the ![UsageReport](_images/UsageReport.png) **Field usage report** icon, located at the top of the **Fields** section, displays a report of all forms, imports, reports and rules using the currently selected field. This is useful, for instance, to obtain information about into which forms a field has been added, in case it is meant to be deleted, because the boxes displaying this field must be removed from all forms, before the field itself can be removed from the data model.

> **Tip:**
> 
> To be able to quickly find certain fields, use the filter by hovering over the heading of the **Name** column, and click on the ![NDMEfilter](_images/NDMEfilter.png) icon. It is also possible to filter on other columns.

## Edit a field

To rename a field, select the table in the **Tables** column in order to display all its fields in the **Fields** column. Double-click the current name of the field and type a new name (field names must be unique within the same table). Save.

To edit a field setting, select it, change its properties and save.

> **Note:**
> 
> The field type cannot be edited. If the wrong field type has been saved, the field must be deleted and a new one created. Also, the **List / Parent table** setting of a [Relation](field_types.md#_relation) field type cannot be changed once the table contains records.

When a field is edited, note that unsaved items are indicated by and asterisk (\*) next to them. This provides a visual feedback, informing that there are pending changes that need to be saved. At this point, navigating away from the current form will discard the pending changes. Once the changes have been saved (by clicking the ![SaveAll3gIcon](_images/SaveAll3gIcon.png) icon), they cannot be undone (except by manual editing).

## Delete a field

> **Tip:**
> 
> Before attempting to delete a field, we recommend that you check how and where it is used in the application. For that, click the ![UsageReport](_images/UsageReport.png) **Field usage report** icon in the **Fields** toolbar.

To delete a field, select it and click the ![DeleteForm](_images/DeleteForm.png) icon. This operation remains pending until you save the form:

-   If the field is used anywhere in the application (excluding [private filters](record_filter.md#_create_a_custom_filter)), deletion will not proceed until you remove the field from there.

-   If the field only contains data, you will be required to type the field name in a warning window to perform the deletion. The **Record update time** will not be affected.

Note that the action and time of deletion will be registered in the [Activity log](activity_log.md) for audit reasons.

## Link a Drop-down field

It is possible to restrict or change the display of values in a [Drop-down](field_types.md#dropdown) field, depending on the value selected in another Drop-down list placed in the same application form. For instance, if a user selects the value _"Europe"_ in the Drop-down called "_Region_", the next Drop-down called "_Country_" will only display values like "_Sweden_", "_France_", etc. But if the user selects the region "_Asia_", then the countries will be "_China_", "_Japan_", etc.

![LinkedListsExample thumb](_images/LinkedListsExample_thumb.png)

This functionality is known as Linked Drop-downs or Linked Lists and is configured as follows:

1.  Make sure the Drop-downs you want to link:  

    1.  Have been created in the same table.

    2.  Have selected a [List](lists.md) (which preferably have a complete list of values).

    3.  Are saved.

    As in the example above, the Drop-down "_Region_" is associated to the "_List of regions_", which contains the items "_Europe_" and "_Asia_". In the same way, "_Country_" is assigned to "_List of countries_", containing "_Sweden_", "_France_", "_China_" and "_Japan_".

2.  Relate the Drop-down fields: In the **Fields** tab, select the Drop-down that you want to subordinate and edit it by choosing a parent Drop-down (i.e., the one that will control it) in the **Filter by** setting; e.g., "_Region_" would be chosen for "_Country_", since a country depends on its region.

3.  Define the Parent items: In the **Lists** tab, select the list associated to the parent Drop-down (in the current example, "_List of regions_" would be selected), and edit its items, one by one, changing its **Type** (originally called "_List item_") to "_Parent item_"; e.g., "_Europe_" is selected and edited to be Parent item as **Type**. Same for "_Asia_". Save.

4.  Relate the list items: In the **Lists** tab, select the List associated to the depending Drop-down (in the current example, "_List of countries_" would be selected), then select those items (use Ctrl+click, or Shift+click) that will be depending by a specific parent, and click on the ![AssignParents](_images/AssignParents.png) icon to assign parent; e.g., the items "_Sweden_" and "_France_" would be selected and assigned to the parent "_Europe_".

> **Note:**
> 
> More than two Drop-downs can be linked in a chain and/or sharing master Drop-downs, e.g., ![LinkedListsChain](_images/LinkedListsChain.png) or ![LinkedListsSharedMaster](_images/LinkedListsSharedMaster.png) respectively.

## Link a relation field

It is possible to restrict or change the display of values in a relation field, depending on the value selected in a previous relation field, placed in the same application form of the table where these two relations were created. For instance, a user creating a Purchase order, selects the record "_Sweden_" in the relation box called "_Country_", and the next relation box called "_City_" will only display records like "_Stockholm_" and "_Gothenburg_". But if the user selects the country _"USA"_, then the cities shown will be "_New York_" and "_Los Angeles_", etc.

This functionality is known as Linked relations, and differs from the Linked Drop-downs functionality in that the values selected by the user are not items created by the administrator, but really are records that belong to tables related to each other, entered in application forms.

Follow these steps to link [Relation](field_types.md#_relation) fields:

1.  Make sure you have three tables (see the tip box below for cases with one or two tables), with the following characteristics:

    1.  The first table, represents the first relation box that will control the subsequent ones. As in the previous example, this table is "_Country_".

    2.  The second table, represents the second relation box, of which values will depend on the previous relation selected. This table must have a **Relation** field which **Parent table** is the first table. For instance, this table is "_City_" with a relation field pointing to "_Country_".

    3.  The third table, which is the main table of the form where the two linked relations are displayed to the users. Therefore, this table must have **Relation** fields pointing to the other tables. For instance, this table is _"Purchase Order"_, with two relation fields: one pointing to _"Country"_ and the other pointing to _"City"_.  
        ![LinkedRelationsDME thumb](_images/LinkedRelationsDME_thumb.png)

2.  Edit the second relation field of the third table, by setting the **Filter by** box to the option where both its parent tables coincide in those records which the current selected relation field will be controlled by. For instance, in the table "_Purchase Order_", select the relation field "_City_" and edit the above setting to "_City of parent record = Country_". This means that the field "_City_" depends on the field "_Country_" in any form using the "_Purchase Order_" table.

    > **Note:**
    > 
    > A relation field can also be self-referenced, i.e., pointing to the same table the Relation field is created from.
    > 
    > Example 1: The table "_Project_" may have a "_Manager_"-"_Employee_" linked relation structure, where both relation fields have "_Personnel_" as parent table, while "_Personnel_" has the relation field "_Manager_" pointing to itself. In this case, note that only these two tables are needed, since "_Personnel_" will be used not only to create managers in one application form, but also used to create employees in another (choosing its manager).
    > 
    > Example 2: A single table "_Person_" may have multiple relations to itself to be able to link to a "_Parent_" and a "_Sibling_". Ask the IS Tools support team for more detailed information.

3.  Create the values (records) that the relation field boxes will display:

    1.  In a form of the first table, create the necessary records; e.g., the form "_Country_" must have two records: "_Sweden_" and "_USA_".

    2.  In a form of the second table, create the necessary records and select their proper relations; e.g., the form "_City_" must have the records "_Stockholm_", "_Gothenburg_", "_New York_" and "_Los Angeles_", where the first two will select "_Sweden_" in their "_Country_" relation box, while the second two will select "_USA_" in their "_Country_" relation box.

4.  Create a form of the third table, where the two linked relations are displayed and ready to be edited and saved; e.g., the "_Purchase Order_" form, showing, amongst other fields, the "_Country_" and the "_City_" relation fields.