What this category's data looks like
This page addresses the kindergarten operation behavior and quality self-assessment scenario; the materials include three categories: self-assessment reports, issue lists, and rectification plans. Self-assessment reports are filed by the kindergarten per semester and contain items such as operating conditions, safety and hygiene, and care and education, with fields including indicator name, self-assessment conclusion, date, and signature. Issue lists come from routine supervision and internal inspections, with fields including issue description, responsible position, rectification deadline, and receipt. Rectification plans follow on from the issue lists, with fields including measures, responsible person, completion date, and signature. When these three categories of materials enter this function, the self-assessment report serves as the primary record source, the issue list serves as the basis for missing-item comparison, and the rectification plan serves as the follow-up content and the destination for completion. The update cadence rolls forward by semester and rectification cycle; old versions must be marked as obsolete to avoid the same record having mismatched names, quantities, or dates across two 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 "intake record and completed question items" are parsed from the response by subsequent nodes, or handled by an external system per agreement to complete the process. The request URL, path parameters, request headers, and request body can all be placeheld via variables, whose values come from global variables, system variables, or the output of preceding nodes; authentication information is placed in Authorization per the external system's requirements.
| Object | Check | Verification action |
|---|---|---|
| Self-assessment report | The indicator name, self-assessment conclusion, date, and signature must correspond item by item with the issue list; the name and quantity of the same record must not be inconsistent in two places | In the request preview, view the complete rendered URL and check whether the fields of that record in responseData are consistent with the self-assessment report |
| Issue list | The issue description, responsible position, rectification deadline, and receipt must be complete; a missing signature or receipt is deemed a missing item | Use one sample request to compare the response and check whether each placeholder in variables can be traced to the source of the issue list field |
| Rectification plan | The measures, responsible person, completion date, and signature must align with the same record in the issue list; when versions are not synchronized, the latest signed document prevails | Check the request header names and value sources, and confirm that after Authorization is passed in, the returned fields include the completed question items |
| HTTP node output | The response body, status code, and returned fields serve only as the basis for intake and follow-up, and do not replace the external system's database write or approval | In the variables panel, check the source of each placeholder; when there is a timeout or empty field, follow up first before answering |
Three common errors
- Symptom: the name and quantity of the same rectification record do not match between the self-assessment report and the issue list. Cause: the two places were entered separately, without writing back and comparing against the same record number.
- Symptom: the rectification plan has been updated, but the intake side still follows up based on the old version. Cause: versions are not synchronized, obsolete documents are not marked, and the placeholder variables pick up expired node output.
- Symptom: the issue list is missing a signature or receipt, yet an answer is still given directly after follow-up. Cause: missing-item identification did not intercept it, and the empty fields returned by the HTTP node were treated as valid values by subsequent nodes.
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 one sample to confirm that the three placeholders responseData, variables, and Authorization are all parsed into actual values.
Business test: submit a question missing key information and see whether it follows up first before answering.
- In the request preview, view the complete rendered URL and check item by item the placeholder sources of the path parameters, request headers, and request body.
- Use one sample request to compare the returned fields, confirm that missing items are identified and followed up, and then forward to the person handling it.