About role-based access

Users who work with Visma.net ERP have specific job responsibilities that define their access level to financial and other workspaces, windows, records, and operations on the records.
User roles in Visma.net ERP are sets of access rights designed for convenient management of access rights for users with similar responsibilities in the system.

In the User roles (SM201005) window, you create a role and assign it to as many user accounts as needed.
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.

We recommend that you configure the roles so that a user with a role has only 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.
For 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.
For more information, see: About access rights for roles.

The process of defining task-based roles requires in-depth knowledge of both the organisation's business processes and the Visma.net ERP approach to security.

For ease of defining and administering roles, Visma.net ERP provides a set of built-in roles that are stored in the System company.
Built-in roles are always supplied with the system and cannot be deleted.

Some of these roles grant the users access to special functionality, and some of the roles are used by the system and should not be assigned to users manually.

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

• Administrator:
  A user with this role has full access to all system objects, and any access restrictions to system objects are not applied to this role.
  Therefore we recommend that you assign users to this role only during initial system setup so they can define roles and enter users.
  Then assign the role only in extraordinary cases. We recommend that you create a user role for system administrators with access only to Visma.net ERP workspaces that are used for configuration and management of the system.
• 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 ERP.
  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 ERP applications.
  
• Field-level audit:
  A user with this role can view the audit trail directly from an audited window.
  
• Guest:
  This role is used for backward compatibility.
• 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:
  A user with this role can access the Visma.net ERP self-service portal configuration and configure the Self-service portal.
  
• Portal user:
  A user with this role can access the Self-service portal.
  You should assign this role only to contacts who must have access to the Self-service portal.
  
• ReportDesigner:
  A user with this role can publish reports in Visma.net ERP.
  Any user can create reports in Report designer, but for publishing reports in Visma.net ERP, the user needs to be granted this role.

Users from outside your organisation may need access to your Visma.net ERP instance if they are partners or customers of your organisation. We recommend that they access necessary data through the Visma.net ERP self-service portal.
You can perform the following steps to provide external users with the rights to use Visma.net ERP self-service portal:

1. You create a contact-related user type in the User types (EP202500) window, as described in Add a user type.
2. You add at least one user role with the Guest role check box selected in the list of allowed roles of the created user type.
   You can use the built-in Portal user role or create a new one.

In Visma.net ERP, you can control a role's access to system entities, which is the most broad, down to the window element level, which is the most specific. The available levels of access depend on the system entity type.
For more information about configuring access rights, see: About access rights for roles.

Consider an example of some roles a business might set):

• Accountant:
  Allows its members full access to journal entries and schedules, and limited (View only) access to allocations.
• Customer ledger administrator:
  Allows its members full access to customer ledger documents; these members may also view supplier ledger documents and budgets.
• Supplier ledger administrator:
  Allows its members full access to supplier ledger documents; in addition, users with the role may view customer ledger documents and budgets.
• Accounting manager:
  Allows its members full access to allocations and budgets; these members may view other user accounts too.
• Security officer:
  Allows its members full access rights to user accounts, roles, and restriction groups.

Note that some users have only one role assigned, while other users have multiple roles, in accordance with their responsibilities.
A user's access to an entity is defined by the most permissive level of access among the roles assigned to this user.
With the roles shown here, User 6 (with both the Accounting manager and Supplier ledger administrator roles assigned) has full access to budgets from the Accounting manager role, rather than view-only access from the Supplier ledger administrator role.