What this category's data looks like
This category involves three core types of materials: onboarding training plans, course sign-in sheets, and job descriptions. Onboarding training plans usually contain fields such as training batch, course name, start and end dates, instructor, and venue; they are published by the training department quarterly or monthly, and their update cadence changes with course adjustments. Course sign-in sheets are generated by on-site or online sign-in systems and contain the trainee's name, employee ID, course name, sign-in date, and personal signature or electronic receipt. Job descriptions are jointly maintained by the hiring department and human resources and contain the job title, department, list of responsibilities, job requirements, and signatures from both parties. When these three types of materials enter the Q&A intake and missing-item follow-up function, they play different roles: the training plan serves as the reference baseline for intake questions, the sign-in sheet is used to determine whether a trainee has completed a course, and the job description is used to check the correspondence between the job and the training content. In terms of field characteristics, date formats, name spellings, course abbreviations versus full names, and the presence or absence of signatures often differ, so missing items must first be identified during intake and then followed up on.
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 intake records and the completed follow-up questions are parsed from the response by subsequent nodes, or handled by an external system according to the agreement to finish the process. 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. The variables come from global variables, system variables, or the output of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Onboarding training plan | Whether the training batch, course name, start and end dates, instructor, and venue fields are complete, and whether the date format is consistent | In the request preview, look at the fully rendered address and check whether the plan fields match the external interface agreement |
| Course sign-in sheet | Whether the trainee's name, employee ID, course name, sign-in date, and signature or electronic receipt are complete, and whether the name and date of the same record match across the two materials | Check the request header names and the sources of their values, and use a sample request to compare the returned sign-in fields |
| Job description | Whether the job title, department, list of responsibilities, job requirements, and signatures from both parties are present, and whether the version is in sync with the training plan | In the variables panel, check the source of each placeholder and confirm that the job fields can be traced to a specific origin |
| HTTP node configuration | 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 | In the request preview, look at the fully rendered address and check the value sources of Authorization and variables |
Three common errors
- Symptom: The same trainee's course name is written differently in the training plan and the sign-in sheet. Cause: The two materials are maintained by different departments, abbreviations and full names are not unified, and versions are not in sync.
- Symptom: The job description lacks signatures or receipts from both parties, and the training plan dates do not match the sign-in dates. Cause: Signatures were not fully collected during the material circulation step, and dates were not entered in a unified format.
- Symptom: The request returns 401 or the external system receives empty fields. Cause: The request header authentication information was not passed in according to the external system's requirements, or the request body fields are inconsistent with the interface agreement.
How to verify the setup
Preview the rendered request, check the status code and returned fields, then compare the result against a sample; at the same time, check whether the field names in responseData are consistent with the external interface agreement.
Business test: submit a question that lacks key information and see whether it follows up first before answering.
- In the variables panel, check the source of each placeholder and confirm that it can be traced to a global variable, system variable, or the output of a preceding node.
- Use a sample request to compare the response, check the request header names and the sources of their values, and confirm that the authentication information is passed in according to the external system's requirements.