# Record Permissions

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

**Purpose:** Explains how <code class="expression">space.vars.entity</code>-level permissions govern visibility and actions across the platform and how they intersect with <code class="expression">space.vars.object</code> permissions, relationships, teams, <code class="expression">space.vars.automations</code>, and APIs.
{% endhint %}

## Overview

<code class="expression">space.vars.entity</code> permissions determine who can see and act on <code class="expression">space.vars.entity</code>s within an <code class="expression">space.vars.object</code>.

Permissions are evaluated through a layered model:

1. <code class="expression">space.vars.object</code>-level access
2. <code class="expression">space.vars.entity</code>-level scope
3. Action permissions (single and bulk)
4. Field-level permissions

Each <code class="expression">space.vars.object</code> supports two primary <code class="expression">space.vars.entity</code> scopes:

* **All Records**
* **My Associated Records**

These scopes can be assigned different access levels within a Permission Group. <code class="expression">space.vars.entity</code> permissions are critical for:

* Controlling data visibility
* Governing bulk operations
* Managing <code class="expression">space.vars.automation</code> behavior
* Preserving archive integrity and audit history

For more information on how permissions relate to <code class="expression">space.vars.object</code>s, review [Object Permissions](/docs/concepts/objects/object-configuration/object-permissions.md).

***

## Record Permissions

<code class="expression">space.vars.entity</code>-level permissions are 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>.

These permissions determine whether users can:

* View All <code class="expression">space.vars.entity</code>s or only associated <code class="expression">space.vars.entity</code>s
* Edit, Create, Delete or Unarchive <code class="expression">space.vars.entity</code>s
* Access <code class="expression">space.vars.entity</code> views and actions (single or bulk)
* Modify <code class="expression">space.vars.automations</code>
* Configure default field permissions

These permissions are configured per <code class="expression">space.vars.object</code> and can vary across different Permission Groups. For example:

* Two <code class="expression">space.vars.object</code>s may both be visible to a user, but only one allows <code class="expression">space.vars.entity</code> creation.
* One <code class="expression">space.vars.object</code> may allow exports while another blocks exports.
* A user may be able to view <code class="expression">space.vars.entity</code>s but not archive or upload them.

### How Configuration and Record Permissions Interact

<code class="expression">space.vars.object</code> configuration permissions and <code class="expression">space.vars.entity</code> data permissions control different behaviors.

| **Object Configuration Permissions** | <code class="expression">space.vars.object</code> structure and configuration                                                  | <ul><li>Edit <code class="expression">space.vars.object</code> settings</li><li>Configure fields</li><li>Customize layouts</li><li>Manage <code class="expression">space.vars.object</code>-level permissions</li></ul>                                                                                                             | <ul><li>Visibility of individual <code class="expression">space.vars.entity</code>s</li><li><code class="expression">space.vars.entity</code>-level actions</li></ul> |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Record Permissions**               | <code class="expression">space.vars.entity</code> data and actions within an <code class="expression">space.vars.object</code> | <ul><li>View <code class="expression">space.vars.entity</code>s within an association scope (All or My Associated)</li><li>Create, edit, archive, delete <code class="expression">space.vars.entity</code>s</li><li>Perform single-<code class="expression">space.vars.entity</code> actions</li><li>Perform bulk actions</li></ul> | Editing <code class="expression">space.vars.object</code> 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 <code class="expression">space.vars.entity</code>s.
* A user may see records but be unable to edit the <code class="expression">space.vars.object</code> configuration.
* API calls may return empty results if record-level access is restricted, even when <code class="expression">space.vars.object</code> visibility is enabled.

When troubleshooting access issues, verify both <code class="expression">space.vars.object</code> configuration permissions and <code class="expression">space.vars.entity</code> data permissions.

***

## How Record Permissions Work

Each <code class="expression">space.vars.object</code> 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 <code class="expression">space.vars.entity</code>s
* Create/Edit access to My Associated <code class="expression">space.vars.entity</code>s

This allows broad visibility while restricting modification rights to associated records.

<details>

<summary>Configuring Record Permissions</summary>

#### 1. Select settings in Kizen's navigation

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

#### 2. Go to Team, Roles, & Permissions

Navigate to the **Permissions Group** subtab.

<figure><img src="/files/qgfAE4fo4A4R9XOUA0Fc" alt=""><figcaption></figcaption></figure>

#### 3. Select New Permission Group

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

#### **4. Scroll down and toggle on the Record Permissions you want to add.**

In the example shown, **Custom Object - Products** is selected.

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

#### 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.

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

#### 6. Edit permissions for your Record

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

You can now edit permissions on your <code class="expression">space.vars.entity</code>s.

</details>

### 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 <code class="expression">space.vars.entity</code>-level deletion or archive capability for that scope.

### What “My Associated Records” Means

“My Associated <code class="expression">space.vars.entity</code>s” grants access only to <code class="expression">space.vars.entities</code> where the user is the owner, explicitly assigned as a team member, or inherits access through a defined relationship.

Association may include:

* <code class="expression">space.vars.entity</code> ownership (Owner field)
* Explicit team association
* Relationship-based inherited association

Associations determine whether a record falls within a user’s “My Associated <code class="expression">space.vars.entity</code>s” 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](/docs/concepts/objects/object-configuration/object-relationships.md) for details on how relationship modeling affects inherited access.

#### Unarchive Permissions

Unarchive permissions are explicitly separated into:

* Unarchive Any <code class="expression">space.vars.entity</code>
* Unarchive My <code class="expression">space.vars.entity</code>s

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 <code class="expression">space.vars.entity</code>s do not appear in active <code class="expression">space.vars.entity</code> views.

#### Record Creation

<code class="expression">space.vars.entity</code> creation is controlled separately through: Create New <code class="expression">space.vars.entity</code>s

Create permission is not automatically implied by other scope settings and must be explicitly granted.

***

## Record-Specific Permission Areas

<code class="expression">space.vars.entity</code> permissions are configured inside Permission Groups and intersect with <code class="expression">space.vars.object</code>-level configuration.

### Record Overview Permissions

Access to <code class="expression">space.vars.entity</code> view types is permissioned separately from record visibility. Under <code class="expression">space.vars.entity</code> 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-<code class="expression">space.vars.entity</code> permissions control actions performed on an individual <code class="expression">space.vars.entity</code>. These permissions determine which action controls appear on the <code class="expression">space.vars.entity</code> detail page.

Single-<code class="expression">space.vars.entity</code> permissions include:

* Modify <code class="expression">space.vars.automation</code>
* Team Associations
* View Timeline

For Contact <code class="expression">space.vars.entity</code>s, additional single-<code class="expression">space.vars.entity</code> actions are available, including:

* Send Single Message (email or SMS)
* Manage Subscription Status
* Access communication history

For more details, see [Contact Permissions](/docs/concepts/objects/contacts/contact-permissions.md).

### Agentic Workflow Overlap

Starting an <code class="expression">space.vars.automation</code> generally requires Create/Edit access to the <code class="expression">space.vars.entity</code>.

<code class="expression">space.vars.automations</code> execute in a separate permission context. Users who can modify <code class="expression">space.vars.automations</code> may be able to cause record changes that exceed their normal UI editing permissions.

Custom Actions can expose specific <code class="expression">space.vars.automations</code> and may allow execution with more limited access. Permission to modify <code class="expression">space.vars.automations</code> should be treated as an elevated capability. For more detail, see Agentic Workflow Actions **(Topic Coming Soon)**.

### Record-Specific Bulk Actions

Bulk permissions are grouped separately under **Perform Bulk Actions**.

Bulk permissions include:

* Change Field Value
* Modify <code class="expression">space.vars.automation</code>
* 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 <code class="expression">space.vars.entity</code>s, they should be granted intentionally and aligned with appropriate scope access.

***

## Field-Level Permissions Interaction

<code class="expression">space.vars.entity</code> permissions operate alongside field-level permissions.

Field-level permissions are evaluated after <code class="expression">space.vars.entity</code>-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 <code class="expression">space.vars.entity</code>-level access, certain fields may remain hidden or read-only.&#x20;

Files include a specific Delete permission at the field level that enables hard deletion of a file rather than simply unlinking it from a <code class="expression">space.vars.entity</code>.

***

## Record Permissions in API Responses

<code class="expression">space.vars.entity</code> permissions are enforced consistently across the UI and APIs. Effective permissions are evaluated at request time.

API responses include an `access` <code class="expression">space.vars.object</code> indicating <code class="expression">space.vars.entity</code>-level permissions (such as view, edit, remove). If a user lacks permission:

* <code class="expression">space.vars.entity</code>s may not appear in search results
* Update operations may fail
* Action-based operations may be rejected

Most <code class="expression">space.vars.entity</code> APIs require specifying which fields to return rather than returning all fields by default. For endpoint details, see [Record APIs](/docs/concepts/objects/records/records-apis.md).

***

## Important Considerations

Keep the following in mind when configuring or troubleshooting record permissions:

* Platform-level <code class="expression">space.vars.object</code> access does not imply <code class="expression">space.vars.entity</code>-level access.
* Access to a record does not automatically grant access to view modes, single-<code class="expression">space.vars.entity</code> actions, bulk operations, or field-level editing.
* Association modeling directly impacts visibility.
* <code class="expression">space.vars.automation</code> and bulk permissions can significantly expand user impact.
* Missing <code class="expression">space.vars.entity</code>s 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](/docs/concepts/objects/records/records-apis.md) to understand how <code class="expression">space.vars.entities</code> are created, retrieved, updated, archived, and managed programmatically or you can continue exploring other <code class="expression">space.vars.entities</code> documentation with the topics below:

<details>

<summary>Related Topics</summary>

* [Records](/docs/concepts/objects/records.md)
* [Record Operations](broken://pages/I9VbT9OrruO3QISn2RHF)
* [Records Core Concepts](/docs/concepts/objects/records/records-core-concepts.md)
* [Records Data Model](/docs/concepts/objects/records/records-data-model.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/records/record-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.