Contact Permissions
Audience: Admins, Developers, Solution Architects
Purpose: Explains how Contact permissions work in Kizen, how they align with Object permissions, and how they control access to creating, editing, viewing, and performing bulk actions on Contact Records.
Overview
Contacts are a special type of Object used to represent people in the platform. Contact permissions determine:
Whether a user can see Contacts across the platform
Whether a user can create, edit, archive, or export Contact Records
Whether a user can perform single or bulk actions on Contacts
How Contact access is enforced across the UI, APIs, automations, integrations, and exports
How Contact Permissions Work
Contact permissions follow the same two-level permission model as other Objects, with additional system-level behavior specific to people, communication, and identity.
Permissions are configured through Teams, Roles, and Permission Groups and govern Contact visibility, record access, and actions such as creating, editing, archiving, uploading, and exporting. In addition, Contacts include Contact field permissions, which control whether users can edit Contact-specific fields and settings that do not apply to Objects.
For full details and examples, see Object Permissions.
Contact-Specific Permission Areas
Contacts represent people, so their permissions include additional controls for communication, subscriptions, and identity-related actions.
Accessing Contact Permission Settings
The Permissions step contains all available Contact permission settings.
All permissions discussed below can be located from this page.
Single-Record Contact Actions
Contacts include permissions that allow users to perform communication and interaction actions on individual Contact Records.
Under Perform Single Record Actions, Contact-specific permissions include:
Send Single Message: Allows sending an email or text message from an individual Contact Record
Modify Automation: Allows starting, pausing, or cancelling automations from the Contact context
Team Associations: Controls access to employee-based associations for Contacts
Subscription Lists: Allows viewing and managing a Contact’s email subscription status, including opt-in and unsubscribe state
View Timeline: Allows viewing message history and interaction activity for a Contact
These actions do not exist for standard Objects because they depend on a Contact’s identity and system-managed communication status.
Having permission to edit a Contact Record does not guarantee that communication actions are available. Actions may still be restricted based on system-managed Contact state, such as email status, suppression, or integration configuration.
Contact-Specific Bulk Actions
Contacts also introduce bulk permissions for communication and subscription workflows that are not available on other Objects. These permissions control whether users can perform communication or subscription-related actions across multiple Contact Records at once.
Under Perform Bulk Actions, Contact-only permissions include:
Send Email: Allows users to send emails to one or more Contacts, subject to email status, suppression rules, and permission checks
Send Text: Allows users to send text messages to one or more Contacts when SMS is configured and the Contact has a valid mobile number
Send Survey: Allows users to send surveys to Contacts as part of bulk communication workflows
Change Tags: Allows users to add or remove tags on one or more Contact Records for categorization and segmentation
Manage Subscription: Allows users to view and update Contact email subscription status, subject to system-managed compliance rules
Unlike generic bulk actions (such as changing field values or exporting Records), these actions are explicitly tied to Contacts and reflect workflows that apply only to people.
Bulk communication actions are still subject to:
Record-level permissions
Field-level access
System-managed Contact state (such as opt-in status or suppression)
Identity and Communication Field Permissions
Contacts expose field-level permissions that directly affect identity and contactability.
When you scroll down further on the page, under Individual Contact Field Permission (Set All), permission controls include:
Email: The primary identifier for a Contact, used to determine email contactability and enable email-based communication and automations
Email Status: A system-managed field that reflects a Contact’s email opt-in and deliverability state and may block email sending regardless of user permissions
Mobile Phone: Determines SMS contactability and enables text messaging and SMS-based automations when configured
Tags: A Contact-specific, dynamic field used for categorization, segmentation, and triggering automations and bulk actions
Timezone: Stores a Contact's local time zone and may be used to schedule or personalize communication timing
Birthday: A date field used for personalization and date-based automations and segmentation
These fields differ from typical Object fields because they:
Determine whether communication actions are allowed
Are referenced by campaigns and automations
May be partially system-managed (for example, Email Status)
Contact Permissions in API Responses
Permissions for Contacts are surfaced directly in API responses, just like other Objects. For more information, see Object Permissions.
Caution: Contact API responses indicate whether the current user can access, edit, create, or perform bulk actions on Contact Records. Contact-specific communication actions may still be restricted by system-managed Contact state (such as email status or suppression), even when these permissions are present.
Important Considerations
When working with Contact permissions, keep the following in mind:
Contacts follow the same permission model as Objects, but support additional system behavior
Platform-level Contact access does not imply Record-level access
Missing Contact Records or fields often indicate permission restrictions, not missing data
Bulk Contact actions are subject to the same Record-level permission checks
Permission misconfiguration is a common source of Contact-related issues in both UI and API workflows
What’s Next
From here, you may want to explore other topics related to Contact Permissions below:
Last updated
Was this helpful?