System administrators, organization administrators, security teams, compliance teams, and permission managers
Control which functions, data, and operations Finger Manager back-office users can access.
Control which functions, data, and operations Finger Manager back-office users can access.
Notifications configured in Finger Manager can be delivered precisely inside Finger Trader App according to rules, audience, and schedule.
Permissions control which functions Finger Manager back-office users can access, which data they can view, and which specific operations they can perform.
Roles are collections of permissions, while permissions are the lower-level control units. For example, Operations is a role, and View Product, Edit Product, Publish Announcement, Create Push Notification, and Manage Banner are permissions under that role.
Permission management allows institutions to precisely control back-office access so each position only receives the functions and data access required for its work.
A Permission decides what a back-office user can view, operate, or manage.
Finger Manager permissions can cover page access, feature permissions, operation permissions, data permissions, API permissions, and management permissions.
The system uses the user's roles and permissions to determine what is finally opened in the back office.
Feature permissions decide which Finger Manager modules a user can enter.
Examples include Dashboard, Market & Product Management, Customer Management, Trading Management, Content & Notification, Organization & Permission, System Settings, Logs & Troubleshooting, and Reports & Analytics.
If a user does not have access to a module, that module can be hidden or blocked. For example, a customer service user may access Customer Management but not System Settings.
After entering a module, operation permissions further control what the user can do.
Common operations include View, Create, Edit, Delete, Publish, Approve, Export, Import, Enable, Disable, and Manage.
For example, in Content & Notification, a user may have View, Create, and Edit, but not Publish or Delete. That user can create and modify notifications but cannot publish or delete them.
View is the most basic permission type. It allows users to view the corresponding page or data.
For example, Customer View allows customer list access, Order View allows order viewing, and Product View allows product configuration viewing.
When a user has View but not Edit, the page can be set to read-only.
Create permission controls whether a user can add new records, such as products, notifications, users, roles, user groups, organizations, and scheduled tasks.
A user with only View permission can inspect existing data but cannot create new records.
Edit permission controls whether a user can modify existing content, such as product information, customer profiles, announcements, banners, user groups, and system settings.
Institutions can grant view and edit permissions to different positions separately.
Delete is a relatively high-risk permission. It allows users to delete data that the system permits to be deleted, such as drafts, user groups, unused configurations, and certain back-office records.
For orders, trading records, operation logs, and other long-retention data, the system can restrict permanent deletion.
In practice, Delete should usually be granted only to a small number of administrators.
Publish permission controls whether content or configuration can formally take effect.
Examples include publishing announcements, popups, marquee notices, banners, Push Notifications, and product configuration.
Operations staff can be responsible for Create + Edit, while a supervisor holds Publish permission, separating production from release.
Approve permission can be used for business processes that require internal review.
Examples include customer review, KYC / KYB approval, high-risk operation approval, product launch approval, notification publishing approval, and permission request approval.
Users without Approve permission can submit business items but cannot execute final approval.
Export permission controls whether users can export system data such as customer data, order data, trading records, reports, logs, and statistical data.
Because exports can include large amounts of business or customer information, export should be managed separately from normal view permission.
For example, a user may view customer profiles in the back office but cannot batch export customer data.
Feature permissions answer which module the user can enter. Data permissions answer which data the user can see after entering.
For example, three users may all have Customer Management permission, but User A can view all customers, User B can only view Japan Entity customers, and User C can only view customers assigned to them.
Data access scope can be configured independently from feature permissions.
Finger Manager can define data scopes according to the institution structure.
Common scopes include All Organizations, Current Organization, Specific Organizations, Team, Assigned Users, Selected Markets, and Selected Desk.
Data permissions make it possible to establish data isolation even inside the same back-office function.
Permissions can be limited by Organization scope.
For example, a Japan Entity Operations user may have Product Edit, but if the data scope is Japan Entity, that user can only edit Japan Entity products. The user cannot operate on Hong Kong Entity products.
A complete permission can be understood as feature permission + operation permission + data scope.
In daily use, institutions usually do not configure large numbers of permissions user by user.
A more common workflow is to define permissions, combine several permissions into a role, then assign the role to users.
For example, Operations Role can include Product View, Product Edit, Banner View, Banner Edit, Notification Create, and Notification Publish. When a user receives Operations Role, the user automatically receives those permissions.
In special cases, extra permissions can also be granted directly to a single user.
For example, an Operations employee normally does not have Export Report, but temporarily needs to handle reporting work. The administrator can grant Report Export as an additional permission.
Direct permissions can supplement role permissions. Long-term permissions should usually still be managed through roles.
For institutions with an organization hierarchy, permission inheritance can be used according to system configuration.
For example, a Group Administrator with group-level access can reach Japan Entity, Hong Kong Entity, and Singapore Entity, while a child-organization administrator can only manage their own organization.
Permission inheritance can reduce repeated configuration work in large groups.
Some permissions are high-risk and should be granted cautiously.
Examples include Permission Manage, Organization Manage, User Delete, Customer Export, Trading Manage, API Manage, Security Settings, System Settings, and Audit Log Export.
These permissions should usually be granted only to Super Admin, senior administrators, or designated owners, and related behavior should be recorded in operation logs.
Finger Manager can build different levels of access through permission combinations.
For example, read-only users may only have View; normal operators may have View + Create + Edit; operations supervisors may have View + Create + Edit + Publish; administrators may have View + Create + Edit + Publish + Delete + Manage.
Different modules do not need the exact same permission combination. Institutions can configure combinations according to actual risk.
Institutions should configure permissions according to the Principle of Least Privilege. Back-office users should only receive the permissions necessary for their current job.
For example, customer service staff may need to view customer profiles but do not necessarily need to export all customer data. Operations staff may publish campaign content but do not necessarily need to modify security settings. Trading operations users may view orders but do not necessarily need to manage back-office roles.
This principle helps reduce internal system risk.
Important business workflows can use permission separation to create separation of duties.
For example, operations staff can hold Create + Edit, operations supervisors can hold Approve, and administrators can hold Publish. A major notification then requires multiple people before it can be formally released.
Trading, customer review, and high-risk system operations can use similar mechanisms.
Administrators can adjust permissions when employee responsibilities change.
For example, an employee originally has only Customer View and later needs Customer Edit. The administrator can complete the adjustment by modifying the role or direct user permissions.
After permission changes, the system controls back-office operations according to the new rules.
When a permission is no longer needed, it can be removed from a role or user.
For example, after an employee transfers away from a position, Notification Publish can be removed while Notification View is retained.
The user can still view historical notifications but cannot continue publishing new content.
Beyond back-office page permissions, Finger Manager can control API access separately.
Examples include Market Data Read, Customer Read, Order Read, Order Write, Notification Send, and Account Manage.
API permissions can be managed separately from back-office operation permissions. This prevents a user with back-office access from automatically receiving API operation ability.
When a user performs a back-office operation, the system checks permissions before execution.
The flow is: user initiates an operation -> identify current user -> read Organization -> read user roles -> read role permissions -> read data access scope -> decide whether the operation is allowed -> allow or reject.
If the user does not have the required permission, the system will not execute the operation.
Permission-related operations can enter Finger Manager operation logs.
Examples include adding permissions, modifying role permissions, granting permissions, removing permissions, changing data scopes, and adjusting API permissions.
Logs can record operator, operation time, permission name, modified object, previous state, and new state. This helps institutions track permission changes and perform internal audits.
The workflow can be understood as: define system permissions -> classify by business module -> set operation-level permissions -> set data access scopes -> combine permissions into roles -> assign roles to back-office users -> user signs in to Finger Manager -> system reads roles and permissions -> checks feature access -> checks data access -> checks operation permission -> allows or rejects the operation.
Permissions are the most basic access-control units in the Finger Manager organization and permission system.
They separately control which functions a back-office user can access, which operations the user can perform, and which data scope the user can view.
Roles combine multiple permissions, organizations define business and data boundaries, and permissions ultimately decide whether a user is allowed to perform a specific operation.
Through the combination of roles, organizations, and permissions, institutions can build a fine-grained back-office access control system that matches their internal management structure.
