What this category's data looks like
The category materials for school safety hazard inspections and campus incident reporting include safety inspection checklists, hazard rectification ledgers, and emergency incident reports; together, the three form a chain of evidence from discovery to closure. Safety inspection checklists are filled in weekly or monthly by duty personnel, recording location, name, and quantity; hazard rectification ledgers are updated on a rolling basis by hazard number, recording the rectification date and the signature of the person responsible; emergency incident reports are written separately by incident number, recording the time, personnel involved, and the receipt from the higher-level authority. When the three types of materials enter the authorized access and external services function, the safety inspection checklists and ledgers serve as the basic data within the internal visibility scope, and the incident reports serve as the objects opened to parents or higher-level authorities; the field characteristics are concentrated in the four types of name, quantity, date, and signature, the update cadence is mainly daily or weekly, and versions are distinguished by number and date.
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 "externally available entry points and authorization scope" are completed by subsequent nodes parsing the response, or by an external system handling it as agreed. The HTTP node does not replace the external system in writing to the database or approving; it is only responsible for sending requests as agreed and retrieving the results.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | The location name, inspection quantity, and inspection date are consistent within the checklist, and the signature field has a value | In the request preview, look at the fully rendered URL, and check whether the request body fields are consistent with the name, quantity, and date in the checklist |
| Hazard rectification ledger | The hazard number, rectification date, and signature of the person responsible match across the three materials; when versions are not synchronized, the latest date prevails | Check the request header names and the sources of their values, confirm that the authentication information is passed in as required by the external system, and compare the numbers in the ledger and the report |
| Emergency incident report | The incident number, personnel involved, and reporting date are consistent with the ledger, and the higher-level receipt is complete | Use a sample request to compare the return, confirm that the response body fields correspond to the report fields, and mark as pending supplementation when the receipt is missing |
| Request URL and path parameters | Placeholder variables can be resolved into actual values, and the path parameters are consistent with the external interface agreement | In the variables panel, check the source of each placeholder, and confirm that the variables come from global variables, system variables, or the output of preceding nodes |
Three common errors
- Symptom: The name or quantity of the same hazard does not match between the safety inspection checklist and the rectification ledger. Cause: The two are entered separately, and the unified field is not written back by hazard number.
- Symptom: The dates in the emergency incident report and the ledger are inconsistent, and the versions are not synchronized. Cause: The report is written first and the ledger is entered later, and the dates are not aligned by the same incident number.
- Symptom: The request returns 401, and the external system receives empty fields. Cause: The request header authentication information is not passed in as required by the external system, and the request body fields are inconsistent with the agreement.
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; in the variables panel, check the source of each placeholder in variables, and confirm the value paths of Authorization and responseData.
Business test: access once with a restricted identity, and see whether the visibility scope matches the setting.
- In the variables panel, check the source of each placeholder, confirm that the variables come from global variables, system variables, or the output of preceding nodes, and compare the request header names and the sources of their values.
- Use a sample request to compare the return, check whether the request body fields are consistent with the fields of the safety inspection checklist, hazard rectification ledger, and emergency incident report, and mark as pending supplementation when a signature or receipt is missing.