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 an Anomaly Impact filter of is at least High, 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 Impact is at least High.

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 impact 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.

Taking a weekly snapshot of who can access which datastore

Context. A compliance team reviews data access every week and keeps each review as evidence for its auditors. Instead of an Admin compiling the Access Report by hand every Monday, an Admin creates a Flow named "Weekly access review" with a Schedule trigger at 6:00 AM every Monday, a Global Export action of Access Report into the governance_exports enrichment datastore, and an Email notification chained after it to the compliance team.

flowchart TD
    F["Flow: Weekly access review"] --> T["Trigger: Schedule, Mondays 6:00 AM"]
    T --> GE["Operation: Global Export, Access Report"]
    GE --> EM["Notification: Email to compliance"]

Flow Node

Node Configuration
Weekly access review Name Weekly access review, description Snapshots every user's datastore access for the weekly review.

Trigger Node

Node Configuration
Schedule Timezone America/New_York, custom cron 0 6 * * 1, so the Flow starts at 6:00 AM every Monday.

Action Nodes

Node Configuration
Global Export (Operation) Asset Type Access Report, Enrichment Datastore governance_exports.
Email Email (Notification) Recipients of the compliance team, message with {{operation_result}} and {{target_link}}.

What happens. Every Monday at 6:00 AM the schedule activates the Flow. The Global Export writes a full snapshot of every active user's effective team permission on every datastore to _export_user_permissions in governance_exports, with every row stamped with the same GENERATED_AT. The action waits for the export to finish; once it succeeds, the Email tells the compliance team the snapshot is ready and links to the run. If the export fails, the action fails with it, the Email is skipped, and the execution shows the failure. A separate job in the team's warehouse copies each snapshot into an access_review_history table, because the next export replaces _export_user_permissions.

Why it works. The schedule removes the manual step, and because the Global Export action finishes with the export's real result, the notification only ever announces a snapshot that actually landed. Copying each snapshot out keeps a dated history, so the auditors can compare two weeks and see exactly who gained or lost access. Since the Flow exports the Access Report, only Admins can change, delete, or manually run it, which keeps the review process under the same control as the access it reports on.

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