33.1 Roles and Permissions Overview

AIUNIFY Leads uses Roles and Permissions to determine what authenticated Staff Members can see and what operations they can perform.

A Role groups permissions together so access can be assigned according to responsibilities instead of configuring every Staff Member independently.

33.2 Access to Roles

The Roles workspace is located under Settings and is protected by the roles_view permission.

Additional confirmed Role permissions include:

Permission	Purpose
roles_view	View the Roles workspace.
roles_create	Create Roles.
roles_edit	Edit eligible Roles.
roles_delete	Delete eligible Roles.
assign_role	Assign Roles and applicable login access through Staff Member management.

33.3 Role Information

The confirmed Role data structure includes:

1. Name.
2. Display Name.
3. Description.
4. Permissions.

The Roles table displays Role Name, Description, and available Actions.

33.4 Creating a Role

An authorized user can select Add from the Roles workspace.

The confirmed server validation requires:

1. A Role Name.
2. A unique internal Role Name.
3. A permission selection.

The protected internal Role Name admin cannot be used to create another normal Role.

33.5 Module-Grouped Permissions

The Role editor organizes Permissions by Module.

When a Module is selected, its available permission groups are displayed with checkboxes so an administrator can decide what that Role can do within that Module.

Common permission types include operations such as:

1. View.
2. Create.
3. Edit.
4. Delete.
5. Specialized actions such as Assign Role or AI access where defined.

33.6 Saving Role Permissions

When a Role is created or updated, AIUNIFY Leads converts the selected permission identifiers and synchronizes those permissions with the Role.

This means removing a checked permission from a Role can remove the associated capability from users relying on that Role.

Important: Review all selected permissions before saving a Role used by active Staff Members.

33.7 Protected Admin Role

The source contains a built-in Role whose internal name is admin.

The application explicitly protects this Role.

If an edit is attempted, the confirmed response is:

Admin role cannot be edited

If deletion is attempted:

Admin role cannot be deleted

The Roles interface also identifies that the Administrator has all permissions by default.

33.8 Assigning Roles to Staff Members

Roles become operational when they are associated with Staff Members.

Within Staff Member management, Role assignment is restricted to users with the assign_role capability or administrative authority.

A Staff Member intended to log in should have:

1. Allow Login enabled.
2. An appropriate Role.
3. A valid Password.
4. An appropriate Active/Inactive account Status.

33.9 Why Menus Can Differ Between Staff Members

Many AIUNIFY Leads routes and menu items have explicit permission requirements.

For example, a user without the required permission may not see a management area that another user can see.

This is expected permission behavior and does not automatically indicate a software error.

33.10 Module Permission Operations

The application also contains administrative operations for:

1. Retrieving module-wise permissions.
2. Retrieving Roles with Module Permissions.
3. Seeding Module Permissions.
4. Toggling individual permissions.
5. Bulk-updating Module Permissions.
6. Bulk-updating permissions across Roles.

These operations should be limited to authorized administrators because a bulk permission change can affect several users at once.

33.11 Least-Privilege Role Design

When creating Roles, grant only the permissions needed for the person's responsibilities.

For example, a Staff Member who only updates website content may not need access to:

1. Staff Member administration.
2. Role management.
3. Company-wide settings.
4. AI configuration settings.

33.12 Recommended Role Workflow

1. Define the business responsibility for the Role.
2. Create a clear Role Name and Description.
3. Review permissions Module by Module.
4. Select only required capabilities.
5. Save the Role.
6. Assign it only to the Staff Members who need it.
7. Test the Staff Member's access.
8. Review Roles periodically as responsibilities change.