Dashboard Users, Roles & Permissions

This guide explains how access is managed for users of the Leena AI dashboard: the
roles you can assign, how permissions are evaluated, and the module-specific
controls that sit on top of the platform's roles. It is intended for administrators
who provision dashboard access and for anyone who wants to understand exactly what a
given role can and cannot do.

---

Overview

Access in the Leena AI dashboard is governed by Role-Based Access Control (RBAC).
A dashboard user is any person who signs into the dashboard (as opposed to an
end user who chats with the assistant). What each dashboard user can see and do is
determined by the roles assigned to them.

A role is a named bundle of permissions scoped to a specific application (module),
such as Case Management, Analytics, Workflows, or Knowledge Management. Roles ship
with sensible defaults and can be assigned to individuals, applied through groups, or
supplemented with direct permissions.

Two ideas are worth keeping in mind from the start:

1. Roles are per-module. Access to Case Management does not grant access to
   Analytics; each is controlled by its own role(s).
2. Most modules add their own finer-grained controls on top of the platform role
   — this is covered in detail in Dedicated permissions inside each module.

---

How access control works

The system combines three sources of permission for every user:

A user's effective permissions are the union of everything granted through
these three channels. When a user attempts an action, the system checks their direct
permissions, their assigned roles, and the roles attached to any group they belong to.
If the required permission is found through any of these paths, the action is allowed;
otherwise it is denied.

Enforcement happens in layers. When a user signs in, the dashboard loads the list
of applications they can access along with the specific actions permitted within each.
This drives the experience end to end:

• Module visibility — only applications the user has access to appear in the module
  switcher and navigation.
• Tabs and pages — administrative tabs (e.g. Settings, Reports) are shown only if the
  user holds the matching action; unauthorized routes render an Access Denied screen.
• Buttons and controls — individual actions (create, edit, delete, download, etc.)
  are enabled or disabled based on the user's permissions, often with a tooltip
  explaining why something is unavailable.

Prerequisite — the module must be enabled. Even a fully privileged user cannot
access a module unless that application is enabled for the workspace. If a role's
parent application is not enabled, assigning the role produces an error such as
"The application <AppName> is not enabled for your account." Enable the application
first, then assign the related roles.

---

The permission model at a glance

Access is evaluated across three complementary layers:

1. Application access — Can the user open this module at all? Controlled by whether
   the user holds any role for that application.
2. Module actions — Within a module, what can the user do? Each application defines
   its own granular actions (view, create, delete, settings, etc.). Admin-style roles
   generally receive all actions; Agent/Viewer roles receive a restricted subset.
3. Data-level access — Of the data inside a module, which records can the user see?
   Audience filters restrict visibility to specific segments (e.g. a regional manager
   sees only their region). See Data-level access.

---

Role catalog

The tables below list the default roles available in the dashboard, grouped by
functional area, along with the scope of each role. "Admin" roles typically have full
access to their module; "Agent" and "Viewer" roles are progressively more restricted.

Administration & governance

Case management & support

Employee lifecycle

Knowledge & documents

Automation & AI

Note on AI Colleague Studio roles: unlike most modules, AIC Studio does not use a
single fixed seeded role. Access is capability-gated: an Admin vs Builder
distinction is derived from the user's assigned actions (create, edit, delete, view AI
Colleagues, manage the tools/skills registry, access the debugging console), and an
additional organization-level restriction layer can allow an org to see the module
while limiting which capabilities it can use. See
Dedicated permissions inside each module.

Analytics

Engagement

Other modules

Some modules above (e.g. Change Requests, Tasks) may be marked experimental and are
available only when explicitly enabled for the workspace.

---

Dedicated permissions inside each module

Yes — each module has its own dedicated permissions. In fact, access within a module
is controlled at up to three levels of granularity.

Level 1 — Every module defines its own actions

Each application publishes its own set of actions (granular permissions). A role is
essentially a named bundle of these actions. Admin-style roles are usually granted all
actions for their module (represented internally as a wildcard, .*), while Agent and
Viewer roles receive a curated subset. Representative examples:

This is what differentiates, for example, a Helpdesk Admin (all Case Management
actions) from a Helpdesk Agent (only view, post, edit).

Level 2 — Module-specific access-control systems

Several modules layer their own access-control model on top of the platform role. The
most important ones:

AI Colleague Studio — capability gating. Studio access merges two independent
sources: role gating (an Admin vs Builder distinction derived from the user's
assigned actions such as create/edit/delete/view AI Colleagues, manage the global
tools registry, and access the debugging console) and organization gating (a
bot/org-level restrictions layer that can let an org view the module but block specific
capabilities). Individual buttons and menus are enabled, disabled, or tooltip-explained
accordingly, and module-level access is denied outright if the user lacks view
permission for AI Colleagues.

Analytics — per-dashboard roles. Beyond the global Analytics Admin role (which
gates the Reports module, Analytics Settings, and the ability to create custom
dashboards), each custom dashboard has its own roles:

• Owner — the creator; full control over layout, deletion, and user management.
• Co-owner — can edit the layout and add/remove other users (except the Owner).
• Viewer — can view the dashboard but cannot edit it.

Dashboards also carry a visibility level: Restricted (owner only), Shared
(specific users), or Public (accessible via link, e.g. for TV/presentation mode).

Engage — two-level ACL. Access to engagement data is governed at two levels:

• Bot-Level access — global administrators who see all reports and manage bot-wide
  settings (filters, AI/GPT configuration, etc.).
• Report-Level access — restricted access where users (e.g. department heads, HRBPs)
  see only the segments they are permitted to view.

Engage additionally uses feature flags and fine-grained question-edit permissions to
control exactly which parts of a survey a user may modify.

Document Management System — resource-level grants. In addition to the DMS Admin/Agent
roles, access can be granted, changed, or revoked on a per-folder and per-file basis,
so users only interact with the documents shared with them.

Knowledge Management / Knowledge Base — ownership & audiences. Content carries an
owner (editing ownership can be delegated), and knowledge is targeted to specific
audiences, so the same module surfaces different content to different users.

Level 3 — Data-level access

Finally, even within a module a user can open, audience filters restrict which
records they see. This is covered next.

---

Data-level access (Access Filters & Audiences)

Access filters (audiences) operate on top of the role model to provide row-level data
governance. Where a role answers "Can this user open this feature?", audience filters
answer "Of the data inside this feature, which specific records can this user see?"

For example, two regional managers can hold the same Helpdesk Admin role and open the
same dashboard, yet each sees only the tickets and data relevant to their own region.
Audiences are managed by administrators of the relevant modules (many admin roles include
an audiences permission for exactly this purpose) and are enforced automatically on the
underlying data queries.

---

Assigning roles

Roles can be assigned in three ways, which can be combined:

1. Individually — assign one or more roles directly to a user.
2. In bulk — upload a spreadsheet of users and their designated roles to onboard whole
   teams at once.
3. Through groups — assign roles to a group; every member inherits them automatically.
   Groups are the recommended approach for teams and departments, since membership changes
   propagate access without editing each user.

Groups use a soft-delete model: deleting a group revokes access while preserving the
historical record for auditing.

---

User account statuses & authentication

Every dashboard user has an account status:

The dashboard supports multiple authentication methods, configured per company:
local (email/password), SSO (SAML), Google, and Azure AD. Password
policies, SSO configuration, and IP restrictions are managed by the System Admin under
Settings.

---

Auditing

All significant access changes — user creation, role changes, and permission
modifications — are recorded in an immutable change log that captures the "before" and
"after" state of each change. Critical events are prioritized to support security
monitoring and real-time alerting, giving administrators a complete audit trail for
governance and compliance.

---

Good to know

• Trial / sandbox workspaces are provisioned with a starter set of roles
  (Helpdesk Admin, Knowledge Management Admin, Analytics Admin, and System Admin) so new
  administrators can explore the platform immediately.
• Role names are stable identifiers. Renaming or removing default roles can affect
  existing permission assignments, so changes are handled through controlled migrations
  rather than ad-hoc edits.
• When in doubt, check enablement first. If a user can't see a module they should have
  access to, confirm (1) the application is enabled for the workspace, and (2) the user
  holds a role for that application.