Custom Fields
Overview
Custom Fields extend an Object’s schema by allowing administrators to capture structured data beyond the platform’s default fields. Each Custom Field represents a defined attribute on a Record 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.
Automation 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.
Custom Fields share the same underlying architecture as standard fields and behave consistently across Objects, activities, forms, automations, and integrations.
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.
Before designing or modifying an 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.
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.
Up to 250 selectable options
Allows multiple predefined values. Renders as checkboxes or collapses into a dropdown when option counts grow beyond 4.
Up to 4 decimal places
Displays a currency symbol without automatic conversion. Supports negative values and is a number + currency symbol.
Stores calendar date only
No time component. Evaluated relative to the business timezone for comparisons and automation logic.
Timezone-aware timestamp
Entered in the user’s timezone and normalized for consistent reporting. Dashboards typically filter using the business timezone.
Up to 250 options
Allows selection of one predefined value. Supports predictable filtering, reporting, and automation logic. Recommended when data must remain standardized.
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.
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.
10 MB per file
Each upload creates a separate stored file, even when reused across records. Optional hard-delete permission available.
Up to 50,000 characters
Supports markdown rendering. Optimized for large content but limited in filtering and aggregation. Treated as unstructured data.
Up to 15 digits total
Supports numeric filters and calculations. Values may be negative.
Must follow international (E.164) format
Automatically formats country codes. SMS uses the mobile phone field when applicable. Extensions supported for business numbers.
5- or 10-point scale
Hybrid behavior: supports both categorical filtering and numeric comparisons (for example, “greater than”).
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.
Active users only
References a user within the business. Honors permission visibility and audit tracking. Forms display employee names but not email addresses.
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.
Up to 2,147,483,647
Ideal for counts and whole-number quantities, including negative values when decreases or offsets must be tracked.
Optional third state
Supports null values to distinguish between “No” and “No response.” Can be treated as a boolean in automation logic.
Custom Field Metadata
Each Custom 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
Custom Field capacity varies by subscription level and should be considered during schema design.
Free accounts support up to 50 Fields (including default fields) per Object
Paid plans allow additional Custom Fields, with limits determined by the organization’s purchased plan
If your implementation requires more fields than your current plan supports, contact Customer Support to discuss available options.
Regardless of plan, an 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 to discuss available options and design considerations.
Note: These limits also apply to forms and activity fields, reinforcing the importance of thoughtful schema design.
Activity Field Alignment
Many Custom Fields can also be reused as Activity fields, enabling consistent schema design across operational Records 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 Records, depending on your relationship configuration.
Aligning Object and Activity schemas improves reporting fidelity and operational clarity.
For more information see, Activity Custom Fields.
Additional Information
Schema Design Best Practices
When creating Custom 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.
What’s Next
Explore any of the field-specific documentation before implementing schema changes to ensure the selected field type supports your operational, reporting, and integration requirements.
Last updated
Was this helpful?