> For the complete documentation index, see [llms.txt](https://docs.ninox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ninox.com/builder-hub/design-your-app/add-and-edit-data-fields-in-your-tables/all-data-fields/shared-field-settings.md).

# Shared field settings

Review the settings that Ninox data fields have in common.

Many data field types share the same settings. Others include options that depend on the field type.\
Some settings, like the visibility, affect the table structure. Others only change how the field appears in the form.

Ninox groups field options by where they apply:

* **Everywhere**: applies globally to this field across all views and forms.\
  These setting are bound to the server. Because of that they apply also if no user interface exists like during the execution of API requests or server side logic.
* **On the form**: applies only to this field in the current form view.\
  These setting need the user interface and the current form to apply.

#### Many data fields include these common settings:

* An description of the field type
* <i class="fa-book-open">:book-open:</i> links to the Ninox documentation
* <i class="fa-trash-can">:trash-can:</i> lets you delete the field

#### Everywhere

* **Label**: the name users see on the form
* **Internal name**: the technical field name used in the table structure and in scripts

{% hint style="warning" %}
Change the **Internal name** carefully. Other parts of the app, especially scripts, may depend on it.
{% endhint %}

Under **Permissions** for:

* **Roles that can read**: controls which roles are allowed to read. If no role is selected all users can read this field. Inherits access from the table.
* **Roles that can** **edit**: controls which roles are allowed to edit. If no role is selected all users can edit this field. Inherits access from the table.
* **Can read if**: controls who can view the field content
* **Can edit if**: controls who can edit the field content\
  To set up these options:

  * Click the gray field with the <i class="fa-code-simple">:code-simple:</i> icon.
  * Enter the logic that controls who can read or edit the field.

  For syntax and function details, see [Ninox Scripting](https://docs.ninox.com/ninox-scripting/).

Under **Behavior** for:

* **Required**: makes the field mandatory
* **Unique**: each record must have a unique value in this field. This option is not available for relationship fields.
* **Indexed**: this creates a lookup structure that allows the database to find records efficiently. This option is not available for relationship fields.

{% hint style="warning" %}
Do not index every field. Indexes use extra storage and memory. They can also reduce performance if used incorrectly.
{% endhint %}

Use indexing only when:

* the table holds many thousands of records,
* the field is used in `where` conditions
* and the query runs frequently every day.

Avoid indexing when:

* the table is small or the field is rarely filtered
* most records share the same value such as a Yes/No field.

For more details see [Index fields to speed up filters and searches](/ninox-scripting/automate-your-workflows/automations/index-fields-to-speed-up-filters-and-searches.md).

Under **Automations** for:

* **On update**: runs a script on the server, after leaving the field and the value actually changed.

#### On the form

**Label**: lets you label the field only for the form view.

{% hint style="info" %}
Use a more descriptive label for the user on the form. Keep the global label in **Everywhere** concise. This makes the field list easier to scan.
{% endhint %}

Under **Display** to configure:

* **Label position**: controls where the label appears
  * **Top**: shows the label above the field
  * **Left**: shows the label to the left of the field
  * **Inside**: shows the label inside the field
  * **Hidden**: hides the label
* **Placeholder**: shows a text when the field is empty
* **Left icon**, **Right icon**: displays an icon on the left or right side of the field in the form
* **Tooltip**: add help text that displays when the user moves the cursor over the field

Under **Behavior:**

* **Disabled**: makes that field read-only. To control that option by a logic click the gray field with the <> icon and enter a script for the condition.
* **On change**: runs a script immediately after each input, without leaving the field. For example in a text field, it runs after each character you type or delete.\
  For syntax and function details, see [Ninox Scripting](https://docs.ninox.com/ninox-scripting/).

Under **Visibility**:

* **Visible**, **Hidden**: controls whether the field appears on the form
* **Conditional**: lets you define a **Visibility condition** that controls when this field is shown or hidden

{% hint style="info" %}
Shared settings can still vary slightly by field type. The main differences usually appear in **General** and in field-specific display options.
{% endhint %}


---

# 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.ninox.com/builder-hub/design-your-app/add-and-edit-data-fields-in-your-tables/all-data-fields/shared-field-settings.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.