User Roles in Klir

If you're an Admin setting up your team in Klir — or just trying to figure out why someone can't see a certain section — you're in the right place. This guide walks through everything: how permissions work, how to add someone new, how to adjust access when roles change, and what to do when someone moves on.

No jargon, no fluff. Just what you need to get your team set up and running smoothly.

How Permissions Work

Think of permissions in Klir as three layers that work together. You can't look at just one in isolation — they all stack.

Layer 1 — Role Level

Every user gets at least one base role. Roles set the overall level of access a person has.

Role	What they can do
Admin	The keys to the kingdom. Manages users, roles, system settings, tags, and data imports.
Manager	Owns everything within their module, including advanced reporting that standard Users don't have.
User	Your everyday operator. Can edit records and review sample results.
Read Only	Can see everything they're permitted to — but can't change a thing. Great for auditors or anyone who just needs visibility.

Layer 2 — Platform Area

Here's where it gets a bit more nuanced. Just because someone has an edit-level role doesn't mean they can edit everywhere. Each role applies to specific areas of Klir.

Platform Area	Read Only	Edit	Admin
Dashboard & Overview	✅	—	—
Records / Core Data	✅	✅	—
Reporting & Analytics	✅	✅	—
Workflows / Processes	✅	—	✅
Reference Data	✅	—	✅
Integrations	—	—	✅
User Management	—	—	✅
System Settings	—	—	✅

Layer 3 — Action Level

Within each area, permissions get even more granular — controlling the exact actions available to a user: create, delete, export, configure, and so on.

The big takeaway: A user's real access is always the combination of all three layers. Someone might have an edit role but only be able to edit in Records — not in Workflows or System Settings. That's by design, and it's a good thing!

Assigning Roles to Users

There are two ways to assign roles in Klir, and you can mix and match them freely.

Option 1: Assign roles directly to a user

Simple and straightforward — you go to a user's profile and assign one or more roles directly to them.

A few things worth knowing:

A user can hold more than one role at a time
All their roles compound — they always get the broadest applicable permissions across everything assigned to them
This approach works best for users with unique access needs that don't fit neatly into a group

Option 2: Assign roles to a Department or Division

This one's a real time-saver once you've got your structure set up. Instead of configuring each user individually, you assign roles to a department or division — and anyone added to that group automatically inherits those roles.

Here's what makes it powerful:

Users can belong to multiple departments and/or divisions at the same time
Inherited roles compound with any roles assigned directly to the user
Perfect for teams that share a common access profile — onboard ten people at once without touching each profile

A quick note on compounding

No matter how a user receives their roles — directly or through a group — Klir always grants them the broadest applicable permission across all of them. There's no conflict to resolve and no manual override needed.

Real example: Say you have a field operator with the User role assigned directly. You then add them to a Regional Managers division that has the Manager role. They now effectively have Manager-level access — no custom role required, no extra configuration.

Now that you know how the layers work, let's put them to use in the next step - Adding New Users to your Klir Platform.