Administrators and operations teams
Understand how Finger Manager controls feature access, data scope, and operation permissions for different back-office users.
Understand how Finger Manager controls feature access, data scope, and operation permissions for different back-office users.
Notifications configured in Finger Manager can be delivered precisely inside Finger Trader App according to rules, audience, and schedule.
Roles and permissions control which functions a back-office user can see in Finger Manager, which data they can access, and which operations they can perform.
An institution can create different roles for administrators, operations staff, customer service, trading operations, compliance, finance, or other internal teams, and assign the required permissions to each role.
By separating responsibilities through roles and permissions, institutions can avoid giving every user the same back-office access and can keep sensitive operations limited to authorized staff.
A role is a predefined permission set. After a back-office user is assigned a role, the user receives the permissions included in that role.
Common examples include Super Admin, Administrator, Operations, Customer Service, Trading Operations, Risk Management, Compliance, Finance, and Read Only.
A permission determines what a user can do inside a function.
For customer management, permissions can control whether a user can view customers, open customer detail, edit customer data, export data, or adjust account status. For the notification center, permissions can control whether a user can view, create, edit, publish, delete, or review sending records.
In short, a role defines what kind of back-office user someone is, while permissions define the exact actions that role can perform.
An authorized administrator can create a new role in Finger Manager and define the role name, description, status, function permissions, data access scope, and operation permissions.
For example, an Operations role can be used for App content operations, notification publishing, and product display configuration. It may have access to content and notification management, Banner management, announcements, Push Notification, and user group viewing, while being restricted from organization permission changes, sensitive finance data, and system security settings.
Each role can be granted access to different Finger Manager modules. Institutions can combine permissions according to job responsibility rather than using one global permission set for every employee.
Important modules can separate view access from write operations. A user may be allowed to view customer records but not modify them, or view notification records but not publish new notifications.
Common operation permissions include View, Create, Edit, Publish, Approve, Delete, Export, and Manage.
After a role is created, it can be assigned to internal back-office users. When the user signs in to Finger Manager, the system loads the corresponding permissions according to the assigned role.
Functions without permission may be hidden, blocked, shown as read-only, or restricted from action execution depending on the system configuration.
Depending on the institution's internal management model, one back-office user can be granted multiple roles. The system can combine the permissions from these roles to determine the user's final access scope.
For high-privilege users, institutions can also create dedicated administrator roles.
Permissions can control not only functions, but also the range of data a user can access.
Some users may only see customers, desks, markets, organizations, customer groups, or business records under their responsibility, while senior administrators may view the institution-wide data range.
This means permission management answers both questions: what can this user do, and which data can this user do it to.
The following examples are typical role patterns. Institutions can adjust names and permission details according to their own organization.
Finger Manager recommends configuring roles according to the principle of least privilege. A user should receive only the permissions required to complete their work.
For example, a user responsible for operational notifications does not need organization management permissions, and a customer service user who views customer data does not need product configuration permissions.
Proper permission limits help reduce misoperation risk, data leakage risk, privilege abuse risk, and internal management risk.
When an employee's role or responsibility changes, an administrator can update the user's roles or permissions.
After the change is saved, subsequent access to Finger Manager follows the updated permission rules. If an employee leaves or temporarily stops using the system, the back-office account can be disabled.
Roles and permissions should be used together with Finger Manager operation logs. Important actions such as sign-in, notification publishing, product changes, customer data changes, role updates, and permission updates can be recorded.
Operation logs help institutions confirm who performed which action and when, which is important for internal management, security review, and troubleshooting.
A typical permission setup flow is: administrator creates a role, configures function permissions, sets data access scope, saves the role, creates or updates a back-office user, assigns the role, and then the user signs in to Finger Manager.
After sign-in, the system reads the user's roles and permissions, loads the authorized menus and data range, and only allows access to authorized functions and operations.
Roles and permissions are an important part of Finger Manager's back-office access control system.
Institutions can create roles for different internal responsibilities and separately control function permissions, operation permissions, and data access scope.
This helps maintain operational efficiency while applying stricter access control to important functions and sensitive data.
In short, roles define the user's responsibility type, permissions define what the role can do, and data scope defines which records those actions can apply to.
