Skip to content

Workflow Action

The Workflow action hands the Flow's event to an external system through a Webhook, an HTTP Action, or an n8n workflow. It carries the event's context in the payload, so the automation can continue outside Qualytics with everything it needs.

Why Use a Workflow Action

Use a Workflow action when the reaction to a data quality event lives outside Qualytics. Common cases:

  • Continue the automation elsewhere: Hand a failed operation or a detected anomaly to a remediation playbook, a pipeline, or an orchestration tool such as n8n.
  • Feed internal systems: Post quality events to a status page, an inventory, or any service with an HTTP endpoint.
  • Fit the endpoint's contract: The HTTP Action picks the verb and the authentication scheme, so the call matches what the receiving system expects.

Writing the message

The Message field of the Webhook and HTTP actions supports the same dynamic tokens as every notification, but it is carried inside the JSON payload as plain text, so Markdown formatting is not supported. See Message for the tokens.

Testing the Endpoint

Both the Webhook and HTTP Action settings panels include a Test Workflow button. Clicking it sends a test notification to the URL you entered. If the URL is correct and reachable, a confirmation message saying "Notification successfully sent" appears, so you can verify the endpoint works before saving and publishing the Flow.

Workflow Actions End Their Branch

A workflow action is always the last step of its branch. No child action can be attached after it. Once the event has been handed to the external system, any follow-up automation happens there, outside Qualytics. To run several things from the same trigger, add each action as a sibling branch instead of chaining them. See How a Flow Works for how branches execute.

Payload Structure

This payload belongs to the n8n action: when the Flow runs, Qualytics posts it to the n8n webhook URL. A Webhook action sends the rendered message instead, and an HTTP Action the request its own settings define. The n8n payload carries the following fields:

{
  "event": "qualytics.flow.triggered",
  "flow": {
    "id": 123,
    "name": "My Flow"
  },
  "trigger": {
    "type": "Anomaly",
    "timestamp": "2026-03-19T12:00:00Z"
  },
  "datastore": {
    "id": 1,
    "name": "Production DB"
  },
  "context": {
    "anomalies": [
      {
        "id": 456,
        "type": "record",
        "description": "Value out of expected range",
        "container": "orders",
        "fields": ["total_amount"],
        "created_at": "2026-03-19T11:59:00Z"
      }
    ],
    "containers": [
      {
        "id": 10,
        "name": "orders"
      }
    ],
    "quality_checks": []
  },
  "operation": {
    "id": 789,
    "type": "scan",
    "result": "warning"
  },
  "target_link": "https://your-qualytics-instance.com/datastores/1"
}

Note

datastore, operation, and target_link are only sent when the trigger provides them. The three context lists are always present and arrive empty when the event carries nothing for them, which is always the case for quality_checks. The trigger.type value is the Flow's trigger type as the API names it: Anomaly, AnomalyStatusChange, Operation, PartitionScan, Schedule, or Manual.

See Also