Special Field Types
Audience: Admins, Developers, Solution Architects
Purpose: Explains how special field types support advanced data modeling and helps administrators, solution architects, and developers select the appropriate field when designing Object schemas.
Overview
Special field types are advanced fields that extend schema capabilities beyond simple data capture. These fields enable more sophisticated data modeling by supporting structured relationships, centralized file storage, and team-based ownership and responsibility.
Unlike basic field types, which store discrete values such as text or numbers, special fields influence how Records connect to one another, how users collaborate, and how data is governed across the platform. Because of their broader impact, selecting and configuring these fields is an important architectural decision when designing scalable Object schemas.
Special field types are commonly used to:
Model relationships between Records
Centralize supporting documents and assets
Assign ownership or responsibility
Enable collaboration and workflow routing
Understanding how these fields behave, and when to use them, helps prevent schema design issues that can affect reporting accuracy, automation reliability, permissions, and long-term maintainability.
Checkbox
The Checkbox field supports a single binary selection and is best suited for true/false style data points. This field stores a boolean-style value and is useful for capturing simple conditions or flags that influence filtering, automation, or Record state.
Common Use Cases
Use a Checkbox field when capturing:
Feature enabled or disabled states
Confirmation indicators
Simple eligibility flags
One-time acknowledgements
Design Guidance
Choose a single Checkbox when only one binary condition is required. Avoid using this field when multiple selections or categorical values are needed, as selection-based field types are more appropriate in those cases.
Note: If you need to have multiple selections or categorical values, use the multi-selection checkboxes field type.
Files
The Files field allows Records to store and reference uploaded documents or digital assets directly within the Record context. Each uploaded file is stored as a separate asset, even if the same file is uploaded to multiple Records.
Common Use Cases
Use a Files field to attach:
Contracts or agreements
Images or media assets
Supporting documentation
Operational resources
Reference files
Centralizing files within Records improves context, reduces dependency on external storage systems, and supports collaboration across teams. Uploaded files are automatically scanned for potential threats and may be removed if a virus is detected or suspected.
Behavior and Governance Considerations
Files are associated with the specific Record where they are uploaded. Removing a file reference does not automatically remove the file from other Records where it may exist.
Permissions determine whether users can upload, remove, or permanently delete files. Because files may contain sensitive information, access controls should be planned carefully. Thoughtful file organization helps prevent unnecessary duplication and keeps Records manageable.
Relationship
The Relationship field connects Records across Objects, enabling structured associations within the data model. Relationship fields are foundational to modeling how entities relate to one another and play a critical role in schema architecture.
For more information, see Object Relationships.
Common Use Cases
Use Relationship fields to:
Link contacts to organizations
Associate deals with accounts
Connect related operational Records
Model hierarchical or peer relationships
Behavior and Architecture Considerations
Relationship fields automatically create an inverse relationship on the related Object, enabling navigation in both directions.
Relationships support:
Cross-Object reporting
Automation triggers and conditions
Record navigation and context
When relationship fields contain many values, the platform summarizes them in timelines and API responses to maintain usability and performance. Because relationships define how data is interconnected, they should be designed intentionally to preserve data integrity, avoid ambiguity, and support long-term scalability. It is important to treat relationship fields as architectural components and not simple attributes.
Team Selector
The Team Selector field assigns ownership or responsibility to specific team members within the organization. This field references active users and is commonly used to model accountability and collaboration.
Common Use Cases
Use a Team Selector field to:
Assign Record ownership in the system Owner field
Route work to specific users
Define responsibility for follow-up
Support collaboration workflows
Influence visibility and access
Permissions and Workflow Impact
Team-based assignments can affect permissions, workflow routing, and operational visibility depending on how access controls and automations are configured. Align team assignments with organizational structure to ensure consistent governance and reduce confusion around responsibility and access.
Additional Information
Schema Design Best Practices
When working with special field types:
Use relationships instead of large selection lists when modeling connected data.
Plan file access and permissions carefully to avoid governance issues.
Align team assignments with workflow and access requirements.
Treat relationship fields as architectural components, not simple attributes.
Intentional use of special fields strengthens data integrity, improves collaboration, and supports scalable system design.
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:
Last updated
Was this helpful?