What this category's data looks like
Undergraduate program revision involves three types of materials: program plans, course syllabi, and credit structure tables. Sources are academic affairs system exports, departmental submissions, and meeting minutes attachments. The program plan provides the major direction and total credit framework, the course syllabus carries course objectives and assessment methods, and the credit structure table locks in the credits and semester distribution of each module. Materials are updated according to the academic-year revision rhythm, and fields include course name, course code, credits, class hours, semester offered, signature, and date. The name, credits, and semester of the same course in the program plan and course syllabus must be consistent, and the summary values in the credit structure table must align with the total credits in the program plan. When entering the exception tracing and manual review function, each of the three materials serves as an original record to support comparison and difference localization.
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 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 follow-up. The HTTP node does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Program plan | Course names, credits, total credits, and signature dates must be consistent with the course syllabus and credit structure table | Extract the course name and credit fields, compare records of the same course across the three materials, and check signatures and dates |
| Course syllabus | Course objectives, assessment methods, and credits/class hours must be consistent with the corresponding course in the program plan | Compare course codes, credits, and semesters offered one by one, and check version numbers and receipts |
| Credit structure table | The credit summary of each module must align with the total credits in the program plan, and dates and signatures must be complete | Check the module credit totals, version dates, and signature fields, and flag items with missing signatures or unsynchronized versions |
| HTTP request | The request URL and path parameters, request headers, request body, and variable sources must all be traceable | View the fully rendered URL in the request preview, check Authorization and variables, and compare the returned field responseData |
Three common errors
- Symptom: The name and credits of the same course do not match between the program plan and the course syllabus. Cause: The two materials were revised separately, without field-level comparison and version synchronization.
- Symptom: The summary values in the credit structure table are inconsistent with the total credits in the program plan. Cause: After module credits were adjusted, the other material was not written back, and versions were not synchronized.
- Symptom: The review conclusion lacks a signature or receipt. Cause: When the exception list was circulated, the original records and signature fields were not bound, and the manual review step was omitted.
How to verify the setup
This function's acceptance: preview the rendered request, check the status code and returned fields, then compare the result against one sample; confirm that Authorization, variables, and responseData can all be traced to their sources.
Business test: create one exception record and see whether it can be traced back to the source material.
- In the variables panel, check the source of each placeholder and confirm that the request header names and value sources meet the external system's requirements.
- Use one sample request to compare the returned fields and check whether the request body fields are consistent with the external interface agreement.