About role-based access

Visma Net employs a role-based system to regulate access to the system. Instead of assigning access rights individually, users are assigned one or more roles, which are predefined sets of access rights. These roles align with their specific job responsibility and determine the levels of access granted to workspaces, windows, records, and record operations.

This allows for easy and efficient management of access to system objects, as changing the access rights of a role affects all users assigned to that role. Users without any assigned roles have no access to system resources.

After Visma Net is installed, you give users access to the system objects according to their responsibilities by assigning them roles. This is done in Admin which is Visma's administration panel where you manage your companies and users.

Before you start managing user access within your company, be sure to create an administrative user role with full system access. This role will serve as a cornerstone for assigning additional user roles. This way you can avoid the potential risk of inadvertently locking users out of the system.

Admin provides predefined roles to simplify role definition and administration.

These roles are license roles and define the maximum number of users per company. They are initially managed and assigned in Admin, then automatically transferred to Visma Net. In the roles registry of Visma Net, they are marked as 'Default' and come with preconfigured access rights that cannot be altered or removed. In Admin you can, for instance, assign users the Financials Administrator or Financials User roles.

Visma Net also includes built-in roles that are stored directly in the system. These roles are always provided and cannot be removed. Some of these roles grant users access to special functionality, while others are used by the system and should not be manually assigned to users.

The following built-in roles are available in the system:

  • Administrator:
    This is an internal role used by the system, for instance to run system processes.
  • Anonymous:
    This role is reserved for system use.
  • DashboardDesigner:
    The system automatically designates this role as a dashboard owner role for dashboards that were created in previous versions of Visma Net.
    We recommend that you create specific roles for users who should own particular dashboards.
    For details, see: About dashboard pages.
  • BI:
    A user with this role can access the BI Views—that is, the pre-configured generic inquiries that are exposed through the OData protocol, such as BI-opportunities.
  • Customiser:
    A user with this role can customise Visma Net applications.
  • Field-level audit:
    A user with this role can view the audit trail directly from an audited window.
  • Guest:
    Not used.
  • Internal user:
    A user with this role can change personal settings, and view Help.
    It is automatically assigned to all user accounts linked with the Employee user type.
  • Portal admin:
    Not used.
  • Portal user:
    Not used.
  • ReportDesigner:
    A user with this role can publish reports in Visma Net.
    Any user can create reports in Report designer, but for publishing reports in Visma Net, the user needs to be granted this role.

In addition to predefined roles, you are able to create new roles using the User roles (SM201005) window, and assign it to as many user accounts as needed. These roles are specific to your company and can be used to remove access granted by the license roles.

We recommend that you configure the roles so that a user with a role only has the access rights necessary to perform typical tasks.

It is better to give a user multiple roles than to create complicated roles that overlap with existing ones.

Example

Suppose that the Accounting manager role has broader access rights than the Accountant role.

Instead of giving the Account manager role the same privileges the Accountant role has, give a user in a managerial position the Accountant role along with the Accounting manager role.

If you need to change access rights for all users assigned to a role, you change the settings of the role instead of editing each user's permissions.
When new users are hired in your organisation, you assign a role to a new user.
When existing users change their position in the company, you simply change set of roles according to their new responsibilities.