> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blis.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Users & Roles

> Understand how user accounts and roles work in bLIS

## Overview

bLIS uses role-based access control to determine what each user can see and do. Every user is assigned a single active role and a primary client (organization). Roles control which features are available, and client assignment controls which accession and billing data is visible.

## How users are created

User accounts are created automatically when someone logs in through your SSO provider (SAML or OIDC) for the first time. This is called just-in-time (JIT) provisioning. During login, bLIS:

1. Matches the user's email domain to an authentication provider
2. Maps SSO attributes to determine the user's **name**, **role**, **client**, and **additional clients**
3. Creates or updates the user record with these values

Each subsequent login refreshes the user's name, role, client, and additional clients from the SSO provider.

<Tip>
  You configure how SSO attributes map to bLIS roles and clients in **Administration** → **Authentication**. See [Authentication](/admin/authentication) for details on setting up SSO providers and attribute mappers.
</Tip>

## Roles

bLIS includes these roles, listed from least to most privileged:

| Role                 | Display name           | Description                                                                                                                                            |
| -------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `blis_org_readonly`  | Field tech (read-only) | View-only access to accessions for assigned clients                                                                                                    |
| `blis_org_tech`      | Field tech             | Can create and manage accessions for assigned clients                                                                                                  |
| `blis_lab_readonly`  | Lab tech (read-only)   | View-only access to lab data including accessions and results                                                                                          |
| `blis_lab_ops_admin` | Ops admin              | Lab assistant work plus **Administration** (configuration, invoices, and insights). Cannot enter or validate results, or generate and release reports  |
| `blis_lab_tech`      | Lab tech               | Full lab operations — enter results, validate, finalize, manage test runs, and generate reports                                                        |
| `blis_lab_manager`   | Lab manager            | Everything a lab tech can do, plus access to **Administration** for managing users, test specifications, authentication, audit logs, and notifications |

### What each role can access

**All roles** can access:

* Dashboard
* Search
* Accession list and custom views

**Ops admin** can additionally access:

* Lab assistant workflows such as accessions, samples, comments, uploads, and viewing test runs
* **Administration** — configuration, invoices, and insights

**Lab tech** and **Lab manager** can additionally access:

* Test runs
* Reports (with pending report counts)
* Accession actions: edit, enter results, place holds, receive/unreceive, create test runs, print labels, upload files, and set priority/status

**Lab manager** can additionally access:

* **Administration** — manage test specifications, users, authentication providers, audit logs, and notification settings

**Ops admin** cannot enter or validate results, or generate and release reports. **Lab tech** can.

**Field tech** roles are scoped to their assigned clients and do not have access to lab-specific features like test runs and reports.

**Read-only** roles (both field tech and lab tech) can view data but cannot create or modify records.

## User fields

Each user record contains the following fields:

| Field              | Description                                                              |
| ------------------ | ------------------------------------------------------------------------ |
| Email              | Unique identifier, case-insensitive. Set from SSO attributes.            |
| Username           | Display name. Set from SSO attributes (first/last name, name, or email). |
| Default role       | The user's active role, determining what they can access.                |
| Allowed roles      | Roles the user is permitted to hold (set from SSO).                      |
| Client             | The primary client (organization) the user belongs to.                   |
| Additional clients | Other clients the user can create and access accessions for.             |
| Last login         | Timestamp of the most recent login.                                      |

## Managing users

**Lab manager** and **Ops admin** can manage other users. The user management interface is available at **Administration** → **Users & Roles**.

From this screen, you can view all users and adjust their settings by selecting a user. The user detail form allows you to change:

* **Role** — the user's active role
* **Client** — the user's primary client assignment
* **Additional clients** — other clients the user can access

<Note>
  Changes made in the admin interface are applied as **user overrides**, which take precedence over values set by the SSO provider. The next time a user logs in, the override values are used instead of the SSO-provided values.
</Note>

### User overrides

When you change a user's role, client, or additional clients through the admin interface, bLIS creates a **user override** record. Overrides let you:

* Assign a different role than what the SSO provider maps
* Move a user to a different client
* Grant access to additional clients

Overrides persist across logins and apply every time the user's session is created.

## Client access

Users can be granted access to multiple clients through the **Additional clients** field. This is useful for:

* Laboratories that process samples from multiple client organizations
* Supervisors who oversee multiple locations
* Staff who need visibility across client organizations

When a user has access to multiple clients, they can view and create accessions for any of those clients.

## Troubleshooting

### User has the wrong role after logging in

Check whether a user override exists in **Administration** → **Users & Roles**. If an override is set, it takes precedence over the SSO-mapped role. Update or remove the override as needed.

If no override exists, check your SSO attribute mapper configuration in **Administration** → **Authentication** to verify that role mapping rules are correct.

### User cannot access certain accessions

* Verify the user's **Client** and **Additional clients** include the client associated with the accession.
* Confirm the user's role has sufficient permissions (read-only roles cannot modify data; field tech roles cannot access lab features).

### User cannot perform certain actions

* Confirm the user's current role. For example, entering results requires **Lab tech** or **Lab manager**. Administrative screens are available to **Lab manager** and **Ops admin**.
* Check whether the user's role was set by an override or by the SSO mapper.

### User account was not created on login

* Verify the SSO provider is configured correctly in **Administration** → **Authentication**.
* Check that the user's email domain matches a configured authentication provider.
* Ensure the SSO attribute mapper can resolve a valid client (organization) for the user.