space.vars.fields extend an space.vars.object’s schema by allowing administrators to capture structured data beyond the platform’s default fields. Each space.vars.field represents a defined attribute on a space.vars.entity and directly influences how data is stored, validated, automated, reported on, secured, and accessed through APIs.
Selecting the correct field type is a foundational schema decision with downstream impacts across the platform.
Field configuration affects:
* **Data consistency:** Structured fields enable reliable filtering, segmentation, and analytics.
* **Agentic Workflow behavior:** Field values frequently act as triggers, conditions, and update targets.
* **Reporting capabilities:** Field types determine whether data can be grouped, aggregated, or used as metrics.
* **Permissions:** Field-level access controls visibility and edit rights.
* **API integrations:** Field API names and metadata define how external systems read and write data.
space.vars.fields share the same underlying architecture as standard fields and behave consistently across space.vars.objects, activities, forms, automations, and integrations.
{% hint style="info" %}
**Note:** Field types cannot be converted after creation. Changing a field type typically requires creating a new field and migrating data, which may impact automations, reports, and integrations.
{% endhint %}
Before designing or modifying an space.vars.object schema, review available field types, platform limits, and specialized behaviors to ensure long-term scalability.
***
## Custom Field Type Reference
The following table provides a high-level comparison of supported field types to guide schema planning decisions.
| Field Type | Limits | Special Features / Notes |
|---|---|---|
| Checkbox | Boolean value. You can only select 1 | Stores a true value or null if nothing is selected. Unchecked values are stored as null. null==false. Useful for binary states. |
| Checkboxes | Up to 250 selectable options | Allows multiple predefined values. Renders as checkboxes or collapses into a dropdown when option counts grow beyond 4. |
| Currency / Price | Up to 4 decimal places | Displays a currency symbol without automatic conversion. Supports negative values and is a number + currency symbol. |
| Date | Stores calendar date only | No time component. Evaluated relative to the business timezone for comparisons and space.vars.automation logic. |
| Date & Time | Timezone-aware timestamp | Entered in the user’s timezone and normalized for consistent reporting. Dashboards typically filter using the business timezone. |
| Dropdown (Single-Select) | Up to 250 options | Allows selection of one predefined value. Supports predictable filtering, reporting, and space.vars.automation logic. Recommended when data must remain standardized. |
| Dropdown (Multi-Select) | Up to 250 options | Allows selection of multiple predefined values. Useful for categorical data where more than one value may apply. May require additional consideration in reporting and automation due to multiple stored values. |
| Dynamic Tags | No practical option limit (performance optimized) | Users can create values at runtime. Behaves similarly to a lightweight relationship. Should be governed to prevent uncontrolled taxonomy growth. |
| Must be valid email format | Stored as data only. Custom email fields do not enable messaging workflows. | |
| Files | 10 MB per file | Each upload creates a separate stored file, even when reused across records. Optional hard-delete permission available. |
| Long Text / Rich Text | Up to 50,000 characters | Supports markdown rendering. Optimized for large content but limited in filtering and aggregation. Treated as unstructured data. |
| Number (Decimal) | Up to 15 digits total | Supports numeric filters and calculations. Values may be negative. |
| Phone Number | Must follow international (E.164) format | Automatically formats country codes. SMS uses the mobile phone field when applicable. Extensions supported for business numbers. |
| Radio Buttons | Up to 250 options | Single-select field rendered as buttons for fast selection. |
| Rating | 5- or 10-point scale | Hybrid behavior: supports both categorical filtering and numeric comparisons (for example, “greater than”). |
| Relationship | Supports 1:1, 1:M, M:1, and M:M | Automatically creates an inverse relationship field. Timeline displays individual values up to 20 records; larger sets are summarized. API responses summarize after 100 values. Not supported on forms. |
| Status | Up to 250 values | Dropdown field with color metadata for visual workflow tracking. |
| Team Member / Employee Selector | Active users only | References a user within the business. Honors permission visibility and audit tracking. Forms display employee names but not email addresses. |
| Text (Short) | 255 characters | Text fields store unstructured values and can be indexed to support search and type-ahead behavior when indexing is enabled. They are commonly used for identifiers, labels, and display names. |
| Whole Number (Integer) | Up to 2,147,483,647 | Ideal for counts and whole-number quantities, including negative values when decreases or offsets must be tracked. |
| Yes / No / Maybe | Optional third state | Supports null values to distinguish between “No” and “No response.” Can be treated as a boolean in space.vars.automation logic. |
space.vars.field includes metadata that influences validation behavior, API interactions, and UI rendering.
Common metadata properties include:
* `is_required`: Field must be provided during record creation.
* `allows_nulls`: Accepts null values.
* `allows_empty`: Accepts empty values appropriate to the field type (for example `""`, `[]`, `{}`).
* `is_masked`: Obscures sensitive text until user interaction.
* `is_markdown`: Renders long text fields as rich text.
A field is considered clearable when it is not required and allows empty values.
Understanding metadata is particularly important when designing integrations or enforcing governance rules.
***
## Platform Limits
space.vars.field capacity varies by subscription level and should be considered during schema design.
* **Free accounts** support up to 50 Fields (including default fields) per space.vars.object
* **Paid plans** allow additional space.vars.fields, with limits determined by the organization’s purchased plan
If your implementation requires more fields than your current plan supports, contact [Customer Support](https://support.kizen.com/support/tickets/new) to discuss available options.
Regardless of plan, an space.vars.object supports a maximum of 500 custom fields. Approaching this limit may indicate schema complexity that should be reviewed for long-term scalability. If your use case requires additional fields, contact [Customer Support](https://support.kizen.com/support/tickets/new) to discuss available options and design considerations.
{% hint style="info" %}
**Note:** These limits also apply to forms and activity fields, reinforcing the importance of thoughtful schema design.
{% endhint %}
***
## Activity Field Alignment
Many space.vars.fields can also be reused as space.vars.activity fields, enabling consistent schema design across operational space.vars.entities such as calls, meetings, and tasks. Reusing structured fields enables consistent automation, filtering, and analytics across operational workflows.
For example:
* Dropdown fields can categorize logged calls
* Rating fields can measure interaction quality
* Relationship fields can link an activity to multiple related space.vars.entities, depending on your relationship configuration.
Aligning space.vars.object and space.vars.activity schemas improves reporting fidelity and operational clarity.
For more information see, [Activity Custom Fields](/docs/concepts/activities/activities-data-model.md#activity-custom-fields).
***
## Additional Information
space.vars.fields, consider the following guidelines:
* Prefer structured fields over free text when reporting, filtering, or automation will depend on the data.
* Select field types carefully, as they cannot be converted after creation without rebuilding the field and migrating data.
* Use relationships instead of large selection lists when modeling connections between records.
* Plan field API names intentionally, since changes may disrupt integrations, automations, and merge fields.
* Avoid excessive field counts, which can increase schema complexity and impact usability.
Thoughtful schema design improves data quality, simplifies reporting, and supports long-term platform scalability.