What this category's data looks like
This page is intended for primary and secondary school admissions organizations. The materials include three categories: admissions plans, application material checklists, and admission lists. Admissions plans come from education authorities and school admissions committees, and are updated by academic year or batch. Fields include admissions scope, time nodes, admission rules, and signature fields. Application material checklists are compiled by the admissions office and updated by application stage. Fields include material name, number of copies, submission date, and receipt. Admission lists are confirmed by the admissions leadership group and updated by batch publication. Fields include student name, ID number, admission status, and signature. When these three categories of materials enter the Q&A intake and missing-item follow-up function, the admissions plan serves as the rule basis, the application material checklist serves as the basis for determining missing items, and the admission list serves as the source for result verification.
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 items to be completed" are parsed from the response by subsequent nodes, or handled externally according to the agreement to complete the process. The HTTP node sends a request to the target address. Path parameters, request body, and request headers can all use variable placeholders. Variables come from global variables, system variables, or outputs from preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Admissions plan | Whether the fields, dates, and signatures for admissions scope, time nodes, admission rules, and signature fields are complete and consistent with the application material checklist | Check the plan version number and effective date, and inspect the signature fields; view the fully rendered address in the request preview to confirm the source of variables |
| Application material checklist | Whether the fields for material name, number of copies, submission date, and receipt correspond to the requirements of the admissions plan, and whether missing items can be identified | Compare the checklist with the plan clauses item by item and mark missing items; use a sample request to compare the response and check how Authorization is passed in |
| Admission list | Whether student name, ID number, admission status, and signature are consistent with the application material checklist and admissions plan | Check the list batch and publication date, and inspect signatures and receipts; in the variable panel, check the source of each placeholder in responseData |
| Intake record | Missing items are identified and followed up on, answers are based on materials, and the record destination is handling by the assigned person | Ask a question missing key information and see whether it first follows up before answering; check whether the intake record fields and follow-up items are complete |
Three common errors
- Symptom: The material name, number of copies, and date for the same record do not match between the admissions plan and the application material checklist. Cause: The two materials are updated separately, without field-level comparison and version checking.
- Symptom: The versions of the admission list and the application material checklist are not synchronized, and the publication batch and application batch are misaligned. Cause: After the list is confirmed, it is not written back to the checklist, and the interface return fields are inconsistent with the agreement.
- Symptom: The intake record lacks a signature or receipt, and the follow-up items do not cover key fields. Cause: The missing-item determination rules are not implemented at the field level, and empty fields returned by the HTTP node are not identified.
How to verify the setup
Preview the rendered request, check the status code and returned fields, then compare the result against a sample to confirm that the placeholders in Authorization, variables, and responseData are parsed correctly.
Business test: Ask a question missing key information and see whether it first follows up before answering.
- In the request preview, view the fully rendered address and check that the placeholder variables in the path parameters, request headers, and request body can be resolved into actual values.
- Use a sample request to compare the response, check that the request body fields are consistent with the external interface agreement, and record the number of array items and the tokens of the referenced text.