# Contacts Core Concepts

{% hint style="success" %}
**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.
{% endhint %}

## Overview

Contacts represent people in the platform’s data model.

While Contacts share the same structural foundation as <code class="expression">space.vars.objects</code>—fields, <code class="expression">space.vars.entities</code>, 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 <code class="expression">space.vars.object</code> 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 <code class="expression">space.vars.objects</code> 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 <code class="expression">space.vars.objects</code>.

### Why Contacts Matter

Using Contacts instead of <code class="expression">space.vars.objects</code> ensures:

* Accurate identity resolution across imports and integrations
* Safe messaging and subscription enforcement
* Reliable <code class="expression">space.vars.automation</code> triggers tied to communication events
* Clean reporting and timelines tied to real individuals
* Compliance with deliverability and consent requirements

Modeling people as standard <code class="expression">space.vars.objects</code> 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, <code class="expression">space.vars.automations</code>, APIs—plus additional features designed specifically for people.

### Contact Record

A Contact <code class="expression">space.vars.entity</code> represents a single real person.

Each Contact <code class="expression">space.vars.entity</code>:

* Stores person-level field values
* Can be related to other Contacts and <code class="expression">space.vars.objects</code>
* Can participate in messaging and <code class="expression">space.vars.automations</code>
* Appears across timelines, reports, dashboards, and APIs

Contacts are first-class <code class="expression">space.vars.entities</code> in the data model, not secondary profiles.

### Contact Custom Fields

Contacts support the same custom field system as standard <code class="expression">space.vars.objects</code>, 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, <code class="expression">space.vars.automations</code>, and compliance behavior.

### Where Contacts Appear

Contacts surface throughout the platform wherever people are relevant, including:

* Relationship fields on other <code class="expression">space.vars.entities</code>
* Timelines and activity feeds
* <code class="expression">space.vars.automations</code> and triggers
* Messaging workflows (email and SMS)
* Reports and dashboards
* API responses and lookups

Contacts, like other Custom <code class="expression">space.vars.objects</code>, can appear across many <code class="expression">space.vars.entities</code> and workflows simultaneously without duplication.

***

## Objects vs Contacts

Contacts and Objects share the same architectural foundation but serve different purposes.

| Aspect                                                                                                                    | Contacts                                                                     | Custom Objects                                         |
| ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------ |
| Always present regardless of permissions                                                                                  | No                                                                           | No                                                     |
| Accessible via <code class="expression">space.vars.objects</code>/ <code class="expression">space.vars.entity</code> APIs | No                                                                           | Yes                                                    |
| Supports <code class="expression">space.vars.fields</code>                                                                | Yes                                                                          | Yes                                                    |
| Can relate to other <code class="expression">space.vars.objects</code>                                                    | Yes                                                                          | Yes                                                    |
| Schema flexibility                                                                                                        | Limited (<code class="expression">space.vars.workflows</code> not available) | Fully configurable                                     |
| Optimized for Communication, Email & SMS                                                                                  | Yes                                                                          | No                                                     |
| Unique Identifier                                                                                                         | Email                                                                        | <code class="expression">space.vars.entity</code> Name |

{% hint style="info" %}
**Note**: If you are modeling people, use Contacts. If you are modeling things, processes, or business entities, use <code class="expression">space.vars.objects</code>.
{% endhint %}

For a deeper explanation of <code class="expression">space.vars.object</code> structure and lifecycle, see [Objects Core Concepts](/docs/concepts/objects/object-core-concepts.md).

***

## 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 <code class="expression">space.vars.automations</code> based on person-level behavior

Below are industry examples of how to use Contacts.

### Industry Examples

{% tabs %}
{% tab title="Insurance" %}

### 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 <code class="expression">space.vars.objects</code>. 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 <code class="expression">space.vars.entities</code>
* Creating a **Claimant Contact** and relating them to Claim <code class="expression">space.vars.entities</code> 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 <code class="expression">space.vars.entities</code> (Policy ↔ Contact, Claim ↔ Contact, Application ↔ Contact)
* Support compliant communication workflows by enforcing Email Status and suppression behavior
* Improve <code class="expression">space.vars.automation</code> 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 <code class="expression">space.vars.entity</code>
  {% endtab %}

{% tab title="Healthcare" %}

### 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 <code class="expression">space.vars.objects</code> (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 <code class="expression">space.vars.entities</code> (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
  {% endtab %}

{% tab title="Financial Services" %}

### 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 <code class="expression">space.vars.objects</code>.

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 <code class="expression">space.vars.entities</code>
* Creating a **Beneficiary Contact** and relating them to financial products or account structures
* Creating an **Authorized Representative Contact** and relating them to client <code class="expression">space.vars.entities</code> 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 <code class="expression">space.vars.entities</code>
* Enable better operational visibility by tying timelines, messaging history, and automations to the Contact <code class="expression">space.vars.entity</code>
  {% endtab %}
  {% endtabs %}

***

## What’s Next

To continue learning about Contacts, review [Contacts Data Model](/docs/concepts/objects/contacts/contacts-data-model.md) to understand identifiers, schema, and system rules.

<details>

<summary>Related Content</summary>

* [Contacts](/docs/concepts/objects/contacts.md)
* [Contacts Data Model](/docs/concepts/objects/contacts/contacts-data-model.md)
* [Contact Permissions ](/docs/concepts/objects/contacts/contact-permissions.md)
* [Objects](/docs/concepts/objects.md)
* [Records](/docs/concepts/objects/records.md)
* [Custom Fields](broken://pages/6rrJeEIzfjMAZY62pfmc)

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/concepts/objects/contacts/contacts-core-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.