---
title: "Access rights level for user accounts with multiple roles"
description: "The level of access rights a user account has to a system object is defined by the user roles assigned to the user."
lang: en
languages:
  en: https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/access-rights-level-for-user-accounts-with-multiple-roles/index.md
lastmod: 2026-02-19
---

> Documentation index: https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/llms.txt


# Access rights level for user accounts with multiple roles

Last modified February 19, 2026

> The level of access rights a user account has to a system object is defined by the user roles assigned to the user.


## General rule in Visma Net

If a user has multiple roles assigned and the roles have different access levels to the system object, Visma Net applies the most permissive access level among the roles.

The following table illustrates this with an example.

|When|And|Then|
|---|---|---|
|A user is assigned both the **Employee** and **Sales manager** roles|The **Employee** role has the **Revoked** access level to the Inventory module, and the **Sales manager** role has the **Granted** access level to this module|the user has the **Granted** access level to the Inventory module, that is, the most permissive level.|

## Roles with inherited and defined granular levels

The method of calculating access rights differs from the general rule described in the previous paragraph for a user who has been assigned multiple roles. This happens when some or all of these roles have the **Inherited** access level, which is applied to window element containers and window elements by default.

For this user, the following two rules are used to calculate access rights to a window element container or window element:

### RULE 1

|IF|THEN|
|---|---|
|all roles have the **Inherited** access level to the particular window element container or window elements|the resulting access level is the most permissive access level of the system object at the next highest access level.|

In practice, this means that a window element container will have the same access level as the window that is closest in the access hierarchy. Similarly, a window element will have the access level of the nearest element container up in the hierarchy. See example 1 below.

### RULE 2

|IF|THEN|
|---|---|
|you have explicitly specified an access level to the particular window element container or window element for at least one role. Let’s say you have chosen the “View only” access level to a Release button, while the other roles have the **Inherited** access level to it.|this gives you the access right that is the most permissive access level among those roles with explicitly defined access levels, that is the "View only" level. See example 3 below.|

In these cases the system ignores the roles with the Inherited level of access rights, which is something to consider when making changes at the detail level.

This algorithm is used to optimise the speed of loading the window.

## Access level examples: Scenarios with multiple roles

The following are additional examples that illustrate the system behaviour described in this section.

### Example 1

Suppose that a user is assigned the **Employee** and the **Accountant**
user roles.
The **Employee** role has the **Revoked** access level to the [Customers (AR303000)](https://docs.vismasoftware.no/visma-net-erp/help/customer-ledger/customer-ledger-windows/customers-ar303000/index.md) window, and the
**Accountant** role has the **Edit** access level to this window.
The
default access level both roles have to the window elements is **Inherited**.

The user with these roles, then, has the **Edit** access level to the [Customers (AR303000)](https://docs.vismasoftware.no/visma-net-erp/help/customer-ledger/customer-ledger-windows/customers-ar303000/index.md) window and its elements.

### Example 2

Suppose that a user is assigned the **Employee** and **Accountant** user
roles.
Both roles have the **Insert** access level to the [Purchase invoices (AP301000)](https://docs.vismasoftware.no/visma-net-erp/help/supplier-ledger/supplier-ledger-windows/purchase-invoices-ap301000/index.md) window.
You have decided to forbid
users with the **Accountant** role to release invoices.
For the
**Accountant** role, you specify the **Revoked** access level for the
**Release** button in this window.
The **Employee** role
has the **Inherited** access level to the **Release**
button.
With the settings you have specified, the user has the **Revoked**
access level to the **Release** button.

### Example 3

Suppose that a user is assigned the **Employee**, **Warehouse Worker**,
and **Sales assistant** user roles.
All these roles have the **Insert**
access level to the [Receipts (IN301000)](https://docs.vismasoftware.no/visma-net-erp/help/inventory/inventory-windows/receipts-in301000/index.md) window.
The
**Employee** role has the **Inherited** access level to the
**Release** button on this window, the **Warehouse worker** role has the **Revoked** access level to this button, and the
**Sales assistant** role has the **View only** access level to this
button.
As a result, the user has the **View only** access level (the most
permissive level of the two explicitly defined levels) to this button.

<h2>Related pages</h2><h3>Concepts</h3>
<ul><li><a href="/visma-net-erp/help/access-management/user-security/about-levels-of-access-rights/index.md">About levels of access rights</a></li><li><a href="/visma-net-erp/help/access-management/user-security/about-role-based-access/index.md">About role-based access</a></li>
</ul>


---

[View this page](https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/access-rights-level-for-user-accounts-with-multiple-roles/)