Selection Field Types
Audience: Administrators, Developers, Solution Architects
Purpose: Explains how selection-based field types capture structured, predefined values and helps administrators and developers choose the correct field type when designing Object schemas.
Overview
Selection field types allow users to choose from predefined values instead of entering freeform data. By constraining input to controlled options, these fields:
Enforce data consistency
Reduce spelling variations and fragmentation
Improve reporting accuracy
Enable reliable filtering and segmentation
Support predictable Automation behavior
Choosing the correct selection field type is a foundational schema decision that affects Record filtering and grouping, Automation triggers, integration interpretation of field values, and the overall data entry experience across the system.
Some selection fields support a single value, while others allow multiple values. Understanding this distinction is critical when designing for reporting logic, workflow triggers, and API updates.
Choosing the Right Selection Field
Use the table below to select the correct selection field based on reporting, Automation, and lifecycle requirements.
Single-select
Tracking lifecycle or workflow progression with drop-down and color-coded visual context
Single-select
Capturing three-state logic (affirmative, negative, neutral); also can be two-state logic if maybe is toggled off
Checkboxes
Checkboxes allow users to select multiple values from a predefined list.
Common Use Cases
Use checkboxes when:
Multiple categories may apply to a single Record
Values are relatively stable and predefined
You need structured multi-value segmentation
Examples include:
Product interests
Skills or certifications
Applicable service areas
Behavior Considerations
Checkboxes support multi-select behavior, which affects filtering updates, and Automation logic across the system. A checkboxes field:
Stores a list of selected options
Allows zero, one, or multiple values per Record
Requires “contains” or multi-condition filtering logic
Uses array-based updates in the API, including
add_valuesandremove_values
Reporting Considerations
Multi-select data can increase reporting complexity. Aggregations and filters must account for Records containing multiple values.
Note: Avoid checkboxes when a Record should belong to only one category, as multi-select fields complicate grouping and state-based automation logic.
Dropdown (Single-Select)
Dropdown fields allow users to select one value from a predefined list, ensuring clear and mutually exclusive categorization.
Common Use Cases
Use a single-select dropdown when:
Only one value should apply to a Record
You want clean, consistent grouping
Automation and reporting depends on mutually exclusive states
Examples include:
Business type
Customer type
Priority level
Behavior Considerations
Single-select dropdowns enforce one active value per Record, supporting unambiguous categorization and predictable Automation logic. A dropdown field:
Enforces mutually exclusive options.
Each record stores a single selected value.
Ideal for standardized categorization.
Prefer single-select fields when records must belong to only one operational state.
Reporting Considerations
Single-select dropdowns are ideal for reporting because each Record contains exactly one standardized value, enabling clean aggregation and segmentation. A dropdown field:
Produces reliable counts by category without duplication.
Supports clear grouping in charts, dashboards, and pipeline summaries.
Prevents ambiguous reporting caused by overlapping or multi-value selections.
Enables consistent trend analysis over time when option values remain stable.
Note: Values are mutually exclusive, reports can safely assume that each belongs to one—and only one—category. To maintain reporting integrity, avoid frequently renaming or deleting options, as changes can fragment historical data.
Why Choose Dropdown Over Radio Buttons?
Both dropdowns and radio buttons support single-select behavior but differ in presentation and space usage.
Choose Dropdown when:
The list of options is long
Screen space is limited
Options do not need to be visible at all times
You want a cleaner, more compact Record layout
Dropdowns reduce visual clutter by collapsing options until clicked.
Dropdown (Multi-Select)
When configured for multi-select, dropdown fields allow users to choose multiple values from a predefined list while maintaining a compact interface.
Common Use Cases
Use multi-value dropdown when:
Multiple classifications may apply
The option set is longer and would be visually overwhelming as checkboxes
You want a cleaner UI while retaining multi-select capability
Behavior Considerations
Multi-select dropdowns support multiple structured values per Record, which influences filtering, reporting, and API updates. A multi-select dropdown:
Allows multiple values
Saves structured list data
Uses array-based updates in API interactions.
Reporting Considerations
Multi-select dropdowns introduce additional reporting complexity because each Record can contain multiple values. A multi-select dropdown:
May count a single Record in multiple categories when grouped by field value.
Requires “contains” or array-based filtering logic in reports.
Can inflate totals if reports do not distinguish between Record count and value count.
Is better suited for segmentation and overlap analysis than mutually exclusive categorization.
Note: Avoid multi-select configurations when mutually exclusive categorization is required, as multi-value data increases reporting and Automation complexity.
Radio Buttons
Provides a single-select experience where all options are visible.
Common Use Cases
Use radio buttons when:
The list of options is short
Visibility of all choices improves usability
You want to reduce clicks compared to a dropdown
Examples include:
Yes / No style decisions (without a neutral state)
Small categorization sets (e.g., Small / Medium / Large)
Behavior Considerations
Radio buttons enforce mutually exclusive selection while keeping all options visible. A radio button field:
Allows only one selected value
Displays all options simultaneously
Supports clear, unambiguous categorization
Prefer radio buttons when the option set is small enough to display without overwhelming the interface.
Rating
Rating fields capture ordered, scaled evaluations that support scoring, comparison, and threshold-based Automation.
Common Use Cases
Use rating fields for:
Customer satisfaction scoring
Priority or urgency scoring
Internal quality assessments
Behavior Considerations
Rating fields store ordered values that are commonly evaluated numerically in reporting and Automation logic. A rating field:
Stores a scaled-option value
Supports scoring and qualitative assessments
Use rating fields when relative measurement is required rather than simple categorization.
Reporting Considerations
Rating fields are especially useful when:
You need averages or score distributions.
Automations depend on thresholds (for example, rating ≥ 4).
Dynamic Tags
Dynamic tag fields support flexible, multi-value categorization by allowing new tag values to be created at runtime without modifying field configuration.
Common Use Cases
Use dynamic tags when:
Categories evolve frequently.
Users need flexible labeling without redesigning schema.
Segmentation must remain structured but adaptable.
Behavior Considerations
Dynamic tag fields support multi-select behavior and runtime value creation. A dynamic tag field:
Allows multiple selected values per Record
Permits new tag values to be created without schema updates
Supports incremental add and remove operations
Maintains structured option identifiers for filtering and Automation
Use dynamic tags when flexibility is required, but avoid them when strict, predefined categorization is necessary.
Note: Admins can merge options to consolidate semantically similar tags and maintain clean, consistent data over time.
Reporting Considerations
Dynamic tags maintain structured option IDs, enabling consistent filtering and Automation despite flexible categorization.
Status
Status fields represent a Record’s lifecycle state and often drive operational workflows, reporting, and pipeline behavior.
Common Use Cases
Use status fields when:
Tracking lifecycle progression
Representing operational state
Driving Automation triggers based on state transitions
Tracking severity of an issue (because of the various status colors)
Behavior Considerations
Status fields frequently influence lifecycle workflows and system logic. A status field:
Is always single-select
Often integrates with pipeline and Automation behavior
Can affect reporting calculations
Includes configurable color indicators (the primary difference from a dropdown)
Special Considerations
Status fields can:
Influence reporting metrics
Affect forecasting or performance tracking
Treat status fields as operational controls. Changes can directly impact Automations, reporting accuracy, and forecasting.
Yes / No / Maybe
Yes / No / Maybe fields capture explicit decision states when binary logic is insufficient.
Common Use Cases
Use the Yes / No / Maybe fields when:
You need to track uncertainty or pending decisions with blank values
You want to avoid blank or null values to represent indecision
Examples include:
Approval readiness
Attendance confirmation
Interest level
Behavior Considerations
Yes / No / Maybe fields support three mutually exclusive responses, enabling explicit capture of affirmative, negative, and neutral states. This field:
Allows selection of Yes, No, or Maybe
Provides structured alternative to binary logic
Explicitly supports neutral or undecided states
Allows the “Maybe” option to be toggled off if only Yes/No is needed
What’s Next
Before implementing schema changes, review field-specific documentation to understand configuration limits, API behavior, and downstream system impact. Continue building your field knowledge.
Last updated
Was this helpful?