Permission Templates

Permission Templates define reusable access policies for Workspace Team Members.

A permission policy consists of granular permission grants grouped into functional areas. System-defined role baselines are provided for Owner, Admin, and Agent. Custom templates can then be created and applied according to the Workspace’s permission model.

Permission Architecture

The hierarchy is:

Workspace Role

      ↓

Default Role Template

      ↓

Permission Template

      ↓

Permission Groups

      ↓

Granular Permission Grants

      ↓

Dependency Rules

Default Role Templates

Owner

The Owner has immutable full system access.

Owner permissions are enforced by role and are not treated as a normal editable permission template.

Admin

The Admin default policy is:

FULL_PERMISSIONS

The default Admin configuration grants the complete available permission set.

Agent

The Agent default policy is:

AGENT_DEFAULT_PERMISSIONS

The verified implementation provides the Agent baseline with the configured Agent-level grants.

Custom Permission Templates

Custom templates are represented by the UserPreDefinedPermission structure.

FieldTypeDescription
idstringTemplate identifier.
policyNamestringDisplay name of the template.
policyobjectMap of permission keys to boolean grants.
createdAtISO-8601 timestampTemplate creation timestamp.
updatedAtISO-8601 timestampLast modification timestamp.

Permission Groups

The dashboard exposes ten permission groups:

1. Team Members

Group ID:

members

Root permission:

team-access

Covers Team Member listing, details, role management, blocking, and removal.

2. Invites & Pending

Group ID:

invitations

Covers pending invitations, member invitations, invitation resending, and invitation cancellation.

3. Permissions & Access Control

Group ID:

permissions

Covers permission viewing, editing, and Permission Template management.

4. Conversation View

Group ID:

conversation

Root permission:

conversation-access

Covers inbox and Conversation visibility, including assigned, resolved, and mention-related views.

5. Conversation Management

Group ID:

conversation-management

Covers assignment, unassignment, resolution, deletion, and transcript operations.

6. Guest & Activity

Group ID:

guests

Covers Visitor detail, active Visitor, and Visitor activity access.

7. Messages

Group ID:

message

Covers message viewing, sending, replying, mentioning, attachments, audio messages, and internal notes.

8. Saved Replies

Implementation permission group ID:

cannedResponse

Root permission:

canned-response-access

The implementation retains canned-response-* permission keys even though the product terminology is Saved Replies.

9. Reports & Analytics

Group ID:

reports

Root permission:

reports-access

Covers analytics overview, Conversation reporting, Team performance, Customer insights, Live Monitor, and export functionality.

10. Workspace Settings

Group ID:

settings

Root permission:

settings-access

Covers Channel management, Team management, audit/login activity, notification settings, notification history, and Workspace creation capabilities.

The ten UI groups are implementation-verified from the permission configuration and dashboard accordion structure.

Permission Dependency Rules

Permission changes are subject to dependency rules.

Permission Editing

Enabling:

permission-edit

requires:

permission-view = true

Permission Template Management

Creating, editing, or deleting Permission Templates requires:

permission-templates-view-use = true

Message Actions

Message reply, mention, attachment, audio, and internal-note actions require:

message-send = true

and:

message-view = true

Saved Reply Management

Saved Reply create, update, or delete operations require:

canned-response-view = true

Team Member Management

Team Member detail, role, block, or delete actions require:

member-list-view = true

Root Permissions

Root access permissions act as cascading access gates for their child permissions.

For example:

conversation-access

       ↓

Conversation View permissions

and:

canned-response-access

       ↓

Saved Reply permissions

Need Help?

Email: support@ysdesk.com

Documentation: https://docs.ysplugins.com/ys-desk

Next