Configure each form output action

Choose destinations, map answers, configure follow-up and approval, and check the results of all ten QMS form output action types.

An output action describes work to perform after a matching form submission. Choose the action for the result you need, configure its destination and answer mappings, then check the saved result with a controlled response.

Open and configure an action

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select an action type and review Sort Order and Active.

Open Data Collection → Output Rules, select the form, expand its rule and choose Add Action. The create location is /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new. Use an existing action's edit icon to open /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/{actionId}. You need QMS Manage forms.

Choose an action type, set its Sort Order and review Active. Order starts at 0; lower values execute first within the rule. New actions start active. Keep a new example inactive while preparing its settings; activate it when ready for a controlled submission. Its parent rule must also be active and match the submitted answers before the action can run.

Changing type changes the settings needed for that action. Review the destination, mappings and order again after selecting a different type.

Use Create or Update to save configuration, or Cancel to leave without saving. Reopen the form's rule list and inspect the saved action. See rule configuration.

A field mapping uses the form's saved field code, such as owner_user_id; an identifier setting uses the actual target object's identifier. For text templates, wrap the field code in braces: Inspection follow-up: {equipment_name} inserts that answer. The shared text-template substitutions include {submission_id}, {date}, {timestamp}, {year}, {month} and {day}. Date substitutions describe the time the action runs; use a form date field when the event date must come from the response. Test the resulting text with populated answers before routine use.

Generate Record

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Generate Record and inspect its Configuration panel.

Use this type when a completed form should produce a quality record. Prepare a record template with the structure and review workflow the resulting record needs.

1. Choose the intended record template. Check its standard, contents and workflow before using it as an automatic destination.

2. Enter a meaningful name pattern. Include an identifying answer or the submission identifier so reviewers can distinguish repeated submissions.

3. Set the folder and inclusion choices. When the form's Record must be signed setting is selected, the record is signed after it is created, through its own approval steps. For a record filed in a document vault, the action checks that the workflow of the record's document type includes a transition that asks for a signature; if it does not, the action fails and names what is missing. Such a record is never approved automatically.

4. Save and reopen the action. Activate the completed rule and action, then submit a controlled response with representative answers and attachments.

5. Open the resulting record. Check its number, template, name, folder, answers and source-submission reference. Inspect the included files. Where the form requires the record to be signed, continue with the signing through the record's workflow.

When no explicit record template is selected, generation can use a record template linked to the form, or the standard's document vault where configured. Check the destination deliberately rather than leaving the outcome to an unfamiliar default. If the template list is empty, prepare the appropriate record template first.

Continue the resulting record's normal review and approval workflow. Generating a record records the response; it does not make a human approval decision.

Create CAPA

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Create CAPA and inspect its Configuration panel.

Use this type when a response should initiate corrective or preventive follow-up. A failed inspection might create a corrective action; a response identifying a potential future problem might create a preventive action.

For From Form Field, choose the question that supplies the type and make its stored values corrective, preventive or both. Use a fixed type when every matching response has the same purpose. Set a realistic target date for the follow-up; an offset of 0 means the submission date.

Automatic mapping uses each question's field code, not its label or standard type. For each CAPA property it uses the first of these codes that has an answer:

An owner answer that is a user identifier assigns that user; other text is recorded as the owner's name. A severity answer must be an active CAPA severity code or a severity identifier; a code that is not active fails the action. Record the incident date, root-cause category and containment action on the CAPA during its investigation.

Use answers that identify the intended severity and person in the configured quality system.

Save and reopen the action, then test a matching response. Inspect the created CAPA's number, title, type, description, owner, severity and target date. Compare mapped information with the response and retain the source-submission reference. Continue the CAPA lifecycle for investigation, actions, verification and closure.

Create Task

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Create Task and inspect its Configuration panel.

Use this type to assign follow-up work after a form is submitted. Make the title identify the work and use the description to explain the expected result.

Choose User for a named person, Role for work assigned by responsibility, or From Form Field when the response supplies the responsible user. For From Form Field, choose the question, such as owner_user_id, whose answer is the identifier of an active user; an empty or any other answer fails the action.

For example, Review inspection for {equipment_name} gives the assignee useful context. A description can include {inspection_result} and explain which evidence to review before completing the task. Use the actual codes in your form.

After saving and reopening the action, submit a controlled matching response. Open the resulting task and check its title, description, assignment, priority, due date and source response. If approval delays creation, the due-date basis remains the submission date; choose the offset with that review time in mind. Task creation assigns work; the assignee still needs to carry it through to completion.

Send Notification

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Send Notification and inspect its Configuration panel.

Use this type when a matching submission should notify selected recipients. Put the reason for the notification in the subject and the requested response in the body.

Use User for a specific recipient, Group or Role for a configured set of recipients, and From Form Field when the response identifies the recipients. Choose the question and check that its answer contains the intended users' identifiers.

For example, the subject Inspection result: {equipment_name} and a body referring to {inspection_result} can make the notification meaningful without copying every answer. Choose a priority appropriate to the required response and check the recipients' notification preferences.

Save and reopen the action. Use a controlled submission addressed to test recipients, then check the received subject, body and priority. Verify each intended recipient, including the members selected through a role or group. The action's result shows how many active users each recipient source resolved to; if no recipient resolves, the action fails. A saved action is configuration; notification delivery follows a matching submission.

Webhook

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Webhook and inspect its Configuration panel.

Use this type to deliver a form submission to an external HTTP endpoint. Agree the destination and payload handling with the receiving system's owner before activating the action.

With No Retries, the action makes one attempt. 1 retry permits up to two attempts, 3 retries up to four and 5 retries up to six. A successful response ends delivery attempts. The receiving system should use the submission identifier to handle repeated delivery safely, so a retry does not create a second business record.

The default JSON payload identifies the tenant, submission, submitting user and timestamp. Its formValues contains entries keyed by field code, each with the field name, type and submitted value. Agree which information the receiver will use, including its treatment of empty answers and structured values.

1. Prepare a test endpoint that accepts the selected method and JSON payload.

2. Set the Webhook URL, method and retry count, then save and reopen the action.

3. Activate the completed rule and action and send a controlled matching response.

4. Confirm the receiving service accepted the request and inspect the resulting external record. Compare its submission identifier and answers with the source response.

5. Exercise an unsuccessful response and the selected retry behavior in the test destination before routine use.

An HTTP success confirms the request was accepted by the endpoint; check the receiver's business result as well. A timeout can occur after the receiver accepted work, which is why repeated-delivery handling matters.

Link Evidence

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Link Evidence and inspect its Configuration panel.

Use this action when the submitted response is evidence that needs to be retained against a specific target. CAPA is the primary destination. Choose a standard requirement when the response itself demonstrates something the requirement asks for, rather than creating a document or process solely to hold that evidence.

Send the response to a CAPA

1. Add Link Evidence to the rule. Under Where to file the evidence, keep CAPA (primary) selected.

2. Under Target, choose A specific target, chosen here and select the CAPA, or choose Taken from a form field and select the field that supplies its identifier. A fixed target suits a form dedicated to one CAPA; a field suits a reusable follow-up form.

3. For a field mapping, select the field in Form field carrying the CAPA id; the list shows each field's name and code. Confirm that the submitted answer contains the intended CAPA identifier, rather than its title or number.

4. Choose the Evidence category that describes the evidence: Containment, Root cause analysis, Implementation, Verification or Effectiveness. Implementation is preselected.

5. Save the action and reopen it to confirm the destination and target settings. Keep it inactive while preparing the rule.

6. When the rule and action are ready, activate both and submit a controlled matching response. Open the target CAPA and inspect its evidence. Check the retained answers and reference back to the originating submission.

For example, a follow-up inspection form can retain the observed result as evidence for the CAPA that prompted the inspection. Continue the CAPA's normal investigation, verification and closure workflow; the existence of an evidence item does not complete those decisions.

Send the response to a standard requirement

1. Under Where to file the evidence, choose Standard requirement.

2. Under Target, select the Standard and then the Requirement, or choose Taken from a form field and select Form field carrying the requirement id. A field-supplied requirement must be an in-scope requirement of the form's own standard. Check the standard as well as the clause; the same clause number can occur in different standards.

3. Choose Link Type according to what the submitted response demonstrates.

4. Set Trigger Evidence Assessment when the new link should be assessed against the requirement.

5. Save and reopen the action. When its rule and settings are ready, activate the rule and action, then test a matching response. Open the requirement's evidence and confirm the source submission, standard, clause and link purpose. Review any requested assessment separately.

A submitted check can provide evidence of what was done or observed without needing a new policy document or process definition. Explain why it addresses the requirement and review the actual answers. Linking the response, requesting an assessment and accepting the evidence are distinct steps. An AI assessment is not human approval or an inspection outcome; follow requirement evidence review.

Confirm the saved evidence

Check the output result and the target's evidence record, including the source-submission reference. If the rule uses a field to choose its target, test responses for different targets so that evidence reaches the correct CAPA or requirement. Also test a non-matching response and an inactive action. A successful action save records configuration; the saved evidence is the result to verify.

Require Approval

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Require Approval and inspect its Configuration panel.

Use this action when named people must approve or reject a submitted response before the outputs that depend on it run. The approval belongs to that submission: each approver receives an inbox task, and the decision is recorded on the response.

Choose at least one source of approvers. Until you do, the editor shows Choose at least one approver: users, roles or a form field. and the action cannot be saved. You can combine sources: each user, whether selected here or named by the form field, and each selected role becomes one approver.

Place the approval before the outputs that depend on it, in the same rule, and keep Hold the later actions of this rule until the decision selected. For example, rule A can require approval before generating a supplier record, while rule B sends a receipt notification for the same submission. The record in rule A waits for the decision; the notification in rule B is sent straight away.

Use a role when the decision belongs to a function rather than a person, for example the holder of a Supplier quality role. Use a form field when the respondent chooses who reviews their request, such as the line manager of a change request. Check that the field offers only real, active users.

What the approver sees

Each approver receives a task named Approval required: followed by the form name. Opening the task shows Approval of a form submission: the Submitted form, who submitted it and when, the Rule, the due date, the approvers with their decisions, and Actions waiting for this decision.

The approver reviews the submitted response, enters a Comment where needed and, when a signature is required, selects I sign this decision electronically. They then choose Approve or Reject; both stay unavailable until a required comment and signature are supplied. Only the named approvers, or holders of a named role, can decide, and each approver decides once.

When All approvers must approve is selected, an approver who has approved sees You have decided; the approval waits for the other approvers. Once the approval closes, the panel shows Approved or Rejected, who decided and when with their comment, and the state of each waiting action, such as Done, Failed or Cancelled. The approver whose decision closes it also sees a summary of how many waiting actions ran, succeeded or failed and how many were cancelled. Each approver's task is completed when they decide; when the approval closes, the tasks of approvers who have not decided are dismissed.

What the respondent sees

After submission, the confirmation lists the approval as Awaiting approval and each held action as Waits for the approval decision. These are waiting states, not failures. The response is Under review while the decision is pending, then Approved or Rejected, with the reviewer, time and comment.

Check the outcome

Save and reopen the action, then test it with controlled responses:

1. Submit a response that matches two rules: one with the approval followed by a dependent output, and one without approval. Check that the second rule's output runs while the dependent output waits.

2. Open the approver's task and approve. Check that the waiting output runs once, the response shows Approved and the decision appears on the response.

3. Submit another response and reject it. Check the configured behaviour: with Cancel the waiting actions, the waiting output is cancelled; with Run the waiting actions anyway, it runs. The response shows Rejected in both cases. Running the actions does not turn a rejection into an approval.

4. If you use All approvers must approve, a comment or a signature, test those requirements with a second approver before routine use.

Create Risk

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Create Risk and inspect its Configuration panel.

Use this type to create an RMS risk from a QMS form. The target module must be available and the submitting user's RMS authority must satisfy Create risks. QMS Manage forms alone does not confer that permission.

These visible settings use the names recognized by the risk handler. The rest of the mapping follows the form's field codes:

The existing_controls text answer is retained on the submission but is not copied into the risk's linked controls. Use the RMS controls workflow to establish those links and their effectiveness. Check the created risk's methodology, status, owner, factors and source reference; a matching field name alone does not prove that the answer contains a valid identifier or score.

Create Treatment Plan

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Create Treatment Plan and inspect its Configuration panel.

Use this type to create an RMS treatment plan for an existing risk. It requires RMS Manage actions for the submitting user. Action order alone does not automatically put the identifier returned by an earlier Create Risk action into this form's risk field.

The editor saves the selected option mapping and omits the other mode's mapping. The handler also has default option field names, so avoid populating conflicting code and ID answers. An absent target risk or an absent treatment option causes the action to fail. An input containing a field label instead of its saved code does not retrieve that answer.

Read the action's result in the response's Output Rule Executions; it identifies the created plan and its risk. Open the risk's Treatment tab to check the plan and continue its lifecycle: approve, start, complete or cancel it. Test a response for a missing risk and a missing treatment option as well. Plan creation does not complete its treatment work or demonstrate reduced risk.

Link Risk Evidence

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Select Link Risk Evidence and inspect its Configuration panel.

Use this type to retain submitted answers as text evidence for an existing RMS risk, optionally against one of that risk's mitigating actions. For example, an inspection response can record the observed result of a mitigation. The submitting user needs RMS Edit risks.

1. Identify the target risk and, where relevant, the mitigating action whose result the form records.

2. Choose the risk here, or choose Taken from a form field and select the question, such as risk_id, whose answer supplies the risk identifier.

3. Set the evidence type and a meaningful title, such as Inspection evidence: {equipment_name}-{submission_id}.

4. Save and reopen the action. Activate it with its completed rule, then submit a controlled matching response.

5. Open the target risk's evidence and check the title, evidence type, answers and source-submission reference. If an action target was configured, check that association as well.

For a reusable form, test responses that select different risks and actions. Confirm the intended target in each case, including the fixed fallback where one is configured. Use a risk that is eligible to receive evidence and give the submitting user the required RMS authority.

This action creates a note containing the answers and their source reference. Use the referenced submission to review the complete response and any original attachments. Review the evidence's meaning separately from the act of filing it; adding a note does not complete a mitigation or establish that risk has been reduced.

Verify the outcome before routine use

Product location: /qms/output-rules/{documentTemplateId}/rules/{ruleId}/actions/new (fallback: /qms/output-rules). Inspect the saved action, then check its intended output against the source submission.

First reopen the saved rule and action to confirm their template, type, active state, order and settings. Then use a controlled matching submission and inspect the resulting object or delivery. Test a non-matching submission as well to check that the rule does not run outside its intended condition.

The form response is saved before its outputs run. A failed action does not undo that response and does not necessarily stop later actions. Repeated submission can create repeated downstream work. Inspect what already exists before submitting again or recreating an apparently missing item.

When investigating an output, record the source submission, resulting object identifiers and relevant execution result. Check the actual destination as well as the configuration: a generated record, completed approval, delivered message and saved evidence each have their own outcome to inspect.