Create a Workflow

Creating Workflows

Workflows automate tasks based on your database data. A workflow consists of a trigger (when to run), one or more queries (what to check), conditions (what to look for), and actions (what to do).

Anatomy of a Workflow

Every workflow has four parts:

1. 1Trigger -- a schedule, or a manual run.
2. 2Query -- a database question or raw SQL that fetches data.
3. 3Condition -- a rule that determines whether the action should fire (e.g., "if row count > 0" or "if total > $10,000").
4. 4Action -- what happens when the condition is met (send email, post to Slack, call a webhook, etc.).

Step 1: Create the Workflow

Navigate to Workflows in the sidebar and click New Workflow. Give it a name and optional description.

Step 2: Set the Trigger

Choose when the workflow runs. New workflows remain drafts until you explicitly publish them:

• Scheduled -- every N minutes, hourly, daily, or weekly
• Manual -- run only from the UI or API

Step 3: Define the Query

Add one or more query steps. Each step can be:

• A natural language question: "Are there any orders placed in the last hour that are still unprocessed?"
• A saved query from your library
• Raw SQL for maximum precision

Each query step produces a result set that is available to conditions and subsequent steps.

Step 4: Add Conditions

Enable Only when results are found on a query to stop the workflow when that query returns zero rows. More complex thresholds should be expressed in the query itself, for example with a WHERE or HAVING clause.

Step 5: Configure Actions

When conditions are met, one or more actions execute:

• Send email -- to specific addresses or dynamically from a query column
• Call webhook -- send an authenticated request to a public HTTPS endpoint

Testing

Test query runs only the selected database query. Test webhook and Run draft execute real delivery actions and can send messages or mutate an external system; the UI asks you to review the destination first.

When the draft is ready, click Publish. Scheduled runs use an immutable published version, so later edits stay in the draft until the next publish.

Example: Low Inventory Alert

1. 1Trigger: Every hour
2. 2Query: "Show me products where stock_quantity < reorder_level"
3. 3Condition: Row count > 0
4. 4Action: Send email to procurement@company.com with the product list