Object Permissions
Audience: Admins, Developers, Solution Architects
Purpose: Explains how Object Permissions control access to Objects and their Records across the Kizen platform.
Overview
Object permissions determine who can access Objects across the platform and who can perform actions within a specific Object. These permissions are enforced consistently across the UI, APIs, automations, integrations, and exports.
During Object configuration, Related Objects appears as Step 5. If Workflows are enabled, it becomes Step 6.
General Settings
Related Objects
Customize Fields
Customize Layout
Permissions
There are two distinct levels of Object permissions, and both must be understood to configure access correctly:
Platform-level Object Permissions (Permission Groups)
Record-level Permissions (Permission Groups, but can also be configured inside each Object)
Both levels work together to determine a user’s effective access.
Level 1: Platform Object Permissions
The first and higher-level permissions for Objects are configured in Teams, Roles, and Permissions (via Edit Permission Group). These permissions control whether a user can:
See Objects across the platform
Create new Objects
Edit Object Settings
Delete Objects
Permissions at this level strictly govern access to your ability to edit, create, modify, and view Objects across the platform, and are not associated with Record modification or visibility.
For example:
A user may have permission to view and edit an Objects structure or settings, but still be unable to view or create Records inside that Object.
Another user may have permission to view and edit inside an Object but not have access to edit the Object's structure or settings.
Object Visibility
An Object is considered visible to a user when they have View permission for that Object in their Permission Group or if they have the Object Record permission enabled for their group.
If a user does not have View permission at this level:
The Object does not appear in the UI
It may be omitted from metadata endpoints
API requests involving that object may return empty results or authorization errors
Level 2: Record-Level Permissions
The second level of permissions can be 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.
Both levels work together to determine a user’s effective access. For Object Permissions, we'll focus on Level 1.
Review Record Permissions for more context on level 2 access.
How Both Levels Work Together
Generally, an admin has permissions at both levels.
User has Object visibility (Level 1) but no Record permissions (Level 2)
Object appears, but Records cannot be viewed or modified
User has Record permissions (Level 2) but no Object visibility (Level 1)
Object still appears, and Records can be viewed or modified
User has permissions at both levels
Full access based on the combination of both settings
Misalignment between these two layers is one of the most common causes of:
“Empty Object” experiences
Missing data reports
API responses returning empty results
Confusion about why actions are unavailable
API Behavior and Permissions
Permissions are surfaced directly in API responses so clients can make safe decisions about allowed actions.
When fetching an Object, responses include access flags such as:
These values allow applications and integrations to:
Hide edit or delete actions when not allowed
Prevent unauthorized writes
Avoid operations that will fail
Safely respond to dynamic permission changes
Structures such as custom_objects and custom_object_entities also include permission indicators that reflect the current user’s effective access.
Important Considerations
Keep the following in mind when configuring or troubleshooting permissions:
Do not assume permissions based on role names. Always evaluate effective permissions.
Platform-level Object access does not imply Object-level access.
Missing Records or fields often indicate permission restrictions, not missing data.
Integrations should always evaluate access flags before attempting write operations.
Permission misconfiguration is a common cause of empty UI states and empty API responses.
What’s Next
In Contact Permissions, you’ll learn how Record-level permissions are represented for Contact Objects and how they affect create, edit, and bulk actions.
Last updated
Was this helpful?