Access to FA functionality
You can manage access to FA functionality in the FA Admin Console. Access to FA functionality is defined by:
A tree structure that consists of departments, roles, and rights. Departments include roles that are linked to user rights. User rights define access to features and functionality within the FA applications.
The role(s) you assign to the user.
Role management lets you structure departments, roles, and rights in the way that suits your use case best. When you create a role structure in FA, identify the types of tasks the users perform in FA and group them accordingly. The screenshot below features an example of a simple role structure that has back-office users, administration, and clients. Such structure is suitable for a small organization where all employees perform the same back-office tasks, and the administration role is reserved for users with access to FA setup. Client role is for the clients using FA Client Portal.
 |
If your use case is more complex, with various users performing various sets of tasks, you should create a corresponding role structure. In the screenshot below, departments feature multiple roles that correspond to different sets of tasks (for example, accountant, back office analyst, fund operations, head of operations).
 |
Note that the role structure in FA should not mirror your organization structure, as roles and departments are based on the system usage.
Note
Roles, departments and rights define user's access to FA functionality (for example, to trade order management or rebalancing). They don't grant or restrict access to certain client data. To set up access to client data, use limited visibility (see Access to data in FA Admin guide).
Departments
Departments are groups of roles in your organization. Departments help you organize roles in a clear structure that is easy to understand, navigate and use. In a smaller organization, a simple department structure with only one role per department can be enough - for example, "Back office", "End client" and "Administration". In a bigger organization, you can have many departments, each of them including several roles (see examples above).
Roles
Roles represent use cases. When you create a role, you link it to the user rights that provide access to FA functionality needed for the role's use case. Here are some tips:
Roles shouldn't copy the structure of your organization or offices. Create roles based on the type of tasks the users need to perform. For example, if your organization has advisors who work in Helsinki and Stockholm offices and have the same scope of tasks – we recommend creating one common "advisor" role for them.
Avoid too granular, feature-specific role definitions. Try to create roles that are based on the type of tasks. For example, "Back office", "Administrator" instead of "Rebalancing" or "User management".
If you have a group of users with the same tasks (for example, back office employees), with a part of these users having additional responsibilities, consider creating separate roles for the basic and additional sets of tasks. For example, you can have a back office role for all back office employees, and separate roles for accounting, user management, compliance, and so on. The users with additional responsibilities would have two or more roles.
Rights
Rights define access to FA features and functionality. While roles depend on your use case and you can define them in FA user management, rights are standard – they correspond to certain FA features and can't be changed. For example, the ROLE_ANA right provides access to Analytics views and Strategy analyzer. You can use it in one or more user roles you set up, such as Analyst, Asset manager, Fund manager, and so on. Here are some tips on adding rights to a role:
Avoid including too many extra rights in one role – identify the rights that are really needed for the role's tasks. If a role is linked to too many rights, the user with the role might see a lot of extra views, tabs, and menus that they don't need. You can always redefine a role in the future by adding more rights in it if you need to.
To provide access to an app in a role, include at least one right for this application. Otherwise, the user won't be able to access it.
To let the users access the same functionality but different data (for example, restrict advisors' view to the portfolios they are responsible for), define a role with the following rights:
The ROLE_LV right for limited visibility.
The ROLE-ELV right for extended limited visibility.
Other rights that provide access to the functionality needed for the role.
The limited visibility rights (ROLE_LV and ROLE_ELV) affect the choice of other rights you add for the role. When you define a role, you should first decide if you want to include the limited visibility right in it. After that, make sure that other rights you add don’t conflict with the limited visibility right – these rights must provide access only to views and features that support limited visibility. To learn more about the views that support limited visibility, see Access for employees.
User's roles
After you defined user rights and roles in the system, assign roles to the users. A user can have one or more roles, depending on what kind of use cases are relevant for them when working with FA.