Contacts Core Concepts
Audience: Admins, Developers, Solution Architects
Purpose: Explains what Contacts are, how they behave differently from Objects, and when to use Contacts to model people, communication, and identity across the platform.
Overview
Contacts represent people in the platform’s data model.
While Contacts share the same structural foundation as Objects such as Fields, Records, relationships, permissions, APIs, they introduce system-level behavior designed specifically for person-based identity, communication, consent, and compliance.
Use Contacts when you need to:
Represent real individuals
Send or manage email and SMS communication
Enforce consent and deliverability rules
Reference people externally using person-level identifiers
Contacts are a specialized system Object with additional guarantees and constraints that ensure safe, consistent handling of people and messaging across the platform.
What Makes Contacts Unique
Contacts behave differently from standard or workflow Objects in several important ways:
Identity-based: Contacts use email (if available) as a unique identifier
Communication-aware: Contacts participate in email and SMS workflows
Consent-enforcing: Messaging behavior is governed by system rules
De-duplicated: The platform prevents multiple Contacts from sharing the same email
Ownerless: Contacts do not have an Owner field; access is association-driven
These behaviors are enforced at the system level and cannot be replicated by modeling people as custom Objects.
Why Contacts Matter
Using Contacts instead of Objects ensures:
Accurate identity resolution across imports and integrations
Safe messaging and subscription enforcement
Reliable Agentic Workflow triggers tied to communication events
Clean reporting and timelines tied to real individuals
Compliance with deliverability and consent requirements
Modeling people as standard Objects may appear simpler initially, but it removes access to these system guarantees and often introduces long-term risk, duplication, or compliance issues.
Contact Features
Contacts support all core platform capabilities—fields, relationships, permissions, Agentic Workflows, APIs—plus additional features designed specifically for people.
Contact Record
A Contact Record represents a single real person.
Each Contact Record:
Stores person-level field values
Can be related to other Contacts and Objects
Can participate in messaging and Agentic Workflows
Appears across timelines, reports, dashboards, and APIs
Contacts are first-class Records in the data model, not secondary profiles.
Contact Custom Fields
Contacts support the same custom field system as standard Objects, allowing each organization to model people according to their needs.
In addition to standard field types, Contacts include system-managed fields with specialized behavior:
Email (unique identifier)
First Name
Last Name
Titles
Email Status (consent and deliverability)
Tags (with built-in tag management)
Home Phone
Mobile Phone (used for SMS)
Business Phone
Time Zone (used for time-aware messaging)
These fields directly influence messaging, Agentic Workflows, and compliance behavior.
Where Contacts Appear
Contacts surface throughout the platform wherever people are relevant, including:
Relationship fields on other Records
Timelines and activity feeds
Agentic Workflows and triggers
Messaging workflows (email and SMS)
Reports and dashboards
API responses and lookups
Contacts, like other Custom Objects, can appear across many Records and workflows simultaneously without duplication.
Objects vs Contacts
Contacts and Objects share the same architectural foundation but serve different purposes.
Always present regardless of permissions
No
No
Accessible via Objects/ Record APIs
No
Yes
Supports Custom Fields
Yes
Yes
Can relate to other Objects
Yes
Yes
Schema flexibility
Limited (Workflows not available)
Fully configurable
Optimized for Communication, Email & SMS
Yes
No
Unique Identifier
Record Name
For a deeper explanation of Object structure and lifecycle, see Objects Core Concepts.
Key Use Cases
If the record must be addressable as a person, it should be a Contact. Use Contacts when you need to:
Send emails or SMS messages
Track communication history with individuals
Manage consent and opt-in status
Identify people consistently across systems
Associate people with multiple records (accounts, policies, cases, etc.)
Model households, teams, or networks of individuals
Trigger Agentic Workflows based on person-level behavior
Below are industry examples of how to use Contacts.
Industry Examples
Modeling People Across Policies and Claims
Insurance teams use Contacts to represent the people involved in coverage and service delivery, while Policies, Claims, Applications, and Renewals remain Objects. Contacts make it possible to reliably identify individuals, communicate with them, and connect them to multiple policies and lifecycle events.
Examples include:
Creating a Policyholder Contact to store person-specific information such as name, email, phone, preferred communication method, and time zone
Creating a Beneficiary Contact and relating them to one or more Policy Records
Creating a Claimant Contact and relating them to Claim Records for claim intake and updates
Creating a Broker/Agent Contact and relating them to Accounts, Policies, and Applications to support servicing workflows
Using Email Status to enforce opt-in/opt-out behavior before sending renewal notices or claim updates
How Contacts Help:
Establish a consistent, de-duplicated identity layer (email-based when present) for policyholders, beneficiaries, claimants, and brokers
Enable relationships between people and operational Records (Policy ↔ Contact, Claim ↔ Contact, Application ↔ Contact)
Support compliant communication workflows by enforcing Email Status and suppression behavior
Improve Agentic Workflow reliability (for example, trigger renewals or claim updates using Contact identity + relationship context)
Reduce duplication risk during imports and integrations by using Contacts as the canonical person Record
Modeling Patients, Caregivers, and Providers
Healthcare teams use Contacts to represent individuals who participate in care and communication—patients, caregivers, emergency contacts, and providers—while clinical, operational, and service workflows remain Objects (appointments, cases, referrals, authorizations, care plans).
Examples include:
Creating a Patient Contact to store name, email, mobile phone, time zone, preferred language, and other person-level attributes
Creating a Caregiver Contact and relating them to the Patient Contact and to care-related Records (cases, care plans)
Creating an Emergency Contact and relating them to a Patient Contact for operational readiness
Using Mobile Phone and Contact messaging rules for SMS reminders (when texting is enabled)
Using Email Status to prevent messaging when consent is not present or deliverability is suppressed
How Contacts Help:
Provide a person-level identity layer that can be referenced across many care workflows without duplicating people
Enable relationship-driven collaboration (Contacts don’t have Owners; visibility is modeled through relationships + permissions)
Support communication workflows like appointment reminders, care updates, and patient outreach
Enforce consent and deliverability rules through Email Status and suppression behavior
Modeling Clients, Advisors, and Beneficiaries
Financial services teams use Contacts to represent people who hold financial relationships—clients, advisors, beneficiaries, authorized representatives—while accounts, products, applications, and service workflows remain Objects.
Examples include:
Creating a Client Contact to store name, email, phone, time zone, and communication preferences
Creating an Advisor Contact and relating them to one or many Client and Account Records
Creating a Beneficiary Contact and relating them to financial products or account structures
Creating an Authorized Representative Contact and relating them to client Records for service and compliance workflows
Using Email Status to enforce subscription and deliverability rules for statements, notices, and outreach
How Contacts Help:
Establish a consistent people layer across accounts, products, and servicing workflows
Support complex real-world structures (households, trusts, joint relationships) through many-to-many relationships
Improve integration reliability by using Contact identity (email-based when present) for lookup and upsert behavior
Support compliant communication by enforcing Email Status and suppression behavior across all related Records
Enable better operational visibility by tying timelines, messaging history, and automations to the Contact Record
What’s Next
To continue learning about Contacts, review Contacts Data Model to understand identifiers, schema, and system rules.
Last updated
Was this helpful?