What this category's data looks like
In the kindergarten play activity organization scenario, the materials that enter the Q&A acceptance and missing-item follow-up questions feature include observation records, area activity plans, material placement lists, activity objective cards, and reflection records. The correspondence between observation records and area plans determines whether activity objective achievement can be judged at acceptance; the quantity of placed materials is a high-frequency trigger for missing-item identification; converting reflections into next week's plan is the connecting material completed after follow-up questions. The materials come from the class's daily care and education process and are updated weekly. The field characteristics are class, area, activity name, objective items, material name and quantity, observation points, and reflection conclusions. When these materials enter the feature, observation records and plans serve as the basis for acceptance, material lists and objective cards serve as references for missing-item determination, and reflection records serve as the source for completing follow-up question items.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, outputting the response body, status code, and return fields. The "acceptance records and completed follow-up question items" are parsed by subsequent nodes from the response, or handled by an external system according to the agreement to complete the next step. The request URL, path parameters, request headers, and request body can all reference global variables, system variables, or outputs from preceding nodes through variables. Authentication information is placed in Authorization according to the external system's requirements.
| Object | Check | Verification action |
|---|---|---|
| Corresponding materials of observation records and area plans | Determine whether the observation points correspond item by item to the activity objective items in the area plan | Check each placeholder source in the variables panel, and confirm that both the plan items and observation point fields enter the request body |
| Material placement quantity list | Determine whether the material names and quantities meet what the activity objectives require, and whether missing items are identified as follow-up question items | Use one sample request to compare the return fields, and check that the quantity field is non-empty and the follow-up question items point to the missing materials |
| Records of converting reflections into next week's plan | Determine whether the reflection conclusions have been converted into next week's plan items, and whether a follow-up question is triggered when they have not been updated | Check the request header names and value sources, and confirm that both the plan update field and the reflection field come from outputs of preceding nodes |
| HTTP request response body | Determine whether the status code and return fields are consistent with the external interface agreement, and whether responseData can be parsed | View the rendered complete URL in the request preview, and check the return fields against the sample result |
Three common errors
- Symptom: answering directly even though the quantity of placed materials is insufficient. Cause: at acceptance, the material list was not compared with the activity objectives, so the missing item was not identified as a follow-up question item.
- Symptom: still transferring to the handler even though the activity objectives do not match the observation records. Cause: the objective items and observation points were not compared item by item, and the missing-item determination skipped the objective achievement dimension.
- Symptom: entering acceptance even though the reflection records have not been converted into next week's plan. Cause: when the plan was not updated, no follow-up question was triggered, and the reflection field and plan field did not both enter the request body.
How to verify the setup
Acceptance for this feature: preview the rendered request, check the status code and return fields, then compare the result against one sample, confirming that responseData can be parsed and that all variables placeholders have sources.
Business test: submit a question that lacks key information, and see whether it asks a follow-up question before answering.
- In the variables panel, check the source of each placeholder, and confirm that global variables, system variables, and outputs from preceding nodes are all traceable.
- Check the request header names and value sources, and confirm that
Authorizationis passed in according to the external system's requirements and that the request body fields are consistent with the interface agreement.