What this category's data looks like
This category's data looks like this: Enrollment consultation conversion for training institutions involves three core types of materials: enrollment brochures, consultation records, and trial class schedules. Enrollment brochures are usually updated by the marketing or academic affairs department per class term, with fields including course name, number of class hours, start date, fee description, and signature of the person in charge; consultation records are registered one by one by consultants, including student name, intended course, consultation date, follow-up status, and receipt; trial class schedules are arranged by academic affairs, including trial class time, instructor, classroom, and confirmation signature. When entering the exception tracing and manual review function, the three types of materials play different roles: enrollment brochures serve as the baseline standard, used to compare the course names and dates in consultation records; consultation records serve as the original process evidence, used to trace conversion nodes; trial class schedules serve as performance evidence, used to verify attendance and signatures. The material update rhythm is based on class terms and consultation batches as units, and field characteristics are concentrated in four categories: name, quantity, date, and signature. It is common for the same record to fail to match across two materials, for versions to be out of sync, or for signatures or receipts to be missing.
Configuration and implementation checks
Configuration and implementation checks: This step is executed by the HTTP node in the workflow, outputting the response body, status code, and returned fields. The "exception list and review conclusions" are parsed from the response by subsequent nodes, or handled by an external system according to the agreement to complete the rest. The HTTP module sends requests to the target address, and variables can be used as placeholders in all three places: path parameters, request body, and request headers. Variables come from global variables, system variables, or outputs of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Enrollment brochure | Whether the course name, number of class hours, start date, and signature of the person in charge are complete, and correspond item by item with the consultation records | Retrieve the original brochure, verify the fields and signature, then compare the name, quantity, and date with the consultation records |
| Consultation record | Whether the student name, intended course, consultation date, follow-up status, and receipt are consistent with the trial class schedule | Extract one record, trace its original registration and receipt, and verify the date and signature |
| Trial class schedule | Whether the trial class time, instructor, classroom, and confirmation signature match the attendance information in the consultation records | Compare the schedule with the consultation records, and check whether the versions are in sync and whether any signatures are missing |
| HTTP request | Whether the placeholder variables in the request address and path parameters can be resolved into actual values, and whether the request header authentication information is passed in according to the external system's requirements | View the fully rendered address in the request preview, verify the request header names and value sources, and compare the response using a sample request |
Three common errors
- Symptom: The course name for the same student does not match between the enrollment brochure and the consultation record. Cause: After the brochure version was updated, it was not synced to the consultation registration template, resulting in deviations in the name and date.
- Symptom: The date on the trial class schedule is inconsistent with the attendance date in the consultation record. Cause: After the schedule was adjusted, it was not written back to the consultation record, and the two materials each retained the old version.
- Symptom: The consultation record lacks the student receipt or the signature of the person in charge. Cause: The registration step did not enforce validation of the signature field, so the responsible node cannot be confirmed during exception tracing.
How to verify the setup
How to verify the setup: Acceptance for this function: preview the rendered request, check the status code and returned fields, then compare the result against one sample; at the same time, verify whether the Authorization request header, the variables variable sources, and the responseData returned fields are consistent with the external interface agreement.
Business test: Create an exception record, see whether the source material can be traced, confirm that the exception is supported by original records and has the reviewer's signature, and hand it over to the person in charge for handling.
- In the variables panel, verify the source of each placeholder, and confirm that the variables in the request address, request headers, and request body can all be traced to global variables, system variables, or outputs of preceding nodes
- Use a sample request to compare the returned fields, check whether the external system received empty fields, and record the status code and response body for the exception list