Records Core Concepts
Audience: Admins, Developers, Solution Architects
Purpose: Explains how Records function as the platform’s operational data layer, storing structured business data and enabling workflows, permissions, reporting, and API-driven integrations.
Overview
Records are the stored instances of business data that teams create, update, relate, and act upon within the platform. Each Record holds the field data that represents a single deal, asset, policy, or contact. When users interact with the system, they are interacting with Records.
A helpful analogy is a database table row. Each Record represents a single row of stored data, containing the values that define one distinct Record.
Workflows, permissions, reporting, and integrations frequently evaluate or modify Records. Understanding how Records behave is important when designing scalable data models and making informed architectural decisions.
System Behaviors
The following behaviors describe how Records operate across the platform:
Store field values: Each Record contains the data entered for a specific business entity. When values are created, updated, or cleared, the Record reflects the current state while maintaining an auditable history of changes through system-managed timestamps and timeline activity.
Include system-managed attributes: Every Record contains system fields such as unique identifiers, created and modified timestamps, and ownership or association references. These ensure traceability and operational integrity.
Follow a defined lifecycle: Records are created, updated, related, automated upon, archived, and potentially unarchived. Archiving removes a Record from active views while preserving history. Restoration reactivates it without data loss.
Generate timeline activity: Changes create timeline entries that show what changed and who initiated the change, supporting governance and collaboration.
Enforce identifier constraints: Each Record must satisfy object-level uniqueness requirements to prevent duplication conflicts and maintain referential integrity.
Inherit visibility through associations: Direct and indirect associations, evaluated alongside permissions, determine who can view or modify a Record.
For more information, see Records Data Model.
Why Records Matter
Records are the operational foundation of the platform’s data model and support core platform behaviors, including:
Activate object schemas
Power workflows and automation
Enable reporting and analytics
Support permission models and governance
Serve as the foundation for integrations and APIs
Poorly designed Record strategies create downstream complexity. Thoughtful Record design supports scalability, data integrity, and long-term maintainability.
Object Records vs Contact Records
While Object Records and Contact Records behave consistently, there are several important distinctions:
Foundational Record Model
Yes
Yes
Supports Custom Fields
Yes
Yes
Participates in Relationships
Yes
Yes
Participates in Automation
Yes
Yes
Primary Identifier
Record Name
Minimum Data Requirements
Defined by the Object's Schema
At least one identifying field (such as name, email, or mobile phone)
Communication-Specific Behavior
No
Yes (subscriptions, messaging history, email status)
Despite these differences, Contact Records remain Records within the same underlying data model. They store values, participate in automation, respect permissions, and support API operations in the same way as other Object Records.
For deeper guidance specific to contact behavior and communication features, see Contacts Core Concepts.
How Records Are Used
Records are the data around which business processes are organized.
Common patterns include:
Managing customers, deals, policies, assets, or projects
Tracking lifecycle progression across defined stages
Associating related data across Objects
Triggering automation based on Record changes
Supporting collaboration through shared visibility
Key Use Cases
The Record model supports diverse industries by enabling structured, operational data management around real-world entities. These examples illustrate the flexibility of the Record model across industries. The underlying behavior remains consistent while adapting to specific business contexts.
Industry Examples
Insurance Teams Managing Policy and Operational Records
Records enable insurance platforms to manage policies, claims, applications, and related operational data as structured, traceable entities.
Insurance teams use Records to capture lifecycle-driven data, associate related entities, and support compliance and servicing workflows.
Examples include:
Creating Policy Records to store structured data such as policy number, coverage type, effective dates, premium amount, and status
Managing Claim Records with loss details, incident dates, adjuster assignments, reserve amounts, and claim status
Associating Policy Records to agents, carriers, accounts, and related claims
Tracking renewals through workflow-driven status progression
How Records Help:
Maintain consistent operational data across policy lifecycles
Enable structured relationships between policies, claims, agents, and accounts
Support reporting and forecasting based on standardized field values
Power automation such as renewal creation or claim escalation workflows
Healthcare Organizations Managing Patient and Care Records
Records enable healthcare teams to organize patient data, care interactions, and provider relationships within a structured and governed framework.
Healthcare teams use Records to maintain accurate engagement histories, manage lifecycle status, and coordinate care-related activities.
Examples include:
Managing Patient Records with identifying information, status, and care milestones
Associating care interactions, providers, and treatment Records
Tracking engagement progression across intake, treatment, and follow-up stages
How Records Help:
Centralize patient-related operational data
Maintain traceable care history through timeline activity
Support regulatory compliance through auditable patient record history and controlled data access
Enable reporting across patient populations and care stages
Financial Services Teams Managing Client and Portfolio Records
Records allow financial services organizations to manage client relationships, engagements, and portfolio activity in a structured, auditable format.
Financial teams use Records to monitor lifecycle progression, enforce governance standards, and support advisor collaboration.
Examples include:
Managing Client Records with profile, engagement, and relationship data
Associating advisors, portfolios, and related financial accounts
Tracking milestones such as onboarding, review cycles, and compliance checkpoints
How Records Help:
Establish structured client data models
Support regulatory oversight through traceable record history and auditable field changes
Enable relationship-driven reporting across accounts and advisors
Power automation tied to engagement milestones or portfolio events
What’s Next
Continue to Records Data Model to explore the architectural structure behind record storage and relationships or explore any of the topics below:
Last updated
Was this helpful?