Record Permissions
Audience: Admins, Developers, Solution Architects
Purpose: Explains how Record-level permissions govern visibility and actions across the platform and how they intersect with object permissions, relationships, teams, automation, and APIs.
Overview
Record permissions determine who can see and act on Records within an Object.
Permissions are evaluated through a layered model:
Object-level access
Record-level scope
Action permissions (single and bulk)
Field-level permissions
Each Object supports two primary Record scopes:
All Records
My Associated Records
These scopes can be assigned different access levels within a Permission Group. Record permissions are critical for:
Controlling data visibility
Governing bulk operations
Managing automation behavior
Preserving archive integrity and audit history
For more information on how permissions relate to Objects, review Object Permissions.
Record Permissions
Record-level permissions are configured within each individual Object’s settings or from the Permission Groups Modal. These permissions control which users can access and manage that Object’s configuration and what permissions they have within that Object.
These permissions determine whether users can:
View All Records or only associated Records
Edit, Create, Delete or Unarchive Records
Access Record views and actions (single or bulk)
Modify automations
Configure default field permissions
These permissions are configured per Object and can vary across different Permission Groups. For example:
Two Objects may both be visible to a user, but only one allows Record creation.
One Object may allow exports while another blocks exports.
A user may be able to view Records but not archive or upload them.
How Configuration and Record Permissions Interact
Object configuration permissions and Record data permissions control different behaviors.
Object Configuration Permissions
Object structure and configuration
Edit Object settings
Configure fields
Customize layouts
Manage Object-level permissions
Visibility of individual Records
Record-level actions
Record Permissions
Record data and actions within an Object
View Records within an association scope (All or My Associated)
Create, edit, archive, delete Records
Perform single-Record actions
Perform bulk actions
Editing Object structure or settings
Since these permissions are evaluated independently, misalignment can lead to confusing behavior. For example:
A user may be able to modify object settings but see no Records.
A user may see records but be unable to edit the Object configuration.
API calls may return empty results if record-level access is restricted, even when Object visibility is enabled.
When troubleshooting access issues, verify both Object configuration permissions and Record data permissions.
How Record Permissions Work
Each Object includes separate permission rows for:
All [Object Name] Records
My [Object Name] Associated Records
Administrators can assign different access levels to each scope. For example:
View access to All Records
Create/Edit access to My Associated Records
This allows broad visibility while restricting modification rights to associated records.
Configuring Record Permissions
1. Select settings in Kizen's navigation
2. Go to Team, Roles, & Permissions
Navigate to the Permissions Group subtab.
3. Select New Permission Group
4. Scroll down and toggle on the Record Permissions you want to add.
In the example shown, Custom Object - Products is selected.
5. Select the drop-down arrow on the Record Permission you're editing
Selecting the arrow will show a drop-down of the various permissions that can be set.
6. Edit permissions for your Record
You can now edit permissions on your Records.
Tiered Access Levels
Each scope row uses tiered access levels:
None
View
Create/Edit
Delete/All
These levels determine the degree of access within that scope. Delete/All represents the highest access level within a scope row and governs Record-level deletion or archive capability for that scope.
What “My Associated Records” Means
“My Associated Records” grants access only to Records where the user is the owner, explicitly assigned as a team member, or inherits access through a defined relationship.
Association may include:
Record ownership (Owner field)
Explicit team association
Relationship-based inherited association
Associations determine whether a record falls within a user’s “My Associated Records” scope.
An interaction (such as modifying a record or logging activity) generates an association. However, a user can be associated with a record without having directly interacted with it. To learn more, check out Team Interactions in Records (Coming Soon).
See Object Relationships for details on how relationship modeling affects inherited access.
Unarchive Permissions
Unarchive permissions are explicitly separated into:
Unarchive Any Record
Unarchive My Records
Unarchive is not implied by Create/Edit access and must be granted independently.
When a record is archived, its owner and team associations are preserved so that unarchive permissions can be enforced correctly. Archived Records do not appear in active Record views.
Record Creation
Record creation is controlled separately through: Create New Records
Create permission is not automatically implied by other scope settings and must be explicitly granted.
Record-Specific Permission Areas
Record permissions are configured inside Permission Groups and intersect with Object-level configuration.
Record Overview Permissions
Access to Record view types is permissioned separately from record visibility. Under Record Overview, administrators can configure access to:
Chart View
Board View
Quick Filters
Users may have record access but be restricted from specific view modes.
Single Record Actions
Single-Record permissions control actions performed on an individual Record. These permissions determine which action controls appear on the Record detail page.
Single-Record permissions include:
Modify Automation
Team Associations
View Timeline
For Contact Records, additional single-Record actions are available, including:
Send Single Message (email or SMS)
Manage Subscription Status
Access communication history
For more details, see Contact Permissions.
Automation Overlap
Starting an automation generally requires Create/Edit access to the Record.
Automations execute in a separate permission context. Users who can modify automations may be able to cause record changes that exceed their normal UI editing permissions.
Custom Actions can expose specific automations and may allow execution with more limited access. Permission to modify automations should be treated as an elevated capability. For more detail, see Custom Actions (Coming Soon).
Record-Specific Bulk Actions
Bulk permissions are grouped separately under Perform Bulk Actions.
Bulk permissions include:
Change Field Value
Modify Automation
Add Team Associations
Export to CSV
Archive Records
Upload Records
Bulk permissions are configured separately from single-record permissions, but they are constrained by record-level scope access. If a user does not have sufficient scope access (such as Create/Edit or Delete/All), corresponding bulk actions will not be available.
Because bulk operations can affect large numbers of Records, they should be granted intentionally and aligned with appropriate scope access.
Field-Level Permissions Interaction
Record permissions operate alongside field-level permissions.
Field-level permissions are evaluated after Record-level access is granted.
Within a Permission Group, administrators can configure:
Default access level for new fields
Individual field permissions (None, View, Create/Edit)
Field-level permissions apply to both default and custom fields. Even if a user has Record-level access, certain fields may remain hidden or read-only.
Files include a specific Delete permission at the field level that enables hard deletion of a file rather than simply unlinking it from a Record.
Record Permissions in API Responses
Record permissions are enforced consistently across the UI and APIs. Effective permissions are evaluated at request time.
API responses include an access Object indicating record-level permissions (such as view, edit, remove). If a user lacks permission:
Records may not appear in search results
Update operations may fail
Action-based operations may be rejected
Most Record APIs require specifying which fields to return rather than returning all fields by default. For endpoint details, see Record APIs.
Important Considerations
Keep the following in mind when configuring or troubleshooting record permissions:
Platform-level Object access does not imply Record-level access.
Access to a record does not automatically grant access to view modes, single-Record actions, bulk operations, or field-level editing.
Association modeling directly impacts visibility.
Automation and bulk permissions can significantly expand user impact.
Missing Records or fields often indicate permission restrictions, not missing data.
Integrations should evaluate access flags before attempting write operations.
Permission misconfiguration is a common cause of empty UI states and empty API responses.
What’s Next
Next, review Record APIs to understand how records are created, retrieved, updated, archived, and managed programmatically or you can continue exploring other Records documentation with the topics below:
Last updated
Was this helpful?