Organization administrators, system administrators, HR operations, compliance leads, and permission managers
Define responsibility types and permission sets for Finger Manager back-office users.
Define responsibility types and permission sets for Finger Manager back-office users.
يمكن تسليم الإشعارات التي يتم إعدادها في Finger Manager داخل Finger Trader App وفق القواعد والجمهور والجدولة.
Roles define the responsibility type and permission set of Finger Manager back-office users.
Institutions can create different roles according to internal positions and management structure, then configure feature permissions, data permissions, and operation permissions for each role.
After a back-office user is assigned a role, the system uses that role to determine which modules the user can access, which data the user can view, and which operations the user can perform.
Roles are a core part of the Finger Manager permission management system.
A Role can be understood as a predefined permission configuration.
Common roles include Super Admin, Administrator, Operations, Customer Service, Trading Operations, Risk Management, Compliance, Finance, and Read Only.
Different roles correspond to different jobs and responsibilities. For example, Operations focuses on product display, content operations, and notification publishing; Compliance focuses on customer review, KYC / KYB, and compliance work; Customer Service focuses on customer data viewing, communication, and service handling.
With roles, institutions do not need to repeatedly configure all permissions for every employee.
Administrators with role management permission can create new roles in Finger Manager.
Common fields include role name, description, organization, status, feature permissions, data permissions, and operation permissions.
For example, an Operations role can be described as responsible for App content operations, notification publishing, and product display management. After creation, the role can be assigned to back-office users.
Each role can contain a different combination of permissions.
Feature permissions decide which system modules the role can access, such as Dashboard, Market & Product Management, Customer Management, Trading Management, Content & Notification, Organization & Permission, System Settings, and Reports & Analytics.
Operation permissions decide what the role can do inside a module, such as View, Create, Edit, Delete, Publish, Approve, Export, and Manage.
Data permissions decide which data the role can access, such as all organization data, current organization data, specified team data, specified customer data, specified market data, or specified Desk data.
These three dimensions make it possible to build a more detailed permission system.
After a role is created, it can be assigned to a back-office user.
For example, if Aki Tanaka is assigned the Operations role, the system grants the permissions configured for Operations.
If the role can view products, edit banners, publish announcements, and create Push Notifications, Aki Tanaka can perform those actions after signing in to Finger Manager. If the role does not include organization management permission, that function is not opened.
The same role can be assigned to multiple back-office users.
For example, Customer Service can be assigned to User A, User B, User C, and User D. These users receive the same base permission set.
If customer service permissions need to change later, the institution can update the Customer Service role once instead of modifying every user one by one.
Depending on the institution's management model, one user can hold multiple roles at the same time.
For example, an employee responsible for both Operations and Customer Service can receive permissions from both roles.
The system calculates the user's final access scope based on the role combination. This is useful for back-office users who work across departments or hold multiple responsibilities.
Roles can belong to a specified Organization.
For example, Japan Entity can have its own Admin, Operations, and Compliance roles. Hong Kong Entity can also have Admin, Operations, and Compliance roles.
Even when role names are the same, different organizations can use different permission settings. Japan Compliance and Hong Kong Compliance can be configured with different access scopes according to local business requirements.
Group-level management users can be assigned global roles with cross-organization permissions.
For example, a Group Administrator can access Japan Entity, Hong Kong Entity, and Singapore Entity, and can be granted cross-organization view or management permissions.
Normal organization roles are limited to data within their own organization scope.
Roles can have statuses such as Active and Disabled.
Active means the role is in normal use. Disabled means the role is temporarily unavailable.
After a role is disabled, new users cannot continue using that role, and users who already hold the role can lose the corresponding permissions according to system rules. For roles that are no longer used but must retain history, disabling is usually safer than direct deletion.
Administrators can modify existing role permissions at any time.
For example, if Operations previously could view customers and publish notifications, and later needs to manage user groups, the administrator can update the Operations role.
After the change, all users holding that role follow the new permission configuration. Before modifying a role, confirm which users may be affected.
When a new role is close to an existing one, administrators can copy the existing role as a starting point.
For example, Senior Operations can be created by copying Operations and adding approval permission, delete permission, or a larger data access scope.
This reduces repeated configuration work.
Institutions should create roles according to the Principle of Least Privilege: each role should only have the permissions required to complete its job.
Customer service staff do not need system configuration permission. Operations staff do not need to modify organization structure. Normal trading operations staff do not need role management permission.
Careful role separation reduces misoperation risk, data leakage risk, permission abuse risk, and internal management risk.
When an employee changes position, administrators can adjust the user's roles directly.
For example, an employee moving from Customer Service to Operations can have the old role removed and the new role assigned.
There is no need to create a new back-office account.
Roles can be used in approval workflows for important business processes.
For example, Operations creates a notification, Manager Review reviews it, Administrator approves it, and the system publishes it.
A trading operation can also be initiated by Trading Operations, reviewed by Risk Management, and then executed. Separating responsibility across roles helps build more controlled internal processes.
Finger Manager can record role-related operations, including creating roles, modifying roles, changing permissions, assigning roles, removing roles, and disabling roles.
The system can record operator, operation time, role name, changed content, and operation result, supporting security audit and troubleshooting.
The workflow can be understood as: create role -> enter role name and description -> set organization -> configure feature permissions -> configure operation permissions -> configure data scope -> save role -> assign role to back-office users -> user signs in to Finger Manager -> system reads roles -> loads permissions -> user can only perform authorized operations.
Roles are permission-set units in the Finger Manager organization and permission system.
Institutions can use roles to configure complex feature permissions, operation permissions, and data permissions once, then assign those roles to different back-office users.
Role management significantly reduces per-user permission configuration work and makes internal responsibilities, data access scopes, and operation boundaries clearer.
