What this category's data looks like
This page addresses the kindergarten home-school co-education communication scenario. The materials cover four types of records: commitment items and response times, descriptions of children's performance, classification of parents' requests, and notification delivery. Sources are mostly class teachers' daily observations, parent feedback, and kindergarten notification archives, with updates rolling according to weekly communication and activity milestones. Field characteristics include the committing party and response deadline, correspondence between observation records and statements, requests assigned to categories, and delivery status. When materials enter the workflow, commitment items and response times serve as the basis for deciding whether to continue follow-up, descriptions of children's performance are used to check whether statements match observation records, classification of parents' requests determines the branch direction, and notification delivery records are used to confirm whether the interaction is complete.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction status records. The "version ledger and change records" are completed by subsequent nodes continuing execution along the branch. When the user selection node is triggered, the conversation enters an interaction state and records the workflow status. After the user completes the selection, execution continues along the branch corresponding to the selected option.
| Object | Check | Verification action |
|---|---|---|
| Commitment items and response times | Whether the commitment item receives a response within the agreed time; if not, it must enter the pending follow-up branch | In the user selection node, check the options and branch connections one by one, confirm that when a commitment has not been responded to it goes to the reminder branch, and record nodeId and the interaction status |
| Descriptions of children's performance | Whether the statement matches the observation record; if not, it must return to the verification branch | Trigger a user selection once, check the node status in the run records, confirm the description matches the observation record before continuing, and reference variables for parameter passing |
| Classification of parents' requests | Whether the request is assigned to an existing category; if not, it must enter the supplementary classification branch | In subsequent nodes, reference the selection result variable and run a trial once, confirm the classification branch direction is correct, and record variables and nodeId |
| Notification delivery | Whether the notification is delivered and triggers the parent's selection; if not delivered, it must re-enter the interaction | In the run records, check the interaction status after delivery, and confirm the option corresponds to the branch and is consistent with the delivery result |
Three common errors
- Symptom: A commitment item does not receive a response within the agreed time, but the process continues downward. Cause: The user selection node does not connect the no-response option to the pending follow-up branch, so the branch direction is disconnected from the commitment status.
- Symptom: The ledger is updated from the original performance statement despite a conflicting observation record. Cause: The verification branch does not record the discrepancy in the interaction status, and subsequent nodes directly reuse the old statement.
- Symptom: A parent's request enters subsequent processing without being classified. Cause: The option and branch connections do not cover the unclassified case, so after the interaction is completed the process stalls or takes the default branch.
How to verify the setup
Acceptance of this feature: run trials option by option, check the branch direction and interaction status in the run records, confirm each option corresponds to one branch, and check whether variables and nodeId are passed as expected.
Business test: change one piece of content, see whether the version number and references are updated synchronously, and confirm that the current version is unique, old versions are traceable, and references are synchronized.
- In the user selection node, check the options and branch connections one by one, and confirm that cases such as a commitment not being responded to and a request not being classified all have corresponding branches.
- Trigger a user selection once, check the node status and selection result variables in the run records, and confirm that the process continues after the interaction is completed.