Skip to content

Actions Examples

Real scenarios showing complete Flows, with the actions chained the way they would sit on the canvas. Pick a tab for a scenario; together they cover the five categories. For trigger-focused scenarios, see Flow Examples.

Refreshing, validating, and publishing a warehouse every night

Context. An e-commerce team lands operational data in an orders_warehouse datastore that analysts query every morning, and its BI tool reads quality metadata from the enrichment destination. They build one Flow with a Schedule trigger (0 2 * * *) and chain the whole pipeline behind it: a Sync, a Profile, and a Scan, then two branches after the Scan, an Export of anomalies and quality checks, and a Slack notification to #data-quality.

flowchart TD
    F["Flow: Nightly orders pipeline"] --> T["Trigger: Schedule"]
    T --> S["Operation: Sync"]
    S --> P["Operation: Profile"]
    P --> C["Operation: Scan"]
    C --> E["Operation: Export"]
    C --> N["Notification: Slack"]

Flow Node

Node Configuration
Nightly orders pipeline Name Nightly orders pipeline, description Refreshes and validates the orders warehouse before 6:00 AM.

Trigger Node

Node Configuration
Schedule Timezone UTC, custom cron 0 2 * * *, so the Flow starts at 2:00 AM every day.

Action Nodes

Node Configuration
Sync (Operation) Source Datastore orders_warehouse, including tables and views.
Profile (Operation) Source Datastore orders_warehouse, all tables.
Scan (Operation) Source Datastore orders_warehouse, all tables, incremental read strategy.
Export (Operation) Source Datastore orders_warehouse, exporting anomalies and quality checks to the enrichment destination.
Slack Slack (Notification) Channel data-quality.

What happens. At 2:00 AM the schedule activates. The Sync refreshes the inventory; when it succeeds, the Profile updates the metadata, then the Scan asserts the checks. Once the Scan succeeds, the two branches run independently: the Export publishes the fresh results to the enrichment destination while Slack tells the team how the night went. If the Sync fails, everything downstream lands as Skipped.

Why it works. One trigger carries the whole pipeline in dependency order, so a broken refresh never gets measured or published, and the sibling branches after the Scan let reporting and alerting happen side by side without one waiting for the other.

Escalating a failed operation to every channel that matters

Context. A data platform team needs failures on the payments datastore to reach on-call, the team channel, and an internal status service at the same time. They create a Flow with an Operation Completed trigger filtered to that datastore and Operation Status = Failure, and chain three terminal branches directly to the trigger: a PagerDuty notification with Severity Error, a Slack notification to #data-alerts, and an HTTP Action that posts the event to the internal status page.

flowchart TD
    F["Flow: Payments failure escalation"] --> T["Trigger: Operation Completed, Failure"]
    T --> PD["Notification: PagerDuty"]
    T --> SL["Notification: Slack"]
    T --> HTTP["Workflow: HTTP Action"]

Flow Node

Node Configuration
Payments failure escalation Name Payments failure escalation, description Escalates failed operations on the payments datastore.

Trigger Node

Node Configuration
Operation Completed Source Datastores payments, Operation Types Scan, Operation Status Failure.

Action Nodes

Node Configuration
PagerDuty PagerDuty (Notification) Severity Error, message with {{datastore_name}} and {{operation_message}}.
Slack Slack (Notification) Channel data-alerts.
HTTP Action HTTP Action (Workflow) Action URL of the internal status service, Http Verb POST, Auth Type Bearer with its secret.

What happens. A scan on payments fails during a credential change. The completion matches the filters, the Flow runs, and the three branches deliver in parallel: PagerDuty opens an incident, Slack posts the failure with its context, and the status service receives the JSON payload through the authenticated HTTP call.

Why it works. Notifications and workflow actions end their branches, so each destination hangs directly from the trigger as a sibling. One failing channel does not block the others, and the Failure filter keeps every message actionable.

Turning severe anomalies into tickets the team hears about

Context. A retailer triages data quality issues in Jira. They create a Flow with an Anomaly Detected trigger on the product_catalog datastore and a minimum Anomaly Severity (Min), then chain a Create Ticket action on the Jira integration, followed by a Slack notification whose message carries {{ticket_number}} and {{ticket_url}}. A sibling In App notification alerts the users working in Qualytics.

flowchart TD
    F["Flow: Product anomalies to Jira"] --> T["Trigger: Anomaly Detected"]
    T --> CT["Ticketing: Create Ticket"]
    CT --> SL["Notification: Slack with ticket link"]
    T --> IA["Notification: In App"]

Flow Node

Node Configuration
Product anomalies to Jira Name Product anomalies to Jira, description Opens a Jira ticket for every severe anomaly in the product catalog.

Trigger Node

Node Configuration
Anomaly Detected Source Datastores product_catalog, Anomaly Severity (Min) set to the team's threshold.

Action Nodes

Node Configuration
Create Ticket (Ticketing) Jira integration, with the ticket's short description, priority, and assignment group.
Slack Slack (Notification) Channel merchandising, message carrying {{ticket_number}} and {{ticket_url}}.
In App In App In App (Notification) Message with {{anomaly_message}}; delivered to admins and the datastore's team members.

What happens. A scan catches a batch import writing null prices. For each anomaly at or above the threshold, the Flow opens a Jira ticket with the anomaly's context, then the Slack message lands in the merchandising channel already carrying the ticket's number and link, while the In App branch notifies the platform's users.

Why it works. The Ticketing category is available because the trigger is Anomaly Detected, and chaining the notification after Create Ticket makes the ticket tokens available, so the channel message carries the ticket itself alongside the anomaly. The severity filter keeps the board free of low-priority tickets.

Archiving stale anomalies and reporting the result

Context. A team's active anomaly queue buries new findings under ones nobody has touched in months. They create a Flow named "Monthly anomaly cleanup" with a Schedule trigger on the first day of each month, an Archive action with an Inactivity Period of 90 days and the tag auto-archived, and an Email notification chained after it, with a message using {{anomaly_count}} and {{inactivity_timeframe}}.

flowchart TD
    F["Flow: Monthly anomaly cleanup"] --> T["Trigger: Schedule, monthly"]
    T --> AR["Anomaly: Archive inactive"]
    AR --> EM["Notification: Email with anomaly count"]

Flow Node

Node Configuration
Monthly anomaly cleanup Name Monthly anomaly cleanup, description Archives anomalies untouched for a quarter.

Trigger Node

Node Configuration
Schedule Timezone UTC, monthly schedule on day 1.

Action Nodes

Node Configuration
Archive (Anomaly) Inactivity Period 90 days, an archive reason under Options, and the tag auto-archived assigned to every archived anomaly.
Email Email (Notification) Recipients of the team, message with {{anomaly_count}} and {{inactivity_timeframe}}.

What happens. Once a month, the Archive action collects the anomalies untouched for 90 days and archives them with the reason and tag. When it succeeds, the Email reports how many anomalies the run removed and over which inactivity window, so the team audits the cleanup from the inbox.

Why it works. The inactivity window protects anything under active triage, the tag makes every automated archive traceable, and the chained notification only sends when the archive actually succeeded, because a downstream action needs its parent to succeed.

See Also

  • Best Practices

    Guidelines per category for actions that do their work quietly and fail loudly.

    Best Practices

  • How It Works

    The action node, the five categories in detail, how actions run, and the chaining rules and limits.

    How It Works

  • Operation

    Run datastore operations (Sync, Profile, Scan, Export, Materialize) when the trigger activates.

    Operation

  • Anomaly

    Archive or delete inactive anomalies automatically.

    Anomaly

  • Notifications

    The dispatch pipeline and the five channels: In App, Email, Slack, Microsoft Teams, and PagerDuty.

    Notifications

  • Message

    The message you write, its formatting, and the dynamic tokens available per trigger type.

    Message

  • Workflow

    Hand the event to an external system through a Webhook, an HTTP action, or n8n.

    Workflow

  • Ticketing

    Create or update tickets in your issue tracker from anomaly events.

    Ticketing