# Object Permissions

{% hint style="success" %}
**Audience:** Admins, Developers, Solution Architects

**Purpose:** Explains how <code class="expression">space.vars.object</code> Permissions control access to <code class="expression">space.vars.object</code>s and their <code class="expression">space.vars.entities</code> across the <code class="expression">space.vars.Kizen\_company\_name</code> platform.
{% endhint %}

## Overview

<code class="expression">space.vars.object</code> permissions determine who can access <code class="expression">space.vars.objects</code> across the platform and who can perform actions within a specific <code class="expression">space.vars.object</code>. These permissions are enforced consistently across the UI, APIs, <code class="expression">space.vars.automations</code>, integrations, and exports.

During <code class="expression">space.vars.object</code> configuration, Related <code class="expression">space.vars.objects</code> appears as Step 5. If Workflows are enabled, it becomes Step 6.

1. General Settings
2. Related Objects
3. Customize Fields
4. Customize Layout
5. <mark style="color:$success;">**Permissions**</mark>

There are two distinct levels of <code class="expression">space.vars.object</code> permissions, and both must be understood to configure access correctly:

1. Platform-level <code class="expression">space.vars.object</code> Permissions (Permission Groups)
2. <code class="expression">space.vars.entity</code>-level Permissions (Permission Groups, but can also be configured inside each <code class="expression">space.vars.object</code>)

Both levels work together to determine a user’s effective access.

***

## Level 1: Platform Object Permissions

<div data-with-frame="true"><figure><img src="/files/coGdTPXQ5obZ6IhLqnOR" alt="" width="563"><figcaption></figcaption></figure></div>

The first and higher-level permissions for <code class="expression">space.vars.objects</code> are configured in **Teams, Roles, and Permissions** (via *Edit Permission Group*). These permissions control whether a user can:

* See <code class="expression">space.vars.objects</code> across the platform
* Create new <code class="expression">space.vars.objects</code>
* Edit <code class="expression">space.vars.object</code> Settings
* Delete <code class="expression">space.vars.objects</code>

Permissions at this level strictly govern access to your ability to edit, create, modify, and view <code class="expression">space.vars.objects</code> across the platform, and are not associated with <code class="expression">space.vars.entity</code> modification or visibility.

For example:

* A user may have permission to view and edit an <code class="expression">space.vars.objects</code> structure or settings, but still be unable to view or create <code class="expression">space.vars.entities</code> inside that <code class="expression">space.vars.object</code>.
* Another user may have permission to view and edit  inside an <code class="expression">space.vars.object</code> but not have access to edit the <code class="expression">space.vars.object</code>'s structure or settings.

### Object Visibility

An <code class="expression">space.vars.object</code> is considered visible to a user when they have **View** permission for that <code class="expression">space.vars.object</code> in their Permission Group or if they have the <code class="expression">space.vars.object</code> <code class="expression">space.vars.entity</code> permission enabled for their group.

If a user does not have **View** permission at this level:

* The <code class="expression">space.vars.object</code> 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 <code class="expression">space.vars.object</code>’s settings or from the Permission Groups Modal. These permissions control which users can access and manage that <code class="expression">space.vars.object</code>’s configuration and what permissions they have within that <code class="expression">space.vars.object</code>.

Both levels work together to determine a user’s effective access. For <code class="expression">space.vars.object</code> Permissions, we'll focus on Level 1.

Review [Record Permissions](broken://pages/uhMfsDTB0PmOzSEoHKUi) for more context on level 2 access.

***

## How Both Levels Work Together

Generally, an admin has permissions at both levels.

| Scenario                                                                                                                                                       | Result                                                                                                                                             |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| User has <code class="expression">space.vars.object</code> visibility (Level 1) but no <code class="expression">space.vars.entity</code> permissions (Level 2) | <code class="expression">space.vars.object</code> appears, but <code class="expression">space.vars.entities</code> cannot be viewed or modified    |
| User has <code class="expression">space.vars.entity</code> permissions (Level 2) but no <code class="expression">space.vars.object</code> visibility (Level 1) | <code class="expression">space.vars.object</code> still appears, and <code class="expression">space.vars.entities</code> 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 <code class="expression">space.vars.object</code>” 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 <code class="expression">space.vars.object</code>, responses include access flags such as:

```json
"access": {
  "view": true,
  "edit": true,
  "remove": true
}
```

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 <code class="expression">space.vars.object</code> access does not imply <code class="expression">space.vars.object</code>-level access.
* Missing <code class="expression">space.vars.entities</code> 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](broken://pages/ZfSbXfWgUab5oeBMU2jp), you’ll learn how <code class="expression">space.vars.entity</code>-level permissions are represented for Contact <code class="expression">space.vars.objects</code> and how they affect create, edit, and bulk actions.

<details>

<summary>Related Topics</summary>

* [Object Core Concepts](/docs/concepts/objects/object-core-concepts.md)
* [Object Data Model](/docs/concepts/objects/object-data-model.md)
* [Object Relationships](/docs/concepts/objects/object-configuration/object-relationships.md)
* [Object Layout Customization](/docs/concepts/objects/object-configuration/object-layout-customization.md)
* [Object APIs](/docs/concepts/objects/object-apis.md)

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/concepts/objects/object-configuration/object-permissions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.