> For the complete documentation index, see [llms.txt](https://developer.kizen.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.kizen.com/docs/concepts/objects/custom-fields/text-field-types.md).

# Text Field Types

{% hint style="success" %}
**Audience:** Admins, Developers, Solution Architects

**Purpose:** Explains how `text` and `longtext` fields store written information and helps administrators, solution architects, and developers choose the appropriate field type when designing <code class="expression">space.vars.object</code> schemas.
{% endhint %}

## Overview

Text field types are flexible fields used to capture descriptive or narrative information that cannot always be constrained to predefined values. These fields provide important context that helps users interpret <code class="expression">space.vars.entities</code>, understand operational history, and document key details.

Text-based data commonly supports:

* Notes and summaries
* Descriptions
* Identifiers
* Titles
* Comments
* Contextual <code class="expression">space.vars.entity</code> information

Selecting the appropriate text field type helps balance flexibility with usability. While freeform input enables richer context, thoughtful schema design ensures that written data remains readable, searchable, and operationally valuable.

<code class="expression">space.vars.Kizen\_company\_name</code> supports two primary text field types:

* `text`: optimized for short, structured inputs
* `longtext`: designed for extended written content

Choosing the correct field type is a foundational schema decision that influences searchability, reporting capabilities, <code class="expression">space.vars.automation</code> behavior, and overall <code class="expression">space.vars.entity</code> clarity.

### Key Differences

The table below summarizes the core differences between `text` and `longtext` fields.

| Capability            | Text                     | LongText                   |
| --------------------- | ------------------------ | -------------------------- |
| Character limit       | 255                      | 50,000                     |
| Intended use          | Short, structured inputs | Extended narrative content |
| Search optimization   | Strong                   | Limited                    |
| Reporting suitability | Moderate                 | Low                        |
| Scannability          | High                     | Lower for dense content    |
| Formatting support    | Plain text               | Markdown-enabled rendering |

{% hint style="info" %}
**Note:** If the value should be quickly read, filtered, or searched, choose `text`. If the value requires depth and explanation, choose `longtext`.
{% endhint %}

***

## LongText

The `longtext` field is designed to store extended written content and multi-paragraph information.

This field is best suited for scenarios where detailed explanations or narrative context are necessary to understand a <code class="expression">space.vars.entity</code>.

Use this field for extended narrative content that requires multi-paragraph readability. Avoid it when concise, structured data is sufficient.

### Common Use Cases

Use a `longtext` field when capturing:

* Detailed notes
* Meeting summaries
* Project descriptions
* Case documentation
* Internal commentary
* Multi-step instructions
* AI- or LLM-generated content that uses structured formatting such as Markdown

`longtext` fields support up to 50,000 characters, allowing teams to preserve comprehensive operational knowledge directly within a <code class="expression">space.vars.entity</code>. For content that exceeds this limit, consider attaching a text file or external document to maintain full detail.

### Behavior and Search Considerations

`longtext` fields support rich text formatting through markdown rendering, improving readability for extended content. These formatting enhancements affect display and editing only and do not alter the stored value.

Because `longtext` fields store large amounts of unstructured data, they are not optimized for structured reporting or detailed filtering. Indexing behavior may also differ to support platform performance, which can limit advanced search capabilities compared to shorter text fields.

***

## Text

The `text` field is intended for shorter written inputs that benefit from quick readability and structured usage. This field supports values up to 255 characters, making it ideal for concise information that users need to scan quickly or reference frequently.

Use this field for short, structured data that must be easily searchable, filterable, or quickly scanned.

### Common Use Cases

Use a `text` field when capturing:

* Names or labels
* Titles
* Identifiers
* Short descriptors
* Reference values
* Brief comments

Shorter `text` fields help maintain cleaner record layouts and improve overall usability.

### Behavior and Search Considerations

`text` fields are typically indexed to support search and type-ahead functionality, making them more effective for lookup scenarios than long-form content. Because values are structured and compact, these fields are often easier to leverage in filters, lightweight reporting, and <code class="expression">space.vars.automation</code> conditions.

`text` fields can also be used in display configurations where readable identifiers are required across the platform and support flexible filtering options such as contains, starts with, and exact match.

***

## Additional Information

<details>

<summary>Schema Design Best Practices</summary>

When designing schemas that include written data:

* Prefer structured fields (such as dropdowns or relationships) when reporting or segmentation is required
* Use `text` instead of `longtext` whenever possible to improve searchability and usability
* Reserve `longtext` for information that genuinely requires expanded narrative
* Avoid storing operational data inside large text blocks that cannot be easily filtered
* Consider <code class="expression">space.vars.entity</code> readability as overly verbose schemas can reduce efficiency for end users

Thoughtful text field selection helps maintain scalable data models while preserving important context.

</details>

***

## What’s Next

Review field-specific documentation before implementing schema changes to ensure the selected field type supports your operational, reporting, and integration requirements. Continue designing your schema with the following resources:

<details>

<summary>Related Topics</summary>

* [Date Field Types](/docs/concepts/objects/custom-fields/date-field-types.md)
* [Selection Field Types](/docs/concepts/objects/custom-fields/selection-field-types.md)
* [Numerical Field Types](/docs/concepts/objects/custom-fields/numerical-field-types.md)
* [Communication Field Types](/docs/concepts/objects/custom-fields/communication-field-types.md)
* [Special Field Types](/docs/concepts/objects/custom-fields/special-field-types.md)

</details>


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/concepts/objects/custom-fields/text-field-types.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.