Find the intended response, filter its history, review saved answers and verify automatic records, evidence and approval outcomes.
Review a saved form response to establish what was submitted, who submitted it and what happened afterward. The response, its review state and each automatic output have separate identities and outcomes.
Product location: /qms/submissions. Expand Data Collection and select Submissions.
Expand Data Collection and choose Submissions, or open /qms/submissions. Use Refresh to reload the register. Access requires the applicable QMS document-view permission.
The register shows the 100 most recent responses. When there are more, it says how many it is showing; use a form's View History to reach older responses.
Each row identifies the template name and code, linked standard, response status, submitter, submission time and field count. An action count indicates recorded output executions. Use these details together to distinguish similar responses, then select the intended row.
The central register covers responses across templates. Use a standard's recent submissions or a particular form's history when your task concerns a narrower scope.
Product location: /qms/{standardCode}/forms (fallback: /qms/standards). Choose Recent Submissions.
Open the intended standard's Forms page at /qms/{standardCode}/forms and choose Recent Submissions. Check the standard heading and the response identities before opening an item.
Use this view for recent activity belonging to that standard. To investigate one template over time, return to its card and open View History. To review responses across templates, use the central submissions register.
Changing the standard changes the context of the work. Confirm the new heading and response details before continuing a review or sharing a link.
Product location: /qms/{standardCode}/forms (fallback: /qms/standards). Open the form card menu and choose View History.
On the Forms page, open the intended card's three-dot menu and select View History. Confirm the form name at the top of the history.
Control | How to use it |
|---|---|
Status | Focus on Draft, Submitted, Under review, Approved, Rejected or Archived responses, or choose all statuses. |
From / To dates | Restrict the submission-date range. The end date includes that day's responses. |
Search by submitter | Enter a distinctive part of the submitter's name or email. |
Status badge close control | Remove the selected status while keeping the other filters. |
Clear All | Reset the status, dates and submitter search together. |
Response row or View Details | Open the selected response in Submissions. |
Combine filters to narrow a review, such as submitted responses from one person during a particular month. Check the displayed result count and rows. Clear the filters when returning to the full template history.
History is ordered by submission time, newest first. Use Drafts to continue an unfinished response; use the saved response detail to review a completed submission.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity.
The detail header identifies the form, response status, submitter and submission date. Submitted Values lists each question's name, code, type and saved answer.
Compare the stored answers with the activity being recorded. Check dates, identifiers, selected choices and explanatory notes. For a repeating group, Submitted Values lists each of the group's questions once per entry, in the order the entries were arranged, without an entry label: the first answer under a question belongs to the first entry, the second to the second, and so on. A field count helps identify the response's size; it does not replace reading its contents.
The calibration example shows a saved response with its demonstration equipment identifiers and results. Open the supporting record when you need context beyond the answer itself.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity.
Use this relative location to direct another user or an agent to a specific saved response:
/qms/submissions?submissionId={submissionId}
Replace {submissionId} with the actual response identifier. A template, source document or generated output has a different identity. Include the form name and relevant activity when sharing the full response location.
The recipient must have access to the response. Confirm the identity shown after opening the link. Use Back to Submissions to return to the register.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity.
The response status describes its progress through submission and review. Submitted identifies a saved response; Under review, Approved and Rejected identify subsequent review states where that workflow is used. Draft identifies unfinished work, and Archived distinguishes responses kept outside active work.
Read the reviewer, review date and review notes when they are present. Check what was reviewed and any requested follow-up before treating the response as accepted.
The form response's review status is separate from the state of a generated document, CAPA, task or evidence link. Inspect the corresponding record when that is the outcome you need to establish.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity.
Scroll to Output Rule Executions in the response detail. Read the rule name, action type, execution state, completion time and result for every relevant execution.
Execution state | What to check |
|---|---|
Pending | The action is awaiting execution. A Require Approval action stays pending until its decision is made. |
Blocked | The action is held by an approval earlier in its rule. It runs, or is cancelled, once the approval is decided. |
Executing | The action is in progress. Check again for its completed result. |
Completed | Read the result and verify the identified destination or artifact. |
Failed | Read the feedback and identify which action needs attention. The saved response has its own status. |
Skipped | The approval earlier in the rule was rejected and the rule cancels the waiting actions. |
Use the result's identifiers to distinguish outputs created by this response from older records with similar names. A recorded execution and a saved response are evidence of different steps; inspect each outcome relevant to your work.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity.
Open the destination identified by the action result. For a generated record or document, check its title, destination, populated answers and association with the intended standard or activity.
For a CAPA or task, check the owner, due date, description and link to the originating work. For an evidence action, check that the supporting response is attached to the intended CAPA, requirement or risk destination.
The output-action reference explains the configuration and result checks for the different actions. Ask the form owner to review the rule when its intended destination is unclear.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity. Approvers open the Approval required task for that submission from their tasks to decide.
When an output rule requests approval, each approver receives a task named Approval required: followed by the form name. Open it from your tasks. Its Approval of a form submission panel names the submitted form, the submitter, the rule and Actions waiting for this decision. Review the submitted response, then choose Approve or Reject with any required comment or signature. Reopen the response afterward to inspect the resulting action states.
While the decision is pending the response is Under review; afterwards it is Approved or Rejected, with the reviewer, time and comment. An approval that holds later actions pauses only the actions after it in its own rule. Other matching rules continue. If the rule is set to Run the waiting actions anyway, those actions run after a rejection; use the actual execution history to establish the outcomes.
Review the approval and output configuration when investigating why an action is waiting, was skipped or needs follow-up. Completing approval does not remove the need to inspect the resulting saved record or delivery.
Product location: /qms/submissions (fallback: /qms/submissions). Use the actual submission identifier and confirm the form and response identity.
For a failed list or detail request, read the feedback and retry after checking access and connectivity. Confirm the selected standard, template and response. For an empty history, review the active filters and date range before concluding that there are no matching responses.
If an automatic action fails, retain the submission link and report the rule name, action and feedback to the form owner. Check the destination before repeating work when the outcome is uncertain. Creating another submission for the same activity can duplicate outputs that already succeeded.
Use the applicable review or follow-up process when submitted information needs correction. Keep the original response identifiable so that reviewers can understand the relationship between the submission and subsequent work.
