--- title: "About levels of access rights" description: "With Visma Net, you can control access to system objects at broad and granular levels, down to the control of window elements, such as buttons, text boxes, and check boxes." lang: en languages: en: https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/about-levels-of-access-rights/index.md lastmod: 2026-02-19 --- > Documentation index: https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/llms.txt # About levels of access rights Last modified February 19, 2026 > With Visma Net, you can control access to system objects at broad and granular levels, down to the control of window elements, such as buttons, text boxes, and check boxes. With Visma Net, you can control access to system objects at broad and granular levels, down to the control of window elements, such as buttons, text boxes, and check boxes. Users are assigned to roles, and you give these roles the appropriate levels of access rights (or access levels) to workspaces, windows, and window elements. You have to be very careful when you assign multiple roles to a user account because these roles may have different levels of access rights to system objects. ## Access rights tier structure When configuring user roles, there are three levels of access rights to consider:
Level Description
Workspace level Access at an overall level, such as an entire workspace. Access on this level will also impact windows and entities.
Window-level Access based on windows. For instance, access to a specific window, but not to the window settings. You can configure whether a role can view or edit the window information.
Entity level Access based on functionality. For example, the ability to access and edit sales invoices, while excluding changes to currency.
## Access rights at the workspace levels The following table summarises the levels of access rights that roles can have to the **workspaces** of Visma Net.
Level Description
Not set Allows all roles to have access to the workspace until Revoked or Granted access level is set to the workspace for at least one role. After that, a role with this level is denied access to the workspace.
Revoked

Denies the role access to the workspace and its windows. Users with this role will not be able to see the workspace or its contents.

However, users with this access level may still have access to the functionality of the windows within the workspace. They can only access these windows from other windows with commands to open them, and they cannot view the windows on the navigation pane.
Granted

Allows the role access to the workspace.

You can, however, limit or revoke access to particular windows within the workspace. Only a user with a role with an access level to a window higher than Revoked can access it by clicking the workspace on the main menu and then clicking the window on the navigation pane.
View only

Allows the role access to the workspace.

You can, however, limit or revoke access to particular windows within the workspace. Only a user with a role with an access level to a window higher than Revoked can access it by clicking the workspace on the main menu and then clicking the window on the navigation pane.
You can set up access rights to individual windows in the **Hidden** node (which cannot be accessed from the main menu) on the site map, but not to the node itself. ### Effects of changing access levels from Not set If you change a role's access level to a workspace from **Not set** to **Granted** or **Revoked**, and apply this access level to all nested objects, the role's access rights to workspaces and windows with the **Not set** access level are changed as follows:
If you set the access level for the workspace to Then
Granted

the access level to the workspaces is changed to Granted,

and the access level to windows are changed to Delete(which allows full access to the window and its functionality).
Revoked the access levels to the windows are changed to Revoked.
Access configuration works similarly for a workspace with the **Not set** access level and the windows within it. The capability to set up an access level to a workspace and to all objects within it at once is helpful if the role's access level to most objects within the workspace is **Delete** or **Revoked**. ### Resetting a role’s access level You can reset a role's access level to a workspace to **Not set** any time you want. While resetting access levels, you have the option to update the access level to **Not set** either for all the workspaces and windows or for only the selected workspace. Similar options are available when you set access level for a workspace to **Not set**. For a procedure that describes how to reset access rights, see: [Reset access rights to a suite or a module](https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/reset-access-rights-to-a-suite-or-a-module/index.md). ## Access rights at the window level Within each workspace, you can set the access rights that roles have to Visma Net windows, which affects what users with those roles can access. By default, a new role has the **Not set** access level. ### Inherited access If you change access rights for a user role to a window or a window element, your changes affect only this window or window element. The level of access rights to the window is inherited by the entities and records that can be created by using the window. To make the window available in the navigation pane to a user with this role, set the access level for the window to the **View only** level or more permissive and set the access level for the workspace where the window is located to **Granted**. You can set any of the following levels of access rights to **windows**.
Level Description
Not set

When assigned to all roles, allows all roles to have access to the window until access rights are set to any other level for at least one role.

After at least one role has been assigned another level of access rights, access to the window is denied for a role with this access level.
Revoked Denies the role access to the window and its functionality.
View only

Gives the role restricted access to the window and its functionality.

This level allows users with the role to view the window and any records associated with the window (in drop-down lists on other windows).

This level forbids users with the role to edit details about any record, create new records or entities of the type, and delete records.
Edit

Gives the role restricted access to the window and its functionality.

This level allows users with the role to view the window, select records, and edit details about any record. This level forbids users with the role to create new records or entities of the type, and to delete records.

The Clipboard button is available on the window toolbar for users with the role.
Insert

Gives the role restricted access to the window and its functionality.

This level allows users with the role to view the window, select records, edit details about any record, and create new records or entities of the type.

This level forbids users with the role to delete records.

The Clipboard and Insert buttons are available on the window toolbar for users with the role.
Delete

Gives the role complete access to the window and its functionality.

This level encompasses the capabilities of the View only, Edit, and Insert levels, while also giving users with the role the ability to delete records.

For users with the role, the Clipboard, Insert, and Delete buttons are available on the window toolbar.
## Access rights to containers of window elements Each window includes containers of elements, such as nested windows, tabs, and grids. Each container includes multiple elements and actions. You can restrict access to any of these containers in the window. ### Inherited access The level of access rights a role has to the container is inherited by the entities and records created by using the container, if applicable. For instance, if you permit access for a user role to a grid, a user with this role can access all records in this grid. By default, containers inherit access level from the window to which they belong. You can set any of the following levels of access rights to the **containers**.
Level Description
Inherited Indicates that the role’s access to the container is inherited from its access level to the window.
Revoked Denies the role access to the container and hides it from the window for users with the role. These users will not see the container in the window.
View only

Gives the role restricted access to the container and its functionality. This level allows users with the role to view the container and any records associated with the container (in drop-down lists on other windows), if applicable.

The level forbids users with the role to edit details about any record, create new records or entities of the type, and delete records, if applicable.
Edit

Gives users with the role restricted access to the container and its functionality. This level allows users with the role to view the container, select records, and edit details about any record, if applicable.

The level forbids users with the role to create new records or entities of the type, and delete records, if applicable.
Insert

Gives the role restricted access to the container and its functionality. This level allows users with the role to view the container, select records, edit details about any record, and create new records or entities of the type, if applicable.

This level forbids users with the role to delete records, if applicable.
Delete Gives the role complete access to the container and its functionality. This level encompasses the capabilities of the View only, Edit, and Insert levels, while also giving users with the role the ability to delete records, if applicable.
## Access rights to window elements By default, a role's access rights to the window elements and actions are inherited from the role's access level to the container of window elements. This includes the elements and actions to which they belong. Therefore, it is recommended to set the role's access level to the container of window elements before setting an access level to an individual element or action. Once this is done, you can then set access rights to the window elements and actions. You can set up the following levels of access rights to **window elements**.
Level Description
Inherited Indicates that the role’s access level to the element is inherited from its access level to the container of window elements.
Revoked Denies the role access to the element and hides the element. A user with the role will not see the element in the window.
View only Makes the element read-only for users with the role. A user with the role will see the element in the window but will not be able to use it.
Edit Allows the use of the element for users with the role.
If a particular window toolbar contains window-specific buttons, you can deny access for the role to these buttons, by setting **Revoked** for the buttons. You can revoke access to some of the elements to hide their contents from users with **View only** access level. Configuring a role's access rights at the window control level requires in-depth knowledge of Visma Net functionality.

Related pages

Concepts

--- [View this page](https://docs.vismasoftware.no/visma-net-erp/help/access-management/user-security/about-levels-of-access-rights/)