What This Category of Data Looks Like
Data for this category primarily originates from customer ITSM systems, monitoring platforms, asset inventories, and on-duty logs. Daily produced documents include on-site daily reports, service desk tickets, inspection reports, and SLA monthly reports. Fields cover ticket numbers, inspection items, SLA achievement rates, on-duty staff information, and additional relevant details. Data updates follow a mostly daily schedule; some monthly summary documents such as SLA monthly reports are updated once per month. Data is associated with three stakeholder groups: on-site engineers, service managers, and customer IT departments. Each group has distinct operational permission boundaries.
Constraints Imposed on Permission and Data Isolation
Data sources include customer-owned systems. Strict isolation of operational data across different customers is required to prevent cross-customer information leaks. Variations in update frequencies for documents such as on-site daily reports and inspection reports mean permission configurations must adapt to access rhythms for different document types. Operational permissions for the three stakeholder groups must be clearly differentiated: On-site engineers may only access tickets and inspection records assigned to them. Service managers may view all data for their team. Customer IT departments may only view content under their corresponding service contracts. Monthly SLA reports involve contract performance data, so additional approval-level permissions must be implemented to prevent unauthorized modifications. The mobility of on-site staff also requires permission configurations that can be adjusted quickly, to prevent terminated employees from retaining access to customer data.
Configuration Settings
The following configurations are based on the permission management module of FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
teamId | Fixed ID bound to the customer’s service contract | Matches the operational data boundaries of different customers to prevent cross-customer data access |
tmbId | Unique identifier divided by on-site teams | Isolates ticket and inspection record data across different on-site teams |
| User role permission mapping | On-site engineers are granted read/write permissions only for assigned tickets. Service managers are granted view permissions for all team data. Customer IT departments are granted read-only permissions only for data under their corresponding contracts | Aligns with the business operation scope of the three stakeholder groups: on-site engineers, service managers, and customer IT departments |
| Data isolation update frequency adaptation | Daily data permissions take effect in real time. Monthly data permissions switch according to the natural month | Matches the update rhythms of on-site daily reports and SLA monthly reports |
| Automatic permission revocation | Automatically revoke permissions within 72 hours after an on-site staff member leaves | Prevents terminated employees from retaining access permissions, complying with security and compliance requirements |
| Conversation record permission control | Only allow creators and authorized roles to view conversation records. Hide content without permissions by default | Avoids direct error prompts for unauthorized users |
Three Common Misconfigurations
- Issue: Data cross-team leakage occurs when different on-site engineers use identical global variables. Cause: The variable scope is not bound via
teamIdortmbId, resulting in global variables not being isolated by team. - Issue: After a team switch, the team data returned by the tokenLogin interface is not synchronized to the current session. Cause: Team data is not bound to the permission identifier of the current session, resulting in permission cache not being refreshed.
- Issue: The prompt "No permission to operate this conversation record" is displayed when the knowledge base responds, and the prompt cannot be dismissed. Cause: No role permission filtering rules are configured for conversation records. Unauthorized user access directly returns an error without hiding the content first.
How to Verify Proper Configuration
- An on-site engineer logs in, verifies that only assigned tickets and inspection records are visible, and data from other on-site teams cannot be accessed.
- A team switch operation is performed, and the system loads team data that matches the selected team.
- A user with an unauthorized role accesses conversation records, verifies that only a no-permission prompt is displayed or the corresponding content is hidden, with no forced direct error.
- A permission revocation test is triggered, and verifies that access permissions for terminated accounts are restricted according to the configured rules.
The values provided are common starting points, and should be evaluated against the reader’s own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.