User Management & RBAC

Control who can do what across your organisation with role-based access control.

Overview

InnConnect uses a role-based access control (RBAC) model to govern access to every feature in the admin portal. The system is built around three concepts: roles, permissions, and site access.

7 Built-in Roles

From platform operator to front-line agent. Every user is assigned exactly one role that defines the boundaries of their access.

17 Granular Permissions

Organised into 6 functional groups. Permissions are never assigned individually — they are bundled into roles by design.

Per-Site Scoping

Users can be restricted to specific sites within a tenant, ensuring agents and managers only see the data relevant to their responsibilities.

Permissions are enforced on both the server side and the interface. On the server, Laravel Gates and route middleware reject unauthorised requests before they reach any business logic. On the client, navigation items, buttons, and form actions are hidden when the current user lacks the required permission. This dual enforcement means there is no way to access restricted functionality by manipulating the browser — even if a UI element were somehow visible, the server would reject the action.

Principle of least privilege. Always assign the most restrictive role that still allows a user to perform their duties. A support agent who only handles live chats should have the Agent role — not Tenant Admin. Keeping roles narrow limits the blast radius of compromised credentials and satisfies ISO 27001 access control requirements.

Roles

InnConnect ships with seven predefined roles. Every user has exactly one role, and roles cannot be customised or combined. The table below lists them from most privileged to least privileged.

Role	Slug	Description
Super Admin	`super_admin`	Full platform access including tenant management. Reserved for InnConnect platform operators. Bypasses all permission checks via a global gate override.
Tenant Admin	`tenant_admin`	Full access within a single tenant. Manages users, sites, billing, AI settings, knowledge base, and commerce. The default role for the account owner.
Compliance Officer	`compliance_officer`	Manages GDPR requests, data retention policies, breach register, and data classification. Can view audit logs, chat history, and AI monitoring for compliance reviews.
DPO	`dpo`	Data Protection Officer. Manages GDPR requests and breach records. Can view audit logs, chat history, and classify data. Narrower scope than the Compliance Officer — no retention management.
KB Manager	`kb_manager`	Creates, edits, approves, and classifies knowledge base articles. No access to billing, compliance, user management, or chat data.
Auditor	`auditor`	Read-only access to audit logs, chat history, and AI monitoring. Cannot modify any data. Intended for internal auditors or external reviewers.
Agent	`agent`	Handles live chat escalations and views chat history. The most restricted role — designed for front-line customer support staff.

Super Admin is platform-level. The super_admin role exists for InnConnect operators who manage the multi-tenant platform itself. It should never be assigned to tenant users. If you need full control within your organisation, use tenant_admin instead.

Permission Matrix

The table below shows all 17 permissions grouped into 6 functional areas. A checkmark (✓) indicates the role holds that permission. The super_admin role bypasses all checks and is included for completeness.

Permission	Slug	Super<br>Admin	Tenant<br>Admin	Compliance<br>Officer	DPO	KB<br>Manager	Auditor	Agent
Administration
Manage Users	`manage-users`	✓	✓	–	–	–	–	–
Manage Sites	`manage-sites`	✓	✓	–	–	–	–	–
Manage Tenants	`manage-tenants`	✓	–	–	–	–	–	–
Manage Billing	`manage-billing`	✓	✓	–	–	–	–	–
Compliance
Manage GDPR	`manage-gdpr`	✓	–	✓	✓	–	–	–
View Audit Log	`view-audit-log`	✓	–	✓	✓	–	✓	–
Manage Retention	`manage-retention`	✓	–	✓	–	–	–	–
Manage Breaches	`manage-breach`	✓	–	✓	✓	–	–	–
Classify Data	`classify-data`	✓	–	✓	✓	–	–	–
Knowledge Base
Manage Knowledge Base	`manage-kb`	✓	✓	–	–	✓	–	–
Approve Knowledge Base	`approve-kb`	✓	✓	–	–	✓	–	–
Classify KB Content	`classify-kb`	✓	–	–	–	✓	–	–
Chat
View Chat History	`view-chat-history`	✓	✓	✓	✓	–	✓	✓
Handle Escalations	`handle-escalations`	✓	✓	–	–	–	–	✓
AI
Manage AI Settings	`manage-ai-settings`	✓	✓	–	–	–	–	–
View AI Monitoring	`view-ai-monitoring`	✓	✓	✓	–	–	✓	–
Commerce
Manage Commerce	`manage-commerce`	✓	✓	–	–	–	–	–

Super Admin bypasses all gates. The super_admin role uses a Gate::before() callback that returns true for every permission check. It is shown with checkmarks in every column for clarity, but it does not actually hold individual permission records in the database.

User List

The Users page displays four stat cards at the top — Total Users, Active, Inactive, and Roles in Use — followed by a table of all team members within your tenant. Each row shows the user's name, email, assigned role, account status, and last login timestamp.

Total Users

The total number of user accounts in your tenant, including active, inactive, and pending invitations.

Active

Users who can currently log in and access the admin portal.

Inactive

Deactivated accounts. These users cannot log in but their data is retained for audit purposes.

Roles in Use

The number of distinct roles currently assigned across your team.

Screenshot: User list page with stat cards (Total Users, Active, Inactive, Roles in Use), role badges, and active/inactive status indicators

Inviting Users

Any user with the manage-users permission can invite new team members. Invited users receive an email containing a temporary password and a link to the admin portal. The temporary password must be changed on first login before the user can access any functionality.

How to invite a new team member

Navigate to Users in the left sidebar and click Invite User.
Enter the user's full name and email address. The email must be unique across the tenant.
Select a role from the dropdown. Refer to the Roles table to choose the least-privileged role that meets the user's needs.
Under Site Access, select which sites this user should have access to. Leave all sites unchecked to grant access to all current and future sites within the tenant (recommended only for admin-level roles).
Click Send Invitation. The system generates a secure temporary password and sends the invitation email.
The user logs in with the temporary credentials and is immediately prompted to set a personal password. The temporary password expires after 72 hours and cannot be reused.

Screenshot: User invitation form showing name, email, role dropdown, and site access checkboxes

Invitation expiry. The temporary password in the invitation email expires after 72 hours. If the user does not log in within that window, use the Resend Invitation action on the Users page to generate a fresh set of credentials. The previous temporary password is invalidated immediately.

Managing Users

The Users page provides a complete view of all team members within your tenant. Each user row shows their name, email, assigned role, account status, and last login timestamp.

Screenshot: User detail page with role badge, 2FA status indicator, site access list, and action buttons

Editing a user

Click a user's name to open their detail page, then select Edit. You can change the assigned role and update site access at any time. Changes take effect immediately — the user's very next request to the server will be evaluated against the new permissions. No logout or session refresh is required.

Downgrading roles. When you reduce a user's role (for example, from Tenant Admin to Agent), any open browser sessions they have will be restricted at the next page load. There is no forced logout, so consider informing the user directly if the change is security-sensitive.

Deactivating a user

Deactivating a user immediately revokes all access to the admin portal. The account and all associated data (audit log entries, actions taken) are retained for compliance purposes — only the ability to log in is removed. This is the recommended action when an employee leaves the organisation or a contractor's engagement ends.

To deactivate, open the user's detail page and click Deactivate User. The user's status changes to Inactive and all active sessions are invalidated.

Safety guards. You cannot deactivate your own account, and you cannot deactivate the last remaining user with the tenant_admin role. These guards prevent accidental lockout.

Reactivating a user

To restore access, open the deactivated user's detail page and click Reactivate User. The account returns to Active status. The user logs in with their existing password — no new invitation is required. If the user has forgotten their password, they can use the standard password reset flow.

Hard deletion is not available from the admin panel. User records are preserved for audit trail integrity and compliance requirements. If a record must be removed for GDPR data subject rights reasons, use the Compliance → Data Subject Requests workflow, which handles record removal with proper documentation and audit logging.

User detail information

Last Login

Timestamp of the most recent successful login, including IP address and browser. Useful for detecting inactive accounts or anomalous access patterns.

2FA Status

Shows whether the user has enabled two-factor authentication. Tenant Admins can see 2FA status for all users but cannot enable or disable it on their behalf.

Account Status

Active — full access. Inactive — login blocked. Pending — invitation not yet accepted.

Site Access

A site in InnConnect represents a single deployment of the chat widget — typically one per subdomain, brand, or language version. Each tenant can have multiple sites, and users can be scoped to a subset of those sites.

Site access determines which data a user can see and act on. If a user only has access to the English site, they will not see knowledge base articles, chat history, escalations, or any other data belonging to the German site — even if their role would otherwise grant those permissions.

All-site access

When no specific sites are selected during user creation, the user receives implicit access to all current and future sites in the tenant. Appropriate for Tenant Admins and Compliance Officers who need a global view.

Scoped site access

Selecting one or more specific sites restricts the user to only those sites. Recommended for Agents, KB Managers, and other role holders who are responsible for a specific region, brand, or language.

Permissions and site access are independent controls that work together. A user must have both the correct role permission and access to the site in order to interact with that site's data. Granting site access without the appropriate role permission — or vice versa — will not produce access. Think of it as two keys that must both turn.

Scenario	Has Permission?	Has Site Access?	Result
Agent views chat history for Site A	Yes	Yes	Allowed
Agent views chat history for Site B (no site access)	Yes	No	Denied
Auditor tries to edit KB article on any site	No	Yes	Denied

Force Password Change

When a new user is invited to the platform, they receive a system-generated temporary password. On their first login, InnConnect forces a password change before any other page or action is accessible. This ensures temporary credentials have the smallest possible window of exposure.

The temporary password cannot be reused as the new password.
New passwords must meet the tenant's configured strength policy (minimum length, complexity requirements, no commonly breached passwords).
The force-change flag is cleared only after a successful password update. If the user closes the browser before completing the change, they will be prompted again on next login.
The password change event is recorded in the audit log with the user's IP address and timestamp.

Recommended: After setting a new password, encourage users to enable two-factor authentication immediately from Profile → Security. See the Security page for setup instructions.

How Permissions Are Enforced

For administrators and developers who want to understand the technical implementation, this section describes how RBAC is enforced at the application level.

Layer	Mechanism	Description
Global gate	`Gate::before()`	Registered in the AuthServiceProvider. If the authenticated user has the super_admin role, the callback returns true and short-circuits all subsequent permission checks.
Route middleware	`RequirePermission`	Applied to route groups and individual routes. Accepts one or more permission slugs (e.g. `manage-kb`) and returns HTTP 403 if the user's role does not include any of them.
Model method	`hasPermission()`	Available on the AdminUser model. Used in controllers and Blade templates for fine-grained checks (e.g. conditionally showing an Edit button).
Blade directive	`@can` / `@cannot`	Standard Laravel authorisation directives used in templates to show or hide UI elements based on the current user's permissions.

Defence in depth. Hiding a UI element is a convenience, not a security control. Every permission-sensitive action is validated on the server regardless of what the client renders. This dual-layer approach ensures that even if a user bypasses the UI (via API calls, browser developer tools, or URL manipulation), the server will reject the unauthorised request.

For more on authentication, session management, and 2FA, see the Security documentation.