What this category's data looks like
Student status establishment and changes in primary and secondary schools involve three types of materials: student status archives, transfer applications, and suspension/resumption materials. Student status archives are collected by the school and include basic student information, family members, enrollment date, and homeroom teacher signature; transfer applications are submitted by parents and include the names of the transferring-out and transferring-in schools, application date, and seals from both parties; suspension/resumption materials are provided by the guardian and include the reason for suspension, duration, hospital certificate, and resumption receipt. The three types of materials update at different rhythms: student status archives are checked per semester, transfer applications are triggered by events, and suspension/resumption materials are updated according to approval nodes. When entering workflow orchestration, student status archives serve as the baseline record, while transfer applications and suspension/resumption materials serve as change evidence, respectively providing fields, dates, and signature information for progress recording and statistical verification.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction state records. The "progress table and statistical scope description" is continued and completed by subsequent nodes according to the branch. When the user selection node is triggered, the conversation enters an interaction state and records the workflow state; after the user completes the selection, execution continues along the branch corresponding to the selected option.
| Object | Check | Verification action |
|---|---|---|
| Student status archive | Whether fields, dates, and signatures are complete, and whether names and quantities are consistent with the transfer application | Check item by item the name, student status number, enrollment date, and homeroom teacher signature in the student status archive, compare them with the corresponding fields in the transfer application, and record discrepancies |
| Transfer application | Whether the names of the transferring-out and transferring-in schools, application date, and seals match the student status archive | Check the school names, dates, and seals in the transfer application, and verify whether the names and quantities of the record in the student status archive are consistent |
| Suspension/resumption materials | Whether the reason for suspension, duration, hospital certificate, and resumption receipt are complete, and whether versions are synchronized | Check the signatures and receipts in the suspension/resumption materials, and verify whether the dates and quantities of the same record in the two materials are consistent |
| User selection node | Each option corresponds to one branch, the interaction state is recorded, and the selection result variable has been passed to subsequent nodes | Check the options and branch connections one by one in the node, trigger it once to view the node status in the run record, reference variables in subsequent nodes and run a trial, and confirm that nodeId is consistent with the branch direction |
Three common errors
- Symptom: The name or student status number of the same student does not match between the student status archive and the transfer application. Cause: The two materials were collected at different times, versions are not synchronized, and there is no unified verification step.
- Symptom: Suspension/resumption materials lack signatures or receipts, and it cannot be confirmed during statistics whether the change has taken effect. Cause: The approval node did not return data, material flow was interrupted, and progress records did not mark exceptions.
- Symptom: After selecting an option, the default branch is still followed, and the process stops after the interaction is completed. Cause: The options and branch connections were not checked one by one, and the selection result variable was not referenced correctly.
How to verify the setup
Acceptance of this feature: run trials for each option one by one, check the branch direction and interaction state in the run record, and confirm that variables has been passed to subsequent nodes and that nodeId corresponds to the branch.
Business test: use one week of records to check the totals, see whether the scope and exceptions are clearly written, and whether the number of records matches the statistical number.
- Check the options and branch connections one by one in the node, and trigger it once to view the node status in the run record.
- Reference
variablesin subsequent nodes and run a trial once to confirm that the selection result variable is consistent with thenodeIdbranch direction.