Activity Permissions
Audience: Admins and Technical Builders, Implementors, and Developers
Purpose: Explains how permissions and sharing settings interact for Activities in Kizen so you can configure Activity types, roles, and workflows.
Overview
Activity permissions differ from standard object permissions in several important ways. Understanding these differences is critical when designing activity schemas, configuring sharing rules, and troubleshooting visibility or edit issues.
Activity permissions are determined by:
Activity permissions (Role or User permission group settings such as My vs All, View, Log, Create, Edit, Delete)
Sharing settings on the Activity type
Assignment (user or role)
Object, record, and section permissions for related entities
No single setting controls access in isolation. In this topic, we will cover Activities permissions.
Permission Rules
The following rules apply across all scenarios unless otherwise stated:
If an Activity is assigned to a user or one of their roles, the user can always log it
If a user can see a Scheduled Activity and has Edit permission for it, they can assign it to themselves and log it
“My” permissions are never more restrictive than “All” permissions
Sharing settings can only further restrict access granted by a user’s permission group; they cannot expand or grant additional access
If scheduling is fully denied by permissions, scheduling actions do not appear in the UI
Scheduled Activity Visibility
Visibility for Scheduled Activities depends on assignment, permissions, sharing settings, and whether the Scheduled Activities section is enabled.
Assigned Activities
Users can always:
See Scheduled Activities assigned to themselves
See Scheduled Activities assigned to any of their roles
Log those Activities, regardless of sharing settings
This behavior intentionally overrides standard visibility restrictions to ensure assigned work is always accessible.
Non-assigned Activities
Visibility for Scheduled Activities assigned to other users depends on both permissions and sharing settings:
To see and complete Scheduled Activities assigned to others, a user must have at least View/Log permissions set to All for Activities.
In addition, visibility is affected by:
Scheduled Activity permission scope (My vs All)
Sharing settings on the Activity type
If either the Activity permission scope or the sharing settings restrict access, the Scheduled Activity does not appear.
Disabled Scheduled Activity Permissions
If the Scheduled Activities section is disabled entirely:
No Scheduled Activities appear on record pages or dashboards
This includes Activities assigned to the current user
These rules explain why users may see only their own Scheduled Activities, or none at all, depending on how permissions and sections are configured.
Scheduling Activities
Scheduling Activities is intentionally more restrictive than logging to ensure users cannot create or assign work beyond their permissions.
General Scheduling Requirements
To schedule an Activity, both of the following must be true:
The user’s permissions allow scheduling Activities
The Activity type’s sharing settings allow scheduling
If either condition is not met, scheduling options do not appear in the UI.
Scheduling Activities to Others
Scheduling an Activity for another user or role is allowed only when:
The user has Create/Edit permissions for All Scheduled Activities
The Activity's sharing settings allow scheduling
The user has permission to assign Activities to My Roles.
If any of these conditions are not met, assignment options are hidden.
These rules explain why users may be able to log assigned work but not create or assign new Scheduled Activities.
Logging Activities
Users can always log an activity 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, whether an activity type appears in the Log Activity dropdown depends on configuration. An activity type is only available for manual logging when:
The user has permission to edit that activity type, and
The activity’s sharing settings allow logging
This is why a user may be able to log an assigned activity but not see the same activity type available for manual selection.
Activity Assignment Rules
Assignment controls who is responsible for completing an Activity and is governed by visibility, scheduling permissions, and assignment rights.
Assigning Activities to Roles
Assigning an Activity to a role is allowed when the user has the Assign to My Role(s) permission and the Activity is visible to them.
This permission acts as an override to broader Activity assignment permissions, which allows users with limited Activity permissions to::
Assign an Activity from a role to themselves
Reassign the Activity back to their role if needed
Users cannot assign the Activity to other roles unless they have the appropriate assignment permissions.
Standard visibility rules still apply when assigning Activities to roles. If the user does not have the required assignment permissions, reassignment options are hidden from the UI.
These rules explain why users may be able to view or log an Activity 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.
None
Activity not visible unless assigned
Log/Schedule
Allows logging and scheduling if permissions allow
Edit
Allows editing Scheduled Activities if permissions allow
Admin/Delete
Allows deletion only if permissions allow
Activity Custom Field Permissions
Activities intentionally bypass some standard permission patterns to ensure complete and consistent logging.
Field-level Permissions
Field-level permissions on the custom object fields that Activities mirror are not enforced when viewing or editing Activities. However, object-level permissions are still respected.
This ensures:
Required fields can always be completed
Activities remain structurally complete
Admin-defined schemas are respected
Users can:
View all Activity custom fields for associated objects
Edit all Activity custom fields unless restricted by object-level rules
Mark Activity custom fields as read-only so they can be populated once and remain immutable after a value is set.
Object-level Permissions and Activities
Object-level permissions control whether users can select, change, or view record associations when scheduling or logging Activities.
When Object Permissions are Disabled
If a user does not have access to an object’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.
Scheduled Activities
If a Scheduled Activity was created by another user who has access to the related object:
The existing association is visible but read-only
Associated custom fields are populated from the related record
Custom field values remain editable
This allows users to complete or update Activities without changing protected associations.
No Association
If no related record was selected when the Activity was scheduled:
The association selector is empty and is read-only, which cannot be changed
Associated custom fields are blank
Custom fields behave as standard Activity fields and are editable
These rules preserve data integrity and visibility while allowing users to complete Activities even when they do not have access to the underlying records.
Record-level Permissions
These rules ensure Activities remain flexible and complete while enforcing record-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 Records for an object and the object’s section is enabled:
The association chooser is editable
Users can create new related records
Associated custom fields are editable
This allows users to fully manage associations and related data during Activity submission.
View-only Record Permissions
When a user has View on My Associated Records only for an object and the object’s section is enabled, behavior differs depending on the Activity type.
A Word of Caution
Caution: Carefully review Activity field configurations and sharing settings, as misconfiguration may expose sensitive data or violate organizational data handling policies.
Activity permissions in Kizen are intentionally permissive where logging and completion are concerned, while remaining strict about scheduling, assignment, and cross-record 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 Activity behavior.
What's Next?
Next, continue to Advanced Activity Rules, which explains how conditional logic can be applied to Activities to control field visibility and validation behavior. This section helps you understand:
When Activity fields are shown based on rule conditions
How required fields behave when hidden by rules
How rules are evaluated and enforced across the platform
Last updated
Was this helpful?