Dashboard Users - Roles & Permissions

Overview

The Leena AI dashboard uses Role-Based Access Control (RBAC) to manage user access. A dashboard user is anyone who signs into the dashboard interface. Their permissions are determined by roles assigned to them, which are scoped to specific applications such as Case Management, Analytics, AI Colleague Studio, or Knowledge Management.

Two foundational principles:

1. Roles are module-specific — access to one application does not grant access to another.
2. Modules implement additional fine-grained controls on top of platform roles — ownership, assignment, department/group membership, and audience filters further shape what a user can see and do.

How Access Control Works

User permissions come from three sources:

A user's effective permissions are the union of all three sources. The system enforces access in layers: module visibility, page access, and individual button/control availability.

Prerequisite: Even a fully privileged user cannot access a module unless that application is enabled for the workspace. Assigning a role has no effect until the module is turned on.

The Permission Model

Access evaluation happens across three layers:

1. Application access — whether the user can open a module
2. Module actions — what granular operations they can perform within the module
3. Data-level access — which specific records they can view, through ownership, assignment, and audience filters

Role Catalog

Administration & Governance

Case Management

Employee Onboarding / Offboarding

Knowledge & Documents

Workflows, Integrations & AI Colleagues studio

AI Colleague Studio — which includes workflow building — is governed by two dedicated roles:

Analytics

Employee Relationship Management

Engagement & Notifications

Legacy & special-purpose roles

These roles remain available for backward compatibility with existing deployments but should not be assigned in new rollouts:

AI Colleague Studio Access in Detail

AI Colleague Studio consolidates AI Colleagues, workflow building, connections, and tools under a single access model with two platform roles — Admin and Builder.

Roles

• AI Colleague Studio Admin — full control over everything in the Studio. Admins see and manage every AI Colleague, every workflow, all connections and settings, and the complete run history.
• AI Colleague Studio Builder — a scoped creator. Each AI Colleague has a list of builders (owners); a Builder's rights extend to the AI Colleagues they are assigned to and the workflows that belong to those colleagues. Role changes and builder assignments take effect on the user's next dashboard request (ownership changes may take a short time to propagate).

Workflow scoping

Every workflow application carries a scope:

Access per role and scope:

Additional rules:

• Scope changes are restricted. An AIC-scoped workflow can be promoted to Global by an Admin only. An unscoped workflow can be attached to an AI Colleague by any user who can edit it, or promoted to Global by an Admin. Reassigning a workflow from one AI Colleague to another, or demoting a Global workflow, is not permitted.
• Connections are scoped too. Connections to external systems are either global or scoped to an AI Colleague; a workflow can only be published if its connections are compatible with its scope. Managing connection settings is an Admin-level permission.
• Per-application permissions still apply. As before, an Admin can grant an individual user fine-grained permissions on a specific workflow application (for example, access to one app's reports or admin actions) without making them an Admin.
• Run history follows scope. Builders see run history and debug detail only for their own AI Colleagues; entries involving other colleagues' skills are withheld or redacted. Admins see everything.

Migration from workflow roles

Legacy role assignments are still honored — a Workflow (V2) Admin retains admin-level workflow access, and a Workflow (V2) Agent behaves like a Builder. Workflows that existed before scoping remain accessible to the users who could already access them.

Dedicated Permissions Inside Each Module

Level 1 — Module-Defined Actions

Each application defines granular actions that form the basis of roles. Examples include:

• Case Management: view, post, delete, restore, smart-comments, analytics, settings, nudge, bulkCreate, pendingApprovals, linkTicket, createTicket
• Settings: view, dashboardUsers, authentication, dataSubjectRequests, botUserManagement, employeeSync, audiences
• Workflows (within AI Colleague Studio): view, create, myTasks, myItems, post, settings, plus per-application grants such as viewApp, editApp, viewReport
• Onboarding/Offboarding: view, post, reports, employees, pendingCandidates, upcomingCandidates
• Audit Logs: auditLogSettings, view-logs
• Analytics (V2): view, settings

Level 2 — Module-Specific Access Control

• AI Colleague Studio — role + ownership: access combines the platform role (Admin vs Builder) with per-colleague builder assignments and per-workflow scope, as described above.
• Analytics — per-dashboard roles: beyond the global Analytics Admin role, individual dashboards have Owner / Co-owner / Viewer tiers and visibility levels (Restricted, Shared, or Public).
• Knowledge Management — ownership & audiences: content has an owner and can have collaborators and reviewers, and knowledge targets specific audiences, so different users see different content.
• Case Management — departments & groups: agents are organized into departments and user groups; ticket visibility is the intersection of role and group membership.

Level 3 — Data-Level Access

Audience filters restrict which records a user sees even within features they can access. Where roles control feature access, audiences control which records appear in data queries.

Data-Level Access (Access Filters & Audiences)

Audience filters provide row-level data governance separate from roles: "Of the data inside this feature, which specific records can this user see?" For example, regional managers holding the same role see only region-specific tickets and data. Two people holding the same role can therefore see different data.

Assigning Roles

Roles are assigned through:

1. Individually — direct role assignment to users
2. In bulk — spreadsheet upload for team onboarding
3. Through groups — recommended for teams and departments; changes propagate automatically

Groups use soft deletion: deleted groups revoke access while preserving audit history.

User Account Statuses & Authentication

Supported authentication methods: local (email/password), SSO (SAML), Google, and Azure AD. System Admin manages policies and IP restrictions.

Auditing

All significant access changes — user creation, role changes, and permission modifications — are recorded in an immutable change log.

Good to Know

• Trial/sandbox workspaces ship with starter roles (Helpdesk Admin, Knowledge Management Admin, Analytics Admin, System Admin).
• Role names are stable identifiers; renaming default roles requires controlled migrations.
• When in doubt, check enablement first — confirm the application is enabled for the workspace and the user holds the appropriate role.