What this category's data looks like
This page centers on the category of student status changes and graduation qualification audits. The materials come from three types of original records: leave-of-absence/resumption applications, major transfer applications, and graduation audit checklists. Leave-of-absence/resumption applications contain student ID, change type, effective date, and approval signature; major transfer applications contain original major, target major, application date, and department seal; graduation audit checklists contain course name, credit count, completion date, and reviewer receipt. Materials are updated by semester batch; change applications are submitted immediately as the process proceeds, and graduation checklists are synchronized in two rounds, preliminary review and final review. The field characteristic is that dates and signatures appear in pairs, and the same student ID appears repeatedly in the two types of materials. When the materials enter workflow orchestration, leave-of-absence/resumption applications and major transfer applications serve as the source basis for exception tracing, and the graduation audit checklist serves as the qualification determination baseline; together, the three support the generation of the exception list and review conclusions.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction status records. The "exception list and review conclusions" are completed by subsequent nodes continuing execution according to 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 |
|---|---|---|
| Leave-of-absence/resumption application | Student ID, change type, effective date, and approval signature must be complete, and dates and signatures must appear in pairs | Check the options and branch connections one by one in the node, view the node status in the run records, and reference variables and nodeId to locate the source material |
| Major transfer application | Original major, target major, application date, and department seal must be consistent; if the name and date for the same student ID do not match across the two materials, it is an exception | Trigger an interaction once, view the node status in the run records, reference the selection result variable in subsequent nodes, and run a trial execution once |
| Graduation audit checklist | Course name, credit count, completion date, and reviewer receipt must correspond; if the version is not synchronized or the signed receipt is missing, it is an exception | Reference this variable in subsequent nodes and run a trial execution once, and check the branch direction and interaction status records |
| Exception list and review conclusions | Exceptions are supported by original records and signed by the reviewer, then handed to the person in charge for handling | Create an exception record, see whether it can be traced back to the source material, and check the branch direction in the run records |
Three common errors
- Phenomenon: The name and date for the same student ID do not match between the leave-of-absence/resumption application and the graduation audit checklist. Cause: The two materials are entered separately, and cross-comparison using student ID as the primary key is not performed.
- Phenomenon: The target major in the major transfer application and the major name version in the graduation audit checklist are not synchronized. Cause: After the application is submitted, the checklist is not updated with the batch, and the old version is still referenced.
- Phenomenon: The review conclusion lacks a signature or receipt, and the exception list cannot be handed to the person in charge for handling. Cause: After the interaction is completed, the process stops, and subsequent nodes do not continue execution according to the branch.
How to verify the setup
Feature acceptance: Run trial executions for each option one by one, check the branch direction and interaction status in the run records, confirm that each option corresponds to one branch, that the selection result variable has been passed to subsequent nodes, and reference variables and nodeId for locating.
Business testing: Create an exception record, see whether it can be traced back to the source material, and check whether the fields, dates, and signatures of the leave-of-absence/resumption application, major transfer application, and graduation audit checklist are consistent.
- Check the options and branch connections one by one in the node, trigger an interaction once, and view the node status in the run records.
- Reference the selection result variable in subsequent nodes and run a trial execution once, confirming that the exception is supported by original records and signed by the reviewer before being handed to the person in charge for handling.