Skip to main content

Tables

The Tables Activity in workflows lets you perform operations on tables dynamically. With this node, you can automate common table tasks such as adding, updating, deleting, or retrieving rows. This feature simplifies data management, eliminating manual intervention and enabling seamless integration between workflows and tables.

What is a Tables Activity ?

A Tables Activity is a workflow node that interacts with Boltic Tables. It lets you:

  • ➕ Add new rows
  • ✏️ Update existing rows
  • ❌ Delete rows
  • 📥 Fetch rows for processing

You can power these actions using:

  • Static values
  • Dynamic data from previous steps in the workflow

SQL Editor

The Tables Activity in Boltic Workflows now includes a powerful SQL editor. This feature allows you to run DML queries on your tables, generate SQL from natural language using AI, and benefit from smart query suggestions as you type.

Supported SQL Operations

The SQL editor is designed to support essential Data Manipulation Language (DML) queries. You can use:

  • SELECT – Retrieve data

  • INSERT – Add new data

  • UPDATE – Modify data

  • DELETE – Remove data

You can write multiple SQL statements in a single query by separating them with semicolons (;). Boltic Tables also supports advanced SQL operations, including:

  • Using multiple tables
  • JOIN operations to combine data across tables
  • Subqueries for nested logic and complex filtering

Writing SQL Queries

When referencing values in your query, wrap them in single quotes (') to ensure compatibility with SQL syntax.

SELECT * FROM orders WHERE status = 'shipped';
Static SQL

Using Dynamic Variables in Queries

Dynamic variables from earlier steps in your workflow can be injected into your SQL query using the syntax below:

  • For Text, Long Text, Date-Time, Link, Phone Number, Email, and Sparse Vector use this format:

    '{{step.result.field}}'

    Example

    SELECT * FROM customers WHERE email = '{{step1.result.user_email}}';
Dynamic SQL with single quotes
  • For JSON, Vector, and Half Vector use this format:

    '"{{step.result.field}}"'

    Note: This ensures that complex objects are properly formatted and escaped according to the PostgreSQL syntax.

    Example

    INSERT INTO logs (payload) VALUES ('"{{step2.result.json_data}}"') RETURNING *;
Dynamic SQL with double quotes
  • For Number, Currency, and Boolean use this format:

    {{step.result.field}}

    Example

    UPDATE products SET price = {{step3.result.new_price}} WHERE product_id = {{step3.result.product_id}};
Dynamic SQL with no quotes
  • For Dropdown use this format:

    ARRAY{{step.result.field}}

    Example

    INSERT INTO products (tags) VALUES (ARRAY{{step4.result.tags}}) RETURNING *;
Dynamic dropdown

Dynamically handle NULL Values

When working with dynamic inputs in workflows, you may need to insert values into a column only if they exist—and insert NULL if the value is missing or explicitly set to 'null'.

To handle this cleanly, you can use the NULLIF function combined with type casting.

NULLIF('{{dynamic_value}}', 'null')::data_type

Example: Inserting into a Vector Column

Let’s say you're inserting a dynamic vector field in your table. If the vector is provided, it should be stored; if it's missing or intentionally passed as 'null', the column should remain empty (NULL).

Refer to the table schema in the Tables activity to know about the PostgreSQL data type of your columns.

INSERT INTO "customer_insights" (customer_id, interaction_vector)
VALUES (
'{{step5.result.customer_id}}',
NULLIF('"{{step5.result.interaction_vector}}"', 'null')::vector
);
Dynamic SQL with null value in Vector

Result Limits

To ensure performance and prevent accidental large dataset queries, Boltic Tables applies a default row limit of 100. To retrieve all rows, add NOLIMIT at the end of your query:

SELECT * FROM orders WHERE region = 'APAC' NOLIMIT;

🤖 Generate SQL with AI

Skip the syntax struggles—just tell us what you want to see, and Tables’s AI will write the SQL for you.

The best part? AI already knows the schema of all the tables in your Boltic Tables account. That means you don’t need to remember column names or table structures—it’s all taken care of.

Generate SQL with AI

Quickly check your table schemas whenever you need, whether you’re writing new queries or refining existing ones.

Generate SQL with AI

Example: "Show me the latest 10 orders placed this month"

SELECT *
FROM "orders"
WHERE
DATE_TRUNC('month', created_at) = DATE_TRUNC('month', CURRENT_DATE)
ORDER BY
created_at DESC
LIMIT 10;

Let AI handle the boilerplate, while you focus on getting insights faster.

💡 Smart Suggestions as you type

The SQL editor gives real-time smart suggestions to supercharge your query writing experience! Here's how it helps:

  1. Table and Column Names: No more guessing or typos. The editor suggests table and column names as you type, ensuring accuracy and saving you time.

  2. SQL Functions: Get instant recommendations for SQL functions. Whether you're calculating sums, averages, or performing complex operations, the editor has got you covered.

  3. Reserved Keywords: Never worry about missing a keyword again. The editor highlights and suggests SQL reserved keywords, making your queries syntactically correct.

This helps you write correct queries faster and with confidence. For the best experience, we recommend using double quotes around table and field names to get the most accurate suggestions.

Smart Suggestions

GUI

The Tables Activity supports the following operations:

1. Create Record

  • Action: Add a new row to your table.
  • Static Data: Predefine the values for each column.
  • Dynamic Data: Use output from a previous workflow activity to populate values.
Add Record Example

2. Update Record

  • Action: Modify an existing row in your table.
  • Required Data: Provide a Record ID to identify the row to update.
  • Specify: Static or dynamic data for the columns you want to modify.
Update Record Example

3. Delete Record

  • Action: Remove a row from the table.
  • Required Data: Specify the Record ID of the row to delete.
Delete Record Example

4. List Records

  • Action: Retrieve rows from a table.
  • Options: Fetch all rows or apply filters to refine the results.
  • Use Case: This action can be used to provide data for subsequent workflow nodes.
List Records Example

How to Use a Tables Activity

  1. Add the Activity

    • Drag and drop a Tables Activity into your workflow.
    • Connect it to a previous node to provide dynamic inputs.
  2. Select an Action - Choose one of the supported actions:

    • Create Record
    • Update Record
    • Delete Record
    • List Records
  3. Configure the Action - Specify the table you want to interact with. Then provide the necessary details for the action:

    • Create Record: Define column values (static or dynamic).
    • Update Record: Provide the Record ID and columns to update.
    • Delete Record: Enter the Record ID.
    • List Records: Optionally apply filters to narrow down the results.
  4. Activate the Workflow - Save and publish the workflow to start automation.

Examples

  1. Automating Lead Creation

    • Trigger: Detects a new submission on a contact form.
    • Tables Activity (Create Record) Adds a new row to the “Leads” table with the contact’s details.
  2. Updating Order Status

    • Trigger: Detects a payment confirmation event.
    • Tables Activity (Update Record): Updates the “Orders” table to set the status of the corresponding order to “Shipped.”
  3. Deleting a Canceled Subscription

    • Trigger : Detects a cancellation event.
    • Tables Activity (Delete Record): Removes the customer’s record from the “Subscriptions” table.
  4. Retrieving Open Support Tickets

    • Tables Activity (List Records): Fetches all rows where the “Status” column equals “Open.”
    • Subsequent Nodes: Process the data to notify support agents.

Best Practices

  1. Use Dynamic Data - Leverage outputs from previous nodes to make actions dynamic and context-aware.

  2. Apply Filters for Efficiency - When listing rows, use filters to limit the results and improve performance. The activity lists upto 1000 rows.

Advanced Options

For more information on advanced settings, see the Advanced Options documentation.

With the Tables Activity, you can build powerful, data-driven workflows that interact seamlessly with your Boltic Tables, enabling automation for a wide range of use cases.

Troubleshooting Common Issues

Running into errors? Here are some common problems and how to fix them:

⚠️ Error TypeCauseSolution
Relation does not exist- The table name is misspelled.
- Incorrect use of quotes (e.g., using single quotes instead of double quotes).
- The table may not exist in your account.
- The table may not be shared with you.
- Use double quotes ("table_name") for table names.
- Check the spelling and capitalization — identifiers in PostgreSQL are case-sensitive when quoted.
- Use the table schema viewer in Tables activity to confirm table names.
Column does not exist- The column name is incorrect or misspelled.
- Wrong table alias or no alias used.
- Case mismatch due to quoted identifiers.
- Check column names using the schema viewer.
- Use double quotes for column names if they contain uppercase letters or special characters (e.g., "created_at").
- Verify any table aliases used in your query.
Syntax error near...- Missing commas, parentheses, or semicolons.
- Incorrect keyword usage or misplaced clauses (e.g., WHERE before FROM).
- Double-check SQL syntax.
- Use an online SQL validator or Boltic’s Text to SQL AI to fix the query.
Invalid input syntax for type...- Trying to filter or insert values that don't match the column's data type (e.g., using text in a numeric field or wrong date format).- Ensure values match the expected data type (e.g., wrap dates in single quotes like '2024-01-01').
- Use functions like CAST() or ::type to convert values explicitly.
Queries returning empty results- Filters are too restrictive.
- Date/time ranges or case-sensitive values may be incorrect.
- Use ILIKE for case-insensitive matches.
- When performing INSERT, UPDATE, or DELETE, use RETURNING * to check what rows were affected—this helps confirm your query is working as expected.