# Activity Permissions

{% hint style="success" %}
**Audience:** Admins, Technical Builders, Implementors, and Developers

**Purpose:** Explains how permissions and sharing settings interact for <code class="expression">space.vars.activities</code> in <code class="expression">space.vars.Kizen\_company\_name</code> so you can configure <code class="expression">space.vars.activity</code> types, roles, and workflows.
{% endhint %}

## Overview

<code class="expression">space.vars.activity</code> permissions differ from standard <code class="expression">space.vars.object</code> permissions in several important ways. Understanding these differences is critical when designing activity schemas, configuring sharing rules, and troubleshooting visibility or edit issues.

<code class="expression">space.vars.activity</code> permissions are determined by:

* <code class="expression">space.vars.activity</code> permissions (Role or User permission group settings such as My vs All, View, Log, Create, Edit, Delete)
* Sharing settings on the <code class="expression">space.vars.activity</code> type
* Assignment (user or role)
* <code class="expression">space.vars.object</code>, <code class="expression">space.vars.entity</code>, and section permissions for related entities

No single setting controls access in isolation. In this topic, we will cover <code class="expression">space.vars.activities</code> permissions.

### Permission Rules

The following rules apply across all scenarios unless otherwise stated:

1. If an <code class="expression">space.vars.activity</code> is assigned to a user or one of their roles, the user can always log it.
2. If a user can see a Scheduled <code class="expression">space.vars.activity</code> and has Edit permission for it, they can assign it to themselves and log it.
3. “My” permissions are never more restrictive than “All” permissions.
4. Sharing settings can only further restrict access granted by a user’s permission group; they cannot expand or grant additional access.
5. If scheduling is fully denied by permissions, scheduling actions do not appear in the UI.

***

## Scheduled Activity Visibility

Visibility for Scheduled <code class="expression">space.vars.activities</code> depends on assignment, permissions, sharing settings, and whether the Scheduled <code class="expression">space.vars.activities</code> section is enabled.

{% columns %}
{% column %}

#### Assigned <code class="expression">space.vars.activities</code>

Users can always:

* See Scheduled <code class="expression">space.vars.activities</code> assigned to themselves,
* See Scheduled <code class="expression">space.vars.activities</code> assigned to any of their roles,
* Log those <code class="expression">space.vars.activities</code>, regardless of sharing settings.

This behavior intentionally overrides standard visibility restrictions to ensure assigned work is always accessible.
{% endcolumn %}

{% column %}

#### Non-assigned <code class="expression">space.vars.activities</code>

Visibility for Scheduled <code class="expression">space.vars.activities</code> assigned to other users depends on both permissions and sharing settings:

To see and complete Scheduled <code class="expression">space.vars.activities</code> assigned to others, a user must have at least **View/Log** permissions set to **All** for <code class="expression">space.vars.activities</code>.

In addition, visibility is affected by:

* Scheduled <code class="expression">space.vars.activity</code> permission scope (My vs All),
* Sharing settings on the <code class="expression">space.vars.activity</code> type.

If either the <code class="expression">space.vars.activity</code> permission scope or the sharing settings restrict access, the Scheduled <code class="expression">space.vars.activity</code> does not appear.
{% endcolumn %}
{% endcolumns %}

### Disabled Scheduled Activity Permissions

If the Scheduled <code class="expression">space.vars.activities</code> section is disabled entirely:

* No Scheduled <code class="expression">space.vars.activities</code> appear on <code class="expression">space.vars.entity</code> pages or <code class="expression">space.vars.dashboards</code>.
* This includes <code class="expression">space.vars.activities</code> assigned to the current user.

These rules explain why users may see only their own Scheduled <code class="expression">space.vars.activities</code>, or none at all, depending on how permissions and sections are configured.

***

## Scheduling Activities

Scheduling <code class="expression">space.vars.activities</code> is intentionally more restrictive than logging to ensure users cannot create or assign work beyond their permissions.

### General Scheduling Requirements

To schedule an <code class="expression">space.vars.activity</code>, both of the following must be true:

* The user’s permissions allow scheduling <code class="expression">space.vars.activities</code>.
* The <code class="expression">space.vars.activity</code> type’s sharing settings allow scheduling.

If either condition is not met, scheduling options do not appear in the UI.

{% columns %}
{% column %}

### Scheduling <code class="expression">space.vars.activities</code> to Yourself

A user can schedule an <code class="expression">space.vars.activity</code> for themselves only when:

* They have **Create/Edit** permissions for Scheduled <code class="expression">space.vars.activities</code>
* The Activity’s sharing level is set to **Log/Schedule** or higher
  {% endcolumn %}

{% column %}

### Scheduling <code class="expression">space.vars.activities</code> to Others

Scheduling an Activity for another user or role is allowed only when:

* The user has **Create/Edit** permissions for All Scheduled <code class="expression">space.vars.activities</code>
* The <code class="expression">space.vars.activity</code>'s sharing settings allow scheduling
* The user has permission to assign <code class="expression">space.vars.activities</code> to **My Roles**.

If any of these conditions are not met, assignment options are hidden.
{% endcolumn %}
{% endcolumns %}

These rules explain why users may be able to log assigned work but not create or assign new Scheduled <code class="expression">space.vars.activities</code>.

***

## Logging Activities

Users can always log an <code class="expression">space.vars.activity</code> that has been assigned to them, regardless of permissions or sharing settings. This behavior is intentional so assigned work cannot be blocked from completion.

However, users can only create a new logged <code class="expression">space.vars.activity</code> from scratch if the <code class="expression">space.vars.activity</code> type is available to them. Whether an <code class="expression">space.vars.activity</code> type appears in the Log <code class="expression">space.vars.activity</code> dropdown depends on configuration. An <code class="expression">space.vars.activity</code> type is only available for manual logging when:

* The user has permission to edit that <code class="expression">space.vars.activity</code> type, and
* The <code class="expression">space.vars.activity</code>’s sharing settings allow logging

This is why a user may be able to log an assigned <code class="expression">space.vars.activity</code> but not see the same <code class="expression">space.vars.activity</code> type available for manual selection.

***

## Activity Assignment Rules

Assignment controls who is responsible for completing an <code class="expression">space.vars.activity</code> and is governed by visibility, scheduling permissions, and assignment rights.

{% columns %}
{% column %}

#### Assigning <code class="expression">space.vars.activities</code> to Yourself

A user can assign an <code class="expression">space.vars.activity</code> to themselves when:

* They can see the <code class="expression">space.vars.activity</code>, and
* They have permission to schedule <code class="expression">space.vars.activities</code>

If either condition is not met, the option to assign the <code class="expression">space.vars.activity</code> to themselves does not appear.
{% endcolumn %}

{% column %}

#### Assigning <code class="expression">space.vars.activities</code> to Roles

Assigning an <code class="expression">space.vars.activity</code> to a role is allowed when the user has the Assign to My Role(s) permission and the <code class="expression">space.vars.activity</code> is visible to them.

This permission acts as an override to broader <code class="expression">space.vars.activity</code> assignment permissions, which allows users with limited <code class="expression">space.vars.activity</code> permissions to::

* Assign an <code class="expression">space.vars.activity</code> from a role to themselves
* Reassign the <code class="expression">space.vars.activity</code> back to their role if needed

Users cannot assign the <code class="expression">space.vars.activity</code> to other roles unless they have the appropriate assignment permissions.&#x20;

Standard visibility rules still apply when assigning <code class="expression">space.vars.activities</code> to roles. If the user does not have the required assignment permissions, reassignment options are hidden from the UI.
{% endcolumn %}
{% endcolumns %}

These rules explain why users may be able to view or log an <code class="expression">space.vars.activity</code> but not change who it is assigned to.

***

## Activity Share Settings

Share Settings restrict access further after permission groups are applied. It cannot override missing permissions.

| Sharing Level | Effect                                                                                              |
| ------------- | --------------------------------------------------------------------------------------------------- |
| None          | <code class="expression">space.vars.activity</code> not visible unless assigned                     |
| Log/Schedule  | Allows logging and scheduling if permissions allow                                                  |
| Edit          | Allows editing Scheduled <code class="expression">space.vars.activities</code> if permissions allow |
| Admin/Delete  | Allows deletion only if permissions allow                                                           |

***

## Activity Custom Field Permissions

<code class="expression">space.vars.activities</code> intentionally bypass some standard permission patterns to ensure complete and consistent logging.

### Field-level Permissions

Field-level permissions on the <code class="expression">space.vars.object</code> fields that <code class="expression">space.vars.activities</code> mirror are not enforced when viewing or editing <code class="expression">space.vars.activities</code>. However, <code class="expression">space.vars.object</code>-level permissions are still respected.

This ensures:

* Required fields can always be completed
* <code class="expression">space.vars.activities</code> remain structurally complete
* Admin-defined schemas are respected

Users can:

* View all <code class="expression">space.vars.activity</code> <code class="expression">space.vars.fields</code> for associated <code class="expression">space.vars.objects</code>
* Edit all <code class="expression">space.vars.activity</code> <code class="expression">space.vars.fields</code> unless restricted by <code class="expression">space.vars.object</code>-level rules
* Mark <code class="expression">space.vars.activity</code> <code class="expression">space.vars.fields</code> as read-only so they can be populated once and remain immutable after a value is set.

***

## Object-level Permissions and Activities

<code class="expression">space.vars.object</code>-level permissions control whether users can select, change, or view <code class="expression">space.vars.entity</code> associations when scheduling or logging <code class="expression">space.vars.activities</code>.

### When Object Permissions are Disabled

If a user does not have access to an <code class="expression">space.vars.object</code>’s section:

* Association selectors are displayed as read-only
* Existing associations remain visible
* Tooltips explain why the selector cannot be changed

This ensures users can see existing configuration without expanding access.

{% columns %}
{% column %}

#### Scheduled <code class="expression">space.vars.activities</code>

If a Scheduled <code class="expression">space.vars.activity</code> was created by another user who has access to the related object:

* The existing association is visible but read-only
* Associated <code class="expression">space.vars.fields</code> are populated from the related <code class="expression">space.vars.entity</code>
* <code class="expression">space.vars.field</code> values remain editable

This allows users to complete or update <code class="expression">space.vars.activities</code> without changing protected associations.
{% endcolumn %}

{% column %}

#### Logged <code class="expression">space.vars.activities</code>

When logging an <code class="expression">space.vars.activity</code> and the related <code class="expression">space.vars.object</code> section is disabled:

* The association selector is empty and read-only
* No <code class="expression">space.vars.entities</code> can be selected or changed
* Associated <code class="expression">space.vars.fields</code> behave as standard <code class="expression">space.vars.activity</code> fields and remain editable
  {% endcolumn %}
  {% endcolumns %}

### No Association

If no related <code class="expression">space.vars.entity</code> was selected when the <code class="expression">space.vars.activity</code> was scheduled:

* The association selector is empty and is read-only, which cannot be changed
* Associated <code class="expression">space.vars.fields</code> are blank
* <code class="expression">space.vars.fields</code> behave as standard <code class="expression">space.vars.activity</code> fields and are editable

These rules preserve data integrity and visibility while allowing users to complete <code class="expression">space.vars.activities</code> even when they do not have access to the underlying <code class="expression">space.vars.entities</code>.

***

## Record-level Permissions

These rules ensure <code class="expression">space.vars.activities</code> remain flexible and complete while enforcing <code class="expression">space.vars.entity</code>-level access boundaries. Differences between Scheduled and Logged behavior based on when associations are preconfigured versus selected at submission time.

### Create/Edit on my Records

When a user has **Create/Edit** on My Associated <code class="expression">space.vars.entities</code> for an <code class="expression">space.vars.object</code> and the <code class="expression">space.vars.object</code>’s section is enabled:

* The association chooser is editable
* Users can create new related <code class="expression">space.vars.entities</code>
* Associated <code class="expression">space.vars.fields</code> are editable

This allows users to fully manage associations and related data during <code class="expression">space.vars.activity</code> submission.

### View-only Record Permissions

When a user has View on My Associated <code class="expression">space.vars.entities</code> only for an <code class="expression">space.vars.object</code> and the <code class="expression">space.vars.object</code>’s section is enabled, behavior differs depending on the <code class="expression">space.vars.activity</code> type.

{% columns %}
{% column %}

#### **Scheduled** <code class="expression">space.vars.activities</code>

* Pre-selected associations remain editable
* If the user changes the association, they cannot reselect the original <code class="expression">space.vars.entity</code> if it is not otherwise visible to them
* Associated <code class="expression">space.vars.fields</code> still pre-populate and remain editable
  {% endcolumn %}

{% column %}

#### **Logged** <code class="expression">space.vars.activities</code>

* Association options are limited to <code class="expression">space.vars.entities</code> the user can view
* Users cannot select or associate <code class="expression">space.vars.entities</code> outside their visibility
  {% endcolumn %}
  {% endcolumns %}

***

## A Word of Caution

{% hint style="warning" %}
**Caution:** Carefully review Activity field configurations and sharing settings, as misconfiguration may expose sensitive data or violate organizational data handling policies.
{% endhint %}

<code class="expression">space.vars.activity</code> permissions in <code class="expression">space.vars.Kizen\_company\_name</code> are intentionally permissive where logging and completion are concerned, while remaining strict about scheduling, assignment, and cross-<code class="expression">space.vars.entity</code> visibility.

Admins should carefully consider:

* Sharing levels
* Assignment patterns
* Object section permissions
* Required field configurations

Misalignment between these settings is the most common cause of unexpected <code class="expression">space.vars.activity</code> behavior.&#x20;

***

## What's Next?

Next, continue to [Advanced Activity Rules](/docs/concepts/activities/advanced-activity-rules.md), which explains how conditional logic can be applied to <code class="expression">space.vars.activities</code> to control field visibility and validation behavior. This section helps you understand:

* When <code class="expression">space.vars.activity</code> fields are shown based on rule conditions
* How required fields behave when hidden by rules
* How rules are evaluated and enforced across the platform

<details>

<summary>Related Topics</summary>

* [Activities](/docs/concepts/activities.md)
* [Activities Core Concepts](/docs/concepts/activities/activities-core-concepts.md)
* [Activities Data Model](/docs/concepts/activities/activities-data-model.md)
* [Advanced Activity Rules](/docs/concepts/activities/advanced-activity-rules.md)
* [Activities API & Webhooks](/docs/concepts/activities/activities-api-and-webhooks.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/activities/activity-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.