What this category's data looks like
This page addresses the course selection, scheduling, and classroom resource dispatch category. Materials come from three types of source documents: course offering plans, scheduling tables, and course selection rules, and are updated on a rolling basis according to the semester cycle and the rhythm of temporary schedule changes. Course offering plan fields include course name, class, week number, and teacher signature; scheduling table fields include classroom, period, capacity, and date; course selection rule fields include priority, enrollment limit, and effective version. When the three types of materials enter the form input node, their roles differ: the course offering plan serves as the main record providing the course name and week number, the scheduling table serves as the resource record providing the classroom and period, and the course selection rules serve as the constraint record providing the enrollment limit and version number. The form collects these field values item by item, and after submission passes them to subsequent nodes, where subsequent nodes or humans use them to draft signable material drafts and handover records. The field characteristic is that five types of information—name, quantity, date, version, and signature—need to be aligned across materials, and missing items are blocked by required markers before submission.
Configuration and implementation checks
This step is executed by the form input node (interaction node) in the workflow, which outputs the field values filled in by the user (passed to subsequent nodes after submission). The signable material drafts and handover records are then completed by subsequent nodes or humans. After the form input node is triggered, the conversation enters an interactive state and records the workflow state. After the user fills in the required items and submits, the form information is passed to subsequent nodes for use.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | The course name, class, week number, and teacher signature match the corresponding records in the scheduling table item by item, and the date and version number are in sync | Check the field names one by one in the node configuration, confirm that the course name and week number are marked as required, and after submission check whether subsequent nodes can reference these fields |
| Scheduling table | The classroom, period, capacity, and date match the name, quantity, and date of the same record in the course offering plan | Check the required settings one by one, run a trial submission, reference the classroom and period fields in subsequent nodes, and view the values |
| Course selection rules | The enrollment limit, priority, and effective version are consistent with the scheduling table capacity, and signatures or receipts are complete | Reference the version number field in subsequent nodes and run a trial, confirming that the field value is passed to the next stage along with the submission |
| Handover record | The responsible person, receipt time, version, and date are consistent, and missing items are blocked at submission | Draft one according to the template and complete one handover, observe whether submission is possible when required items are empty, and check the receipt fields |
Three common errors
- Symptom: The name, quantity, or date of the same course does not match across two materials. Cause: The course offering plan and scheduling table are maintained separately, and the fields enter the form without being checked item by item.
- Symptom: The course selection rule version is not synchronized, and the old version number still circulates with the scheduling table. Cause: The version field is not marked as required, and after submission subsequent nodes retrieve an expired value.
- Symptom: The handover record lacks a signature or receipt, and the conversation stays in the interactive state. Cause: The required markers do not cover the signature and receipt fields, and after submission subsequent nodes cannot retrieve the values.
How to verify the setup
Acceptance of this feature: fill it in once and submit, check the field values retrieved by subsequent nodes, and confirm that the fields referenced by userSelect after formInput submission match what was filled in.
Business test: draft one according to the template and complete one handover, and see whether missing items are blocked.
- Check the field names and required settings one by one in the node configuration, and confirm that key material fields are marked as required.
- Reference the
formInputResultandselectResultfields in subsequent nodes and run a trial, checking the field transfer after submission and the consistency of version and date.