What this category's data looks like
This category's data covers three core types of materials: daily life schedules, morning and afternoon check records, and child health observation records. The daily life schedule is compiled by the childcare and education department on a per-semester basis, with fields including activity segment name, start and end times, activity type, and responsible person; the morning and afternoon check records are filled in by class teachers every half day, with fields including child's name, body temperature, oral and hand condition, abnormal description, and teacher's signature; the child health observation records are registered by health care personnel as needed, with fields including observation date, symptoms, handling measures, parent receipt, and health care worker's signature. The three types of materials come from different sources and have different update rhythms: the schedule is revised as seasons or kindergarten adjustments change, the morning and afternoon check records accumulate day by day, and the health observation records are triggered by individual events. When the materials enter workflow orchestration, the schedule serves as the baseline version for node comparison, while the morning and afternoon check records and health observation records serve as reference sources, and their fields, dates, and signatures need to stay synchronized with the baseline version.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction state records. The "version ledger and change records" are then completed by subsequent nodes continuing execution according to the branch. When a 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 |
|---|---|---|
| Daily life schedule | Whether the fields, dates, and signatures are consistent with the current version, and whether the activity segment names and counts match up | Check the options and branch connections one by one in the node, confirm that the schedule version option points to the corresponding branch, and view the node status in the run records |
| Morning and afternoon check records | Whether the names, counts, and dates of the same record match across the two materials, and whether missing signatures or receipts are identified | Reference the selection result variable in a subsequent node and run a test, then check whether the record reference updates synchronously with the branch |
| Child health observation records | Whether the observation date, symptoms, handling measures, parent receipt, and health care worker's signature are complete and synchronized with the baseline version | Use variables and nodeId to locate the reference source, and check the version attribution of that record in the branch direction |
| Version ledger and change records | Whether the current version is unique, old versions are traceable, and reference synchronization holds | After changing one piece of content, run a test to see whether the version number and references update synchronously, and record the branch direction and interaction state |
Three common errors
- Symptom: The names, counts, and dates of the same record do not match between the schedule and the morning and afternoon check records. Cause: The materials come from different sources, and the fields are not aligned to the baseline version.
- Symptom: An old version of the schedule is still referenced, and the version number is not updated when the content changes. Cause: The version is not synchronized, and the branch does not point to the current version.
- Symptom: The health observation record is missing the parent receipt or the health care worker's signature. Cause: The signature fields are not included in the check, and the process stops after the interaction is completed.
How to verify the setup
Feature acceptance: Run tests on each option one by one, check the branch direction and interaction state in the run records, confirm that each option corresponds to one branch, and that the selection result variable has been passed to subsequent nodes.
Business test: Change one piece of content, see whether the version number and references update synchronously, and check the reference results of variables and nodeId in subsequent nodes.
- Check the options and branch connections one by one in the node, and confirm that no option still follows the default branch.
- Trigger a user selection node once, view the node status in the run records, and confirm that the process continues after the interaction is completed.