Communication Field Types
Audience: Administrators, Developers, Solution Architects
Purpose: Explains how communication field types capture validated contact data to support messaging, Automation, identity matching, and integrations.
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.
Note: Avoid storing communication data in text fields, as doing so can compromise deliverability, Automation, and identity matching.
Communication Fields vs. Text Fields
If the value powers outreach, validation, identity, or integration, use a communication field.
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
Schema Design Best Practices
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?