Communication Field Types

circle-check

Overview

Communication fields are specialized field types designed to store Contact information used for messaging, notifications, and outreach. Unlike generic text or numerical fields, communication fields include built-in validation and formatting behaviors that help maintain data quality and support reliable system-driven communication.

These fields support:

  • Email messaging and marketing Automation

  • SMS and phone outreach

  • Contact verification and identity matching

  • Integrations with external third-party messaging and voice systems

Using dedicated communication fields instead of generic text fields improves:

  • Data consistency

  • Deliverability and formatting reliability

  • Automation accuracy

  • Integration compatibility

When communication workflows depend on a field, use the appropriate communication field type rather than freeform text.

circle-exclamation

Communication Fields vs. Text Fields

If the value powers outreach, validation, identity, or integration, use a communication field.

Scenario
Use Communication Field
Use Text Field

Sending emails

Email

❌ Text

Sending SMS

❌ Text

Storing Contact identity

Email / Phone

❌ Text

Capturing descriptive notes

Storing non-validated strings

Text


Email

The email field captures validated email addresses and often functions as a primary Contact identifier across communication, Automation, and integration workflows.

Only the Contact’s email and Team Member’s email fields can be used for system or Automation emails.

Common Use Cases

Use this field when the value will:

  • Send marketing or transactional emails

  • Trigger email-based Automations

  • Serve as a login or unique Contact identifier

  • Integrate with external email platforms

  • Support lookup or upsert operations by email

The platform validates email formatting at the API and UI layers. Invalid values are rejected (for example, “Enter a valid email address.”), protecting Automation logic and outreach workflows from malformed data.

Behavior Considerations

The email field directly influences identity matching, Automation behavior, and integrations.

  • Format validation is enforced at the API and UI layers

  • Email may function as a unique identifier for Contacts

  • Uniqueness constraints may apply

  • Normalization standards should be defined to ensure consistent matching

Always use an email field instead of a text field when sorting email addresses. Freeform text does not enforce validation and can lead to Automation failures, integration errors, and deliverability issues.


Phone Number

The phonenumber field captures validated telephone Contact data using standardized formatting to support voice, SMS, and telephony integrations.

Only Contact and Team Member phone fields can be used for system calling or SMS workflows.

Common Use Cases

Use this field when the value will:

  • Support outbound or inbound calls

  • Enable SMS messaging

  • Power communication automations

  • Integrate with telephony providers

  • Support Contact verification workflows

Structured phone data improves consistency across Records and reduces formatting errors that can disrupt communication workflows.

Behavior Considerations

The Phone Number field directly impacts delivery reliability, automation behavior, and telephony integrations.

  • Standardized formatting supports downstream systems: Consistent formatting improves integration reliability and reduces communication failures.

  • API and upload values must use E.164 format: When creating or updating phone fields via the API or bulk upload, values must be submitted in E.164 format (for example, +14155552671). E.164 is an international numbering standard that requires a leading +, country code, and full national number, with no spaces or formatting characters. See E.164 for more information.

  • International numbers require a defined convention: Establish requirements for country codes and extensions so integrations do not misinterpret values.

  • Reduce duplicates and ambiguity: If you capture multiple phone numbers (mobile, work, home), make the “primary” number explicit so automations don’t message the wrong channel.

Always use a phonenumber field instead of a text field when storing telephone data. Free form text can introduce formatting inconsistencies that disrupt integrations and messaging workflows.


Additional Information

chevron-rightSchema Design Best Practiceshashtag

Email

Use an email field instead of a text field whenever:

  • The data represents an actual email address

  • Deliverability and formatting matter

  • Automations or integrations depend on the value

Avoid storing email addresses in generic text fields. Freeform text does not enforce validation and can lead to:

  • Failed automations

  • Integration errors

  • Poor deliverability

  • Inconsistent formatting

Validated email data improves automation reliability and protects downstream communication processes.

SMS

Use a dedicated phonenumber field instead of freeform text when:

  • The number will be used for calls or SMS

  • Downstream systems require structured formatting

  • Automations rely on valid phone data

Storing phone numbers in generic text fields can introduce:

  • Inconsistent formatting

  • International number issues

  • Failed SMS or call attempts

  • Integration mismatches

Using the phonenumber field ensures cleaner data and more reliable communication execution.


What’s Next

Before implementing schema changes, review the field-specific documentation and API definitions to ensure compatibility with automation and integration requirements Kizen API. To continue designing effective schemas, review our other Field topics:

Last updated

Was this helpful?