What this category’s data looks like
This category of data originates from SIEM, EDR, firewall logs, and host images, with updates occurring in real time or triggered per individual incident. Daily delivered documents include incident response reports, forensic records, disposal plans, and notification materials. Core fields cover incident unique identifiers, attack source addresses, disposal execution times, evidence chain verification values, and notification scopes. All data is real-time business information associated with a single incident.
What constraints these characteristics impose on the workflow orchestration link
Decentralized data sources and real-time updates require workflows to bind to single-incident trigger nodes, to avoid timing chaos caused by batch processing. Document fields include unstructured logs and structured verification values, so support for multi-type variable extraction steps is needed. Single-incident data volume fluctuates widely, so adaptive context length limits must be configured to prevent workflow interruptions from data overload. Additionally, disposal plans must be linked to real-time data from forensic records, requiring zero delayed loss of data transfer between workflow nodes. The content on this page is based on the workflow operating mechanism of FastGPT v4.17.0.
How to set the configurations
| Configuration Item | Recommended Practice | Rationale |
|---|---|---|
variables | Bind event ID, attack source IP, and forensic path as preset variables | Match core fields of incident response data to ensure reusability across nodes |
nodeId | Use link type plus event ID suffix, such as dissect_log_${eventId} | Facilitate troubleshooting of workflow exceptions for single incidents, to quickly locate links |
| Variable extraction trigger condition | Trigger based on the output of the log parsing completion node | Ensure extracted keywords come from complete raw data, to avoid truncation |
| Context length limit | 800–1200 characters, calibrated based on actual testing | Adapt to the standard document length of forensic records and disposal plans, to prevent overflow |
| Tool call trigger logic | Let the model independently judge whether to call forensic tools | Match dynamic disposal needs in incident response scenarios, no fixed calls required |
| Timeout threshold | 600 seconds | Cover the standard execution duration of log parsing and evidence chain verification, to avoid false timeout judgments |
Three common mistakes
- Global variables are empty after the workflow runs, making subsequent nodes unable to read event IDs. This occurs because the corresponding data source variable is not bound during the workflow startup phase, or the variable name does not match the node output field.
- The tool call link cannot obtain preset authentication parameters. This occurs because global variables are not correctly passed to the tool's configuration items, causing the tool to fail to read runtime-generated information.
- The number of keyword extraction results does not match the raw logs. This occurs because the extraction trigger node executes before log parsing is complete, leading to incomplete extracted content.
How to confirm the configuration is complete
- Manually trigger a single-incident test workflow, check whether the variable output of each node matches the core fields of the raw logs.
- View the workflow running logs, confirm that node names follow preset rules, with no duplicate or abnormal characters.
- Simulate a data overload scenario, verify that the context length limit takes effect and the workflow does not show interruption errors.
- Trigger the tool call link, confirm that the model can independently choose whether to call forensic tools based on current incident data.
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.