On-site Operations Outsourcing Service: Operations Duty Rotation and Internal Work Order Q&A - Permission and Data Isolation

Data for this category typically comes from the client’s ITSM system, monitoring platform, asset inventory, and internal duty records. Four types of

What the data for this category looks like

Data for this category typically comes from the client’s ITSM system, monitoring platform, asset inventory, and internal duty records. Four types of documents are produced regularly: on-site daily reports, service desk work orders, inspection reports, and SLA monthly reports. On-site daily reports are updated daily, and include on-site handling items and daily inspection status for the current day. SLA monthly reports are compiled monthly, covering fields such as service compliance rate and work order response time. All data is bound to the corresponding client’s on-site service contract, and fields change based on the client’s IT asset configuration and service scope adjustments.

What constraints do these characteristics impose on permission and data isolation?

Different clients’ on-site service data has strict contractual boundaries. Teams must avoid cross-client data leakage. Daily-updated on-site daily reports and work order data have strong timeliness. Permission configurations must support real-time verification of the accessing subject’s service scope. Monthly-generated SLA reports involve client service assessment indicators. Teams must lock edit and view permissions for the corresponding tenant. On-site engineers can only access client IT asset data for their assigned areas. They cannot access operation and maintenance information of other clients without authorization. Data sources include the client’s own systems. Teams must isolate access permissions between the outsourcing team and the client’s internal IT department to prevent sensitive asset information leakage.

How to set the configurations

The configurations in this chapter apply to FastGPT v4.17.0.

Configuration ItemRecommended PracticeRationale
Tenant Isolation ConfigurationCreate an independent tenant for each on-site service projectMatch the service contract boundaries of different clients to avoid cross-client data confusion
Team Permission BindingAssign exclusive permission groups based on the on-site engineer’s assigned areaRestrict engineers to only access operation and maintenance data for their assigned clients
Data Storage PartitionDivide independent storage directories by tenant, set the single-tenant storage limit to 1000 MBEnsure physical isolation of data such as work orders and on-site daily reports, prevent resource preemption
Access Timeliness VerificationConfigure an access validity period of 1 hour for daily-updated dataAdapt to the real-time requirements of on-site daily reports, prevent leakage of expired sensitive data
Permission Audit LogEnable full access log recording, set the log retention period to 30 daysFacilitate tracing of cross-permission access behaviors, meet compliance requirements of service contracts
Model Key IsolationBind exclusive model invocation keys for each tenantIsolate model cost statistics by tenant, match commercial version permission requirements

Three common misconfigurations

  • Symptom: Unauthorized on-site engineers view cross-client on-site work order data. Cause: Independent tenant permissions are not configured per on-site service project, resulting in ineffective isolation of operation and maintenance data for different clients.
  • Symptom: Team-level permission management cannot be enabled in a local deployment environment. Cause: Tenant management module initialization configuration is not completed, resulting in the permission isolation logic not being loaded.
  • Symptom: SLA monthly report data from different clients is incorrectly merged and displayed. Cause: Data storage partitions are not divided by tenant, resulting in cross-tenant historical data being returned during retrieval.

How to confirm the configuration is complete

  • Log in to the backend of different tenants, attempt to access work order data from other tenants, and confirm that access is denied.
  • View the permission audit log, confirm that all access operations record information about the corresponding tenant and accessing subject.
  • Export on-site daily report data for a specified tenant, confirm that it only includes content related to that service project.
  • Verify the binding relationship of model invocation keys, confirm that keys from different tenants cannot be used across tenants.

The values provided here 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.