Organization administrators, role managers, permission managers, operations leads, and security administrators
Control which Finger Manager modules, features, and actions each back-office user can use.
Control which Finger Manager modules, features, and actions each back-office user can use.
يمكن تسليم الإشعارات التي يتم إعدادها في Finger Manager داخل Finger Trader App وفق القواعد والجمهور والجدولة.
Feature permissions control which modules a Finger Manager back-office user can access and whether the user can use the corresponding features.
Feature permissions decide whether the user can use a function. Data permissions decide which data the user can see when using that function.
For example, if a user has Customer Management -> Customer View and the data scope is Japan Entity, the user can enter Customer Management but can only view customer data under Japan Entity.
Feature Permissions are the basic feature-access controls in the Finger Manager permission system.
They determine whether a back-office user can enter a module and whether the user can use specific functions in that module.
Examples include viewing customers, editing customers, viewing orders, managing products, publishing announcements, sending Push Notifications, managing users, and changing system settings.
Finger Manager can first control access by top-level business module.
Examples include Dashboard, Market & Product Management, Customer Management, Trading Management, Content & Notification, Organization & Permission, System Settings, Logs & Troubleshooting, and Reports & Analytics.
If a back-office user does not have access to a module, that module can be hidden from the left menu or blocked. For example, Customer Service may see Dashboard, Customer Management, and Content & Notification, but not System Settings, Organization & Permission, or API Management.
After entering a module, the system can further control the specific functions inside that module.
For example, Market & Product Management can separately control Market Management, Desk Management, product basic information, product icons, product listing, product sorting, trading hours, price precision, and product parameter configuration.
A user with Market & Product Management access does not need to receive every function inside that module. Institutions can open only the functions required for the user's role.
The same function can further distinguish different operations.
Common operations include View, Create, Edit, Delete, Publish, Approve, Export, Enable, Disable, and Manage.
For example, an Operations user may have View + Create + Edit for announcements, but not Publish. The user can prepare announcement content but cannot publish it to users.
View permission controls whether a user can view a feature and its related information.
Examples include Customer View, Product View, Order View, Position View, Notification View, and Report View.
After receiving View permission, the user can see the related page. Without other operation permissions, the page can remain read-only.
Create permission decides whether a user can create new business records.
Examples include creating products, customers, announcements, notifications, banners, user groups, back-office users, roles, and Organizations.
A user with Notification View but without Notification Create can only view existing notifications and cannot create new notifications.
Edit permission decides whether a user can modify existing data or configuration.
Examples include editing customer profiles, changing product parameters, editing banners, changing announcements, modifying user groups, editing roles, and changing system settings.
View and Edit can be granted independently, allowing some positions to inspect important data but not modify it.
Delete permission allows the user to delete data that the system permits to be deleted.
Because deletion is usually high risk, it should be configured cautiously. Operations users may have View, Create, and Edit, but not Delete.
For orders, trading records, operation logs, and other long-retention data, the system can completely prohibit permanent deletion.
Publish permission controls whether a configuration or content item can formally take effect.
It is commonly used for announcements, banners, popups, login popups, marquee notices, Push Notifications, in-app notifications, and product listing.
For example, content editors can hold Create + Edit, while operations supervisors hold Publish, preventing unaudited content from being published to Finger Trader App.
Approve permission is used for workflows that require multiple people or internal review.
Examples include KYC / KYB review, product launch approval, notification publishing approval, high-risk operation approval, permission-change approval, and customer status adjustment.
With approval permissions, institutions can build an internal flow of create -> review -> approve -> execute.
Export permission controls whether a back-office user can export data.
Examples include customer lists, order records, position data, trading history, reports, and logs.
View and Export can be controlled separately. For example, customer service can view customer profiles but cannot batch export the customer database.
Content & Notification permissions can divide operating responsibilities across different users.
Organization & Permission is a highly sensitive back-office module and should usually only be granted to senior administrators.
System settings can affect the entire system, so they should be limited to Super Admin or designated technical administrators.
Finger Manager can dynamically control the back-office interface based on feature permissions.
If a user does not have Organization Manage, the Organization Management menu can be hidden. If the user has Organization View but not Organization Edit, the organization page can be shown while edit buttons remain unavailable.
This allows each back-office user to see only the features related to their responsibilities.
Permissions can control not only pages, but also buttons inside pages.
For an announcement page, Announcement View allows the user to see announcements, Announcement Edit enables the Edit button, Announcement Publish enables the Publish button, and Announcement Delete enables the Delete button.
This provides finer-grained interface permission control.
In most cases, feature permissions are not configured one by one directly for every user.
A common workflow is: feature permissions -> combine into roles -> assign roles to back-office users.
For example, Operations Role can include Product View, Product Edit, Banner Manage, Announcement Manage, and Push Notification Send. Compliance Role can include Customer View, KYC / KYB Review, Compliance Task Manage, and Audit Log View.
Feature permissions and data permissions jointly determine the final access result.
If a user has Order View, the user can use the order-viewing feature. If Data Permission = US Equity Desk, the user can only view orders within US Equity Desk.
The final result is that the user can view orders, but only orders inside the authorized data scope.
When employee responsibilities change, administrators can modify the feature permissions attached to the role.
For example, if Operations originally only has Banner View and Banner Edit, and later needs Banner Publish, the administrator only needs to add the corresponding permission to the role.
Users with that role can then use the feature according to the new permission rules.
Some features are high-risk and should be controlled separately.
Examples include Permission Manage, Organization Manage, System Settings Edit, Security Settings Manage, Customer Export, Trade Manage, API Manage, Notification Bulk Send, Delete, and Approve.
These permissions should not be granted to normal back-office users by default. They should be assigned only according to actual responsibilities.
Feature permissions should follow the Principle of Least Privilege. Users should only receive the functions needed to complete their current work.
For example, customer service needs to view customer profiles but does not need to change trading system settings. Operations needs to manage banners and notifications but does not need to manage back-office roles. Compliance needs to review customers but does not need to publish marketing campaigns.
Least-privilege configuration clarifies responsibilities and reduces misoperation and permission-abuse risk.
The check workflow can be understood as: user signs in to Finger Manager -> read Organization -> read user roles -> read feature permissions in roles -> decide module access -> decide specific feature access -> decide operation permission -> combine with data permissions to determine data scope -> allow or reject the operation.
Feature permissions are the core Finger Manager permission capability for controlling system feature access.
Institutions can use feature permissions to separately control whether back-office users can view, create, edit, publish, approve, delete, or manage different business modules.
Together with roles and data permissions, the access model becomes: organizations define management boundaries, roles define job responsibilities, feature permissions define what users can do, and data permissions define which data they can operate on.
This creates a complete, clear, and extensible back-office access control system.
