Organization administrators, permission managers, compliance teams, operations leads, and data owners
Control which organization, team, desk, customer, market, and product data each back-office user can access.
Control which organization, team, desk, customer, market, and product data each back-office user can access.
يمكن تسليم الإشعارات التي يتم إعدادها في Finger Manager داخل Finger Trader App وفق القواعد والجمهور والجدولة.
Data permissions control which data a Finger Manager back-office user can view, operate, or manage after the user already has feature access.
Feature permissions decide whether the user can enter a module. Data permissions decide which records or data scopes the user can see after entering that module.
Institutions can use data permissions to isolate data by organization, team, desk, customer, market, product, or other business scopes.
Data Permissions answer which data a user is allowed to access.
For example, three users may all have Customer View. User A can view all customers, User B can only view Japan Entity customers, and User C can only view customers assigned to them.
They have the same feature permission, but different data scopes. That difference is data permission.
Feature permissions decide what the user can do, such as viewing customers, viewing orders, editing products, publishing notifications, or viewing reports.
Data permissions decide which data the user can perform those operations on.
A complete back-office access capability is usually determined by feature permissions, operation permissions, and data permissions together.
Group administrators or senior management users can be configured with All Data or All Organizations scope.
For example, a Group Administrator can view customer, product, trading, and other business data across Japan Entity, Hong Kong Entity, and Singapore Entity.
This scope is broad and should usually be granted only to senior administrators or group-level roles.
Current Organization is the most common data scope. The user can only access data belonging to their own Organization.
For example, a user in Japan Entity can view Japan Entity customers, products, orders, positions, notifications, and reports, but cannot access Hong Kong Entity data.
Administrators can also specify the Organizations a user may access.
For example, a regional lead may access Japan Entity and Hong Kong Entity, but not Singapore Entity.
This supports more flexible cross-organization access control.
Institutions can also control data scope by Team.
For example, Institutional Team can view institutional clients, Retail Team can view retail clients, and VIP Service Team can view customers assigned to the VIP team.
This keeps data isolated even inside the same Organization.
Some positions can use Assigned to Me scope, which only permits access to data assigned to the current back-office user.
For example, Relationship Manager A can only view their own assigned customers, while Relationship Manager B can only view another assigned customer set.
This fits relationship managers, account managers, customer service, sales, and institutional coverage teams.
Administrators can allow a back-office user to access only selected customers or customer sets.
For example, a customer service user may only be allowed to access Client A, Client B, and Client C.
This creates customer-level access control.
Trading-related modules can use Desk as a data permission boundary.
For example, US Equity Desk can only view US equity orders, positions, trading signals, and related customer data, while FX Desk can only view FX orders, positions, and FX trading signals.
Different trading teams can manage their own business independently in the same Finger Manager.
Data permissions can also be scoped by market, such as US Stocks, Japan Stocks, Hong Kong Stocks, Forex, Crypto, and Commodities.
For example, Japan Market Operations may only have Japan Market data access. Even with Order View, the user cannot view orders from other markets.
For more detailed control, data scope can be limited by product or product group.
For example, a user may only view AAPL, TSLA, NVDA, or US Equity Products related customer and trading data.
This is useful when institutions manage specific product lines independently.
Customer Management data permissions control which customers a user can see.
Common scopes include All Customers, Organization Customers, Team Customers, Assigned Customers, and Selected Customers.
Different positions can use different customer data scopes.
Trading Management can restrict data by organization, desk, market, customer, or product.
For example, a user with Order View and US Equity Desk scope can only see orders belonging to US Equity Desk, not FX Desk or other desks.
The same rules can apply to positions, historical orders, real-time trading signals, execution records, and risk data.
Content & Notification can also use data scopes.
For example, Japan Operations can only view and manage announcements, banners, popups, Push Notifications, and App in-app notifications created by Japan Entity.
This prevents operations teams from different entities from modifying each other's content.
Reports and analytics often include large aggregated data sets, so they also need data permission control.
For example, a user may view Japan Entity Report but not Group Consolidated Report, or a Desk Manager may only view statistics for their own desk.
Report permissions should align with raw data permissions so reports cannot bypass data access limits.
Operation logs and system logs can also be managed by data scope.
For example, an Organization Admin can only view logs generated by users in the same organization, while a Group Admin can view logs across multiple organizations.
Highly sensitive security logs can be further limited to Super Admin only.
For institutions with organization hierarchy, data permission inheritance can be used according to configuration.
For example, if a Group Administrator has group-level data permission, the user can access lower organization data. A Japan Retail Team employee can only access data within that team.
Inheritance supports hierarchical management for large groups.
Data permissions can combine multiple conditions.
For example, a user's data scope can be Organization = Japan Entity, Market = US Stocks, Desk = Retail Desk.
That user can only access US stock data under Retail Desk within Japan Entity.
Data permissions can be included directly in role configuration.
For example, Japan Operations may include Product View, Notification Manage, Customer View, and data scope Organization = Japan Entity.
When a user receives this role, the user automatically receives the related data scope.
Even inside the same Organization, different roles can access different data scopes.
For example, Japan Admin can view all Japan Entity data, Japan Operations can view product and operations data, Japan Customer Service can view customer-related data, and Japan Trading Operations can view trading-related data.
Combining roles and data permissions helps avoid unnecessary data exposure.
Besides default role data permissions, administrators can configure special data scopes for individual users.
For example, a Compliance user normally only views Japan Entity, but temporarily needs Hong Kong Entity review access. The administrator can temporarily add Hong Kong Entity data scope and remove it after the task ends.
Data permissions are an important part of Finger Manager data isolation.
For example, when Organization A and Organization B both use Finger Manager, normal users in Organization A cannot see Organization B customers, trades, products, notifications, reports, or back-office users.
Only users with explicit cross-organization data permission can access those data sets.
Viewing data and exporting data can be controlled separately.
For example, a user may view the customer list but cannot export customer data, or may view orders but cannot download a full order file.
Exports that include large amounts of customer or trading data should use stricter permission control.
Beyond record-level scope, the system can further control sensitive fields.
Some roles may view basic customer profiles but cannot view full phone numbers, full emails, identity document numbers, bank account information, or other sensitive fields.
Depending on permission, fields can be hidden, masked, or partially displayed to reduce sensitive data exposure.
When an employee's position, team, or responsibility scope changes, administrators can adjust data permissions.
For example, if an account manager moves from Team A to Team B, the administrator can change the data scope from Team A to Team B without creating a new back-office account.
When a back-office user accesses data, Finger Manager checks whether the requested data belongs to the authorized scope.
The flow is: user signs in -> read Organization -> read roles -> read feature permissions -> read data permissions -> check whether requested data belongs to the authorized scope -> allow or reject access.
Even if a user knows a record ID, the user cannot access it through the normal back office without the corresponding data permission.
Data-permission changes can be recorded in operation logs.
Examples include changing organization data scope, adding cross-organization permission, changing team scope, adjusting customer access, changing Desk permission, changing market permission, and changing sensitive field access.
Logs can record operator, operation time, modified user, previous scope, and new scope for permission audits.
The workflow can be understood as: back-office user -> has roles -> roles include feature permissions -> system confirms module access -> reads data permissions -> checks Organization -> checks Team, Desk, Market, Customer, and other scopes -> only returns authorized data -> user views or operates on that data.
Data permissions are the core Finger Manager permission capability for controlling data access scope.
Feature permissions decide which system functions a back-office user can access and operate. Data permissions further decide which organization, team, customer, market, desk, or product data those functions can apply to.
By combining feature permissions, role permissions, and data permissions, institutions can implement fine-grained data isolation and access control in one Finger Manager environment.
