A dashboard user is anyone who signs into the Leena AI dashboard to build, operate, or administer the platform. This is distinct from a bot user — the employee who talks to the assistant. This page covers how to add and manage dashboard users, how to organize them into groups, and what each role grants.

Watch the tutorial

Where to find it

Open the Admin Console from the hamburger menu at the left of the Unified Dashboard, then go to Dashboard settings → Dashboard users.

The page has two tabs:

• Users — individual dashboard accounts
• User groups — named collections of users that share a set of roles

Adding dashboard users

Users can be added one at a time or in bulk. Both options sit at the top right of the page.

Adding users one at a time

1. Click Add user.

   

2. Fill in the user's details and assign at least one role.

   

3. Click Add user to save.

The account is created and an invitation email goes out. The user appears in the table with Invited status until they complete verification.

Adding users in bulk

1. Click Bulk upload.

2. Download the template and fill in the details of the users you want to create.

   

3. Upload the completed file using Select a file or drag and drop here.

4. The file is validated as soon as it's selected. You'll see a confirmation of how many rows passed — for example, 18 of 20 employees data validated successfully.

If every row is valid

The upload proceeds directly. Accounts are created and invitation emails are sent to all of them.

If some rows have errors

The primary button changes to Preview, which opens a review screen showing every row from your file alongside the specific errors found. On that screen you can:

• Filter the list by All, rows with no errors, or rows with errors
• Search for a specific row
• Import only the rows that passed validation

Importing while errors are present asks you to confirm first. Rows with errors are skipped — correct them in your file and upload again to add those users.

User status

Each user's status appears in the table:

An account can additionally be locked after repeated failed sign-in attempts. Locked accounts get an Unlock user action in the row menu.

Actions on a user

Click the context menu (vertical dots) on any row.

A deactivated user's menu collapses to a single Activate action — the other options return once the account is active again.

Acting on several users at once

Select users with the checkboxes to reveal a bulk action bar.

• Invite again — resends invitations to everyone selected
• Activate or Deactivate — the button shown depends on your selection. Activate appears when every selected user is deactivated; otherwise Deactivate appears, and it stays disabled unless all selected users are currently active. Mixed selections can't be toggled in one go
• Remove — permanently deletes the selected users

Editing roles, resetting passwords, and unlocking are per-user actions and aren't available in bulk.

User groups

Groups let you assign roles once and have every member inherit them. This is the recommended approach for teams and departments — adding someone to the group grants their access, and removing them revokes it, with no per-user edits.

Switch to the User groups tab to see all groups, with their description, assigned roles, creation date, and member count.

Creating a group

1. Click to create a group.
2. Enter a Group name (required) and an optional Description.
3. Select the Roles the group grants — at least one is required.
4. Create the group, then assign members to it.

Editing and removing groups

Each row offers Edit and Delete. Editing lets you change the name, description, roles, and membership. Groups can also be deactivated, which revokes the access they grant while preserving the group and its history for audit purposes.

---

Roles and permissions

The dashboard uses Role-Based Access Control (RBAC). Permissions come from roles that are scoped to specific applications — Case Management, Analytics, AI Colleague Studio, Knowledge Management, and so on.

Two foundational principles:

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

How access is evaluated

Access is checked in three layers:

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

Role catalog

Admin Console administration

Admin Console access is delegated through job-based roles. Each opens a defined set of sections, so channel setup, compliance work, and template management can be handed to different people without granting full platform administration.

Two boundaries are worth knowing, because both are enforced rather than cosmetic:

• Setup belongs to System Admin alone. Channel & Authentication Setup Manager configures authentication but cannot open Dashboard settings → Setup.
• Logs belongs to Audit & compliance manager alone. No other delegated role reaches the log screens.

Hiding a section also blocks it. Opening a restricted page by typing its URL returns an access-denied screen rather than an empty page, so a bookmark shared between admins with different roles will not work for both.

Case Management

Employee onboarding / offboarding

Knowledge & documents

AI Colleague Studio (including workflows)

Analytics

Employee Relationship Management

Engagement & notifications

Roles no longer assigned

These roles are retired and should not be given to new users. Existing holders keep their access through the replacement role:

Legacy & special-purpose roles

Available for backward compatibility with existing deployments, but not recommended for 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 roles — Admin and Builder.

• AI Colleague Studio Admin has full control over everything in the Studio: every AI Colleague, every workflow, all connections and settings, and the complete run history.
• AI Colleague Studio Builder is a scoped creator. Each AI Colleague has a list of builders (owners); a Builder's rights extend to the colleagues they're assigned to and the workflows belonging to those colleagues. Role changes and builder assignments take effect on the user's next dashboard request.

Workflow scoping

Every workflow carries a scope:

Access by role and scope:

Additional rules:

• Scope changes are restricted. Only an Admin can promote an AIC-scoped workflow to Global. An unscoped workflow can be attached to an AI Colleague by anyone who can edit it, or promoted to Global by an Admin. Reassigning a workflow between AI Colleagues, or demoting a Global workflow, is not permitted.
• Connections are scoped too. Connections are either global or scoped to an AI Colleague, and a workflow can only be published if its connections are compatible with its scope. Managing connection settings is Admin-level.
• Per-application grants still apply. An Admin can give an individual user fine-grained permissions on a specific workflow — access to one app's reports or admin actions, say — 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.

Migrating from workflow roles

Legacy assignments are still honored, and workflows that existed before scoping remain accessible to the users who could already reach them.

Controls inside each module

On top of platform roles, individual modules apply their own logic:

• AI Colleague Studio — role plus ownership. Access combines the platform role with per-colleague builder assignments and per-workflow scope, as described above.
• Analytics — per-dashboard roles. Beyond the Analytics Admin role, individual dashboards have Owner / Co-owner / Viewer tiers and visibility levels (Restricted, Shared, Public).
• Knowledge Management — ownership and 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 and groups. Agents belong to departments and user groups; ticket visibility is the intersection of role and group membership.

Data-level access

Audience filters provide row-level governance that operates separately from roles. Where roles decide which features a user can open, audiences decide which records appear inside those features.

The practical consequence: two people holding an identical role can see entirely different data. Regional managers with the same role, for example, each see only their own region's tickets.

Auditing

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

Good to know

• Trial and sandbox workspaces ship with a starter set of roles: Helpdesk Admin, Knowledge Management Admin, Analytics Admin, and System Admin.
• Role names are stable identifiers. Renaming default roles requires a controlled migration.
• When access doesn't behave as expected, check enablement first — confirm the application is enabled for the workspace, then confirm the user holds the right role.