Overview of this category of data
This category of data primarily comes from customer data center environments, equipment inventories, software packages, and network topologies. Daily supporting documents include deployment manuals, installation records, configuration lists, and on-site check-in sheets. Data is updated per order or per phase, with incremental additions and adjustments as on-site deployment proceeds. Involved parties include implementation engineers, system engineers, and customer IT staff. Common data fields include device models, software versions, configuration parameters, and on-site check-in information. There are no unified standardized units, so adjustments must be made flexibly based on the customer’s specific on-site environment.
Constraints on permission and data isolation
Most data in this category constitutes private on-site environment assets for customers, and is updated with each deployment order. As such, permission and data isolation measures must prevent accidental leakage of deployment documents and configuration parameters between different customers. Additionally, personnel participating in a single deployment include both implementation engineers and customer IT staff, so role-based operation permissions must be clearly differentiated to block unauthorized modifications to customer on-site configurations. Finally, since there are no unified standardized data fields, isolation configurations must adapt to custom data structures for each customer. Hard-coded isolation rules based on fixed fields are not recommended.
The following configurations are based on FastGPT v4.17.0.
Configuration Settings
| Configuration Item | Recommended Configuration | Rationale |
|---|---|---|
teamId | Unique identifier bound to a single deployment order, use the unique number of the deployment order as the value | Matches the independent data scope of each deployment order to achieve single-level isolation |
tmbId | Exclusive identifier bound to the implementation team, use the unique ID obtained after team registration as the value | Differentiates operation permissions between different implementation teams to avoid cross-team data access |
| Team role permissions | Divide permissions into two roles: implementation engineer and customer IT staff. Implementation engineers have read/write access to deployment documents and configuration parameters, while customer IT staff only have read access to on-site check-in sheets and equipment inventories | Differentiates the operation boundaries of the two participating parties to prevent unauthorized modifications |
| Data storage directory | Divide independent storage paths by deployment order, with the path format /fastgpt/deploy/{teamId}/{tmbId} | Matches the independent data update rhythm of each deployment order to avoid cross-order data confusion |
| Permission effective timing | Set to real-time effective, with synchronization to all deployment nodes within 10 seconds after adjustment | Adapts to the rapid adjustment needs of on-site deployment, avoiding operational risks caused by delayed permissions |
| Dynamic permission switch | Open corresponding permissions according to the deployment phase. For example, open software package upload permissions during the installation phase, and open configuration modification permissions during the debugging phase | Adapts to the progress flow of on-site deployment, only opening necessary operation permissions for the current phase |
Three Common Misconfigurations
- Phenomenon: The interface displays configuration parameter lists across deployment orders, with no permission intercept prompt. Cause:
teamIdis not used to bind deployment orders, and permissions are only divided by team identifiers, leading to cross-order data leakage. - Phenomenon: After inviting customer IT staff to join the corresponding deployment team, the recipient does not receive any permission notifications. Cause: The message push switch for team invitations is not configured, and permissions are not manually synchronized to the corresponding deployment nodes.
- Phenomenon: Custom plugins cannot normally call customer private deployment data, returning an insufficient permissions error. Cause: The permission scope of the plugin is not configured, causing the plugin to access unauthorized deployment order data.
How to Verify Proper Configuration
- Log in to the accounts corresponding to the
teamIdof different deployment orders, and check if only the deployment documents and configuration parameters of the corresponding order can be viewed. - Invite customer IT staff to join the corresponding deployment team, and check if they can receive permission notifications and only view documents within the authorized scope.
- Modify the configuration parameters of a deployment order, and check if accounts from other deployment orders cannot access the modified content.
- Switch the
tmbIdof the implementation team, and check if only deployment order data managed by the corresponding team can be operated.
The values provided are common starting points and should be measured 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.