What this category's data looks like
This page addresses the scenario of student status changes and graduation eligibility review. The materials come from three ledgers: leave/resume-of-study applications, major transfer applications, and graduation review checklists, updated weekly or monthly. Leave/resume-of-study applications record the student ID, change type, effective date, and approval signature; major transfer applications record the original major, target major, assessment conclusion, and receipt; graduation review checklists record course credits, review conclusion, and signature field. After the three materials enter the workflow, each serves as an independent data source, separately providing fields, dates, and signature information for reconciliation of the progress table and the statistical scope description. Field characteristics center on three categories: names, quantities, and dates: the name spelling, record count, and effective date of the same student's change record must remain consistent across the two materials; when versions are not synchronized or signatures or receipts are missing, the statistical scope must state the exception handling method in the table header.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, which outputs the response body, status code, and returned fields. The "progress table and statistical scope description" is completed by subsequent nodes parsing the response, or by an external system handling it as agreed. The HTTP node does not replace the external system in writing to the database or approving; it is only responsible for sending requests as agreed and retrieving the results.
| Object | Check | Verification action |
|---|---|---|
| Leave/resume-of-study application | The three categories of fields—student ID, change type, effective date, and approval signature—match across the two materials in name, quantity, and date | Take one leave/resume-of-study record, verify the rendered complete address and request body fields in the request preview, and compare the returned fields with the ledger |
| Major transfer application | Original major, target major, assessment conclusion, and receipt are complete, with no missing items in the date and signature fields | Verify the request header names and the sources of their values, confirm that the authentication information is passed in as required by the external system, and then compare the sample response |
| Graduation review checklist | Course credits, review conclusion, and signature field correspond item by item, and the record count matches the statistical total | Verify the source of each placeholder in the variables panel, and confirm that variables, responseData, and Authorization can all be traced to specific origins |
| Progress table and statistical scope description | The table header states the scope and exception rules, and the weekly record total matches the statistical count | Use one week's records to verify the total, check whether the scope and exceptions are clearly stated, and then proceed to the weekly or monthly report |
Three common errors
- Symptom: The name, quantity, and date of the same record do not match between the leave/resume-of-study application and the major transfer application. Cause: The two materials are maintained separately and are not merged and reconciled under a unified scope.
- Symptom: The version of the graduation review checklist is not synchronized, and the signature field is missing in the old version. Cause: The update cadence is inconsistent, and exceptions are not marked in the table header when signatures or receipts are missing.
- Symptom: The request returns 401, the external system receives empty fields, or the request times out. Cause: The authentication information is not passed in as required by the external system, and the placeholder variables are not parsed into actual values.
How to verify the setup
This feature's acceptance: preview the rendered request, check the status code and returned fields, and then compare the result against one sample; at the same time, verify the value sources of the three identifiers Authorization, variables, and responseData.
Business test: use one week's records to verify the total, check whether the scope and exceptions are clearly stated, and confirm that the record count matches the statistical count.
- In the request preview, view the rendered complete address, and verify that the placeholder variables in the three places—path parameters, request body, and request headers—can be parsed into actual values.
- In the variables panel, verify the source of each placeholder, confirm whether it comes from a global variable, a system variable, or the output of a preceding node, and compare the response of one sample request.