What this category's data looks like
School safety hazard inspections and campus incident reporting; materials include safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are filled out weekly or monthly by the inspector, containing inspection items, location, date, and signature; hazard rectification ledgers are registered by hazard number, containing the rectification responsible person, deadline, acceptance conclusion, and signature; emergency incident reports are submitted by incident occurrence time, containing the process, handling, receipt, and signature. When these three types of materials enter the abnormal traceability and manual review function, the safety inspection checklist provides the original discovery record, the hazard rectification ledger provides evidence of the rectification closed loop, and the emergency incident report provides evidence of the incident and receipt. In terms of update cadence, the safety inspection checklist updates with inspection batches, the ledger updates with rectification progress, and incident reports update with reporting and handling milestones. Field characteristics center on names, quantities, dates, signatures, and receipts, and the same record must be able to align across the three materials.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, which outputs the response body, status code, and returned fields. The "abnormal list and review conclusion" is parsed from the response by subsequent nodes, or handled externally by an external system according to the agreement to complete the rest. The HTTP module sends requests to the target address; path parameters, request body, and request headers can all use variable placeholders, and the variables come from global variables, system variables, or the output of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Inspection items, location, date, and signature are complete, and the names, quantities, and dates can align with the ledger and incident reports | In the variable panel, check the placeholder sources, confirm that the checklist fields brought into the request body are consistent with the external interface agreement, and compare the response using a sample request |
| Hazard rectification ledger | Hazard number, rectification responsible person, deadline, acceptance conclusion, and signature are complete, and the version is synchronized with the inspection checklist | Check the request header names and value sources, confirm that authentication information is passed in according to the external system's requirements, and then compare the ledger fields with the returned fields |
| Emergency incident report | Incident process, handling, receipt, and signature are complete, and the date is consistent with the ledger and inspection checklist | In the request preview, view the fully rendered address, confirm that path parameters resolve to actual values, and check whether the report fields are correctly sent with the request body |
| HTTP node output | The response body, status code, and returned fields can be parsed by subsequent nodes, and abnormal records can be traced back to the source materials | Use responseData to check the returned fields, use variables to check the source of each placeholder, and use Authorization to check the authentication header |
Three common errors
- Symptom: The name and quantity of the same hazard do not match between the safety inspection checklist and the ledger. Cause: The two entries were not filled in according to the same number and standard, lacking cross-material comparison.
- Symptom: The date of the emergency incident report is inconsistent with the rectification date in the ledger. Cause: The versions were not synchronized; after the report was updated, the ledger was not updated accordingly, making alignment impossible during traceability.
- Symptom: The review conclusion lacks a signature or receipt. Cause: The manual review step did not implement signature and receipt retention, so the abnormal list lacks supporting materials.
How to verify the setup
This function's acceptance: preview the rendered request, check the status code and returned fields, then compare the result against a sample; use responseData to check the returned fields, use variables to check the placeholder sources, and use Authorization to check the authentication header.
Business test: create an abnormal record, see whether it can be traced back to the source materials, and confirm that the abnormality is supported by original records and the reviewer's signature.
- In the variable panel, check the source of each placeholder, and confirm that the variables in the request address, path parameters, request headers, and request body can all resolve to actual values.
- Compare the response using a sample request, check that the request body fields are consistent with the external interface agreement, and confirm that the abnormal list and review conclusion are handed to the responsible person for handling.