User and Role Management
Control access to your tenant
KaliaOps provides a complete RBAC (Role-Based Access Control) system with 4 system roles, 90+ granular permissions and ownership scopes for fine-grained access control. Email invitations simplify onboarding and deactivation/deletion features ensure GDPR compliance.
RBAC system
KaliaOps uses an RBAC (Role-Based Access Control) system to manage access rights.
Principle
Each user is assigned a role that defines their permissions:
- Role: Set of permissions (e.g., Admin, Manager)
- Permission: Right to perform an action (e.g., assets.view, incidents.create)
- Scope: Application scope of the right (e.g., all entities, my team)
System roles
| Role | Description | Default scope |
|---|---|---|
| Admin | Full access to all features | all |
| Manager | Complete management within their scope | organization |
| Tech | Operational CMDB/ITSM actions | team |
| Viewer | Read-only access | own |
These roles are protected and cannot be deleted.
Custom roles
You can create custom roles with specific permissions to meet your needs.
Inviting a user
Access user management
Menu Settings → Users.
Click "Invite"
Open the invitation form.
Fill in information
Complete:
- Email: New user's email address
- Role: Role to assign
- Employee: Link to existing employee (optional)
Send invitation
User receives an email with an activation link valid for 48 hours.
User activation
User clicks the link, sets their password and accesses KaliaOps.
Managing users
User list
The list displays all tenant users with:
- Name and email
- Assigned role
- Status (active, invited, deactivated)
- Last login
Available actions
- Change role: Modify user permissions
- Reset password: Send reset link
- Deactivate: Block access temporarily
- Delete: Permanently remove user
User statuses
| Status | Description |
|---|---|
| Invited | Invitation sent, awaiting activation |
| Active | Account activated and functional |
| Deactivated | Access blocked, data preserved |
Roles and permissions
Creating a custom role
- Menu Settings → Roles
- Click "New role"
- Name the role (e.g., "L1 Support")
- Select permissions
- Save
Permission categories
| Category | Examples |
|---|---|
| CMDB | assets.view, assets.create, applications.edit, contracts.delete |
| ITSM | incidents.view, incidents.resolve, changes.approve, sla.manage |
| Organization | organizations.view, teams.edit, employees.create |
| Administration | users.manage, roles.edit, audit_logs.view, api_tokens.create |
Permission format
{resource}.{action}Examples:
assets.view: View assetsincidents.create: Create an incidentcontracts.field.cost: View contract costs
Ownership scopes
Scopes define the data access perimeter.
Available scopes
| Scope | Access | Example |
|---|---|---|
| all | All tenant entities | Admin sees all incidents |
| organization | Entities in their organization | Manager sees department incidents |
| team | Entities in their team | Tech sees team-assigned incidents |
| own | Only their own entities | Viewer sees only their incidents |
Scope application
Scope applies automatically to:
- Lists filtered by perimeter
- Actions (edit, delete)
- Exports and reports
Inheritance
A user with "organization" scope also sees entities from teams within their organization.
User-employee link
Each user can be linked to an employee in the CMDB.
Why link?
- Consistency: Single identity in the system
- Assignments: User appears in selectors (project manager, etc.)
- Automatic scope: Inherits team/organization from employee
Creating the link
Two methods:
- At invitation: Select employee in the form
- After creation: Edit user and link an employee
Uniqueness constraint
An employee can only be linked to one user. Attempting to link an already-associated employee shows an error.
User without employee
A user without employee link:
- Can log in and use KaliaOps
- Doesn't appear in "employee" selectors
- Scope is determined solely by their role
GDPR compliance
KaliaOps includes features for GDPR compliance.
Deactivation
Deactivation blocks access without deleting data:
- Open user card
- Click "Deactivate"
- User can no longer log in
- Data and history are preserved
Deactivation is reversible.
Deletion
Deletion permanently removes the user:
- Open user card
- Click "Delete"
- Confirm deletion
Scheduled deletion
For GDPR compliance, you can schedule deferred deletion:
- User is immediately deactivated
- Actual deletion occurs on scheduled date
- User can request cancellation before that date
Preserved data
After deletion, some data is preserved for audit:
- Action logs (anonymized)
- History of processed incidents
- References in created entities
- RBAC system with 4 predefined roles (admin, manager, tech, viewer)
- 90+ granular permissions covering all features
- Ownership scopes: all, organization, team, own
- Email invitation with pre-assigned role and employee
- GDPR compliance: deactivation and scheduled deletion