Workflow actions: Reading and modifying data

Actions are the tasks your workflow performs after a trigger fires. Use actions to create, update, or delete database rows, retrieve and analyze data, send HTTP requests to external services, route workflow logic conditionally, and notify users via email.

Baserow workflow automation image

What are workflow actions?

Actions are the core working units of your automation, taking the data payload from the trigger and using it to perform tasks across your database or external platforms.

After a trigger initiates your workflow, actions execute sequentially to accomplish your automation goals. Whether you need to add customer data to your database, send welcome emails, update order statuses, or sync information with external services, actions handle these tasks automatically.

How actions use trigger data

Every action can access data from previous nodes in the workflow:

  • Trigger payloads: Row data from created/updated/deleted records
  • Previous action results: Data retrieved by “Get single row” or “List multiple rows”
  • HTTP responses: Data returned from external API calls
  • Dynamic values: Formulas and calculations based on workflow data

This data flow allows you to build sophisticated automations where each action builds on the results of previous steps.

Concept Description Example
Sequential execution Actions run in order from top to bottom Create row → Send email → Update status
Data mapping Connect trigger/action data to action fields Use trigger’s “customer_email” field in “Send email” action
Sample data Test data generated for workflow building Test creates a row, then use that row’s ID in update action
Dependencies Actions require previous nodes to be tested first Can’t configure “Update row” until “Create row” is tested

Baserow data actions

These actions interact directly with your Baserow tables, providing complete control over your data.

All Baserow data actions require these basic settings:

  • Label: Descriptive name for the action
  • Integration: Connection to your Baserow database
  • Database: Which database contains the table
  • Table: The specific table to interact with

Create a row

This action automatically adds a new row to a specified table when certain events occur. You can define the values that should be included in the new row based on your workflow needs.

Configuration:

  1. Select your integration, database, and table
  2. Map fields: For each field in your table:
    • Enter static values (like “New” for a status field)
    • Use trigger data (like the customer name from a form submission)
    • Combine multiple values (like first name + last name)
  3. Test the action to generate a sample row

Common use cases include adding new customers from website form submissions, creating tasks when a project’s status changes, logging activity when external events occur, or duplicating existing rows with modifications.

Update a row

This action allows you to modify existing records in your table based on changing conditions or new information. It updates specific field values in a row without altering any other fields.

Configuration:

  1. Select your integration, database, and table
  2. Row ID: Specify which row to update:
    • Use the row ID from your trigger (for row update triggers)
    • Reference a row ID from a previous “Get single row” action
    • Use a specific row ID number
  3. Map fields: Define which fields to update and their new values
  4. Test the action to verify the update

Common use cases include updating an order status when payment is received, marking tasks as complete when all subtasks are finished, incrementing counters when events occur, and syncing changes from external systems.

Only mapped fields are updated. All other fields retain their current values.

Delete a row

This action removes records from your table that are no longer needed or meet specific deletion criteria. It permanently deletes the selected row, and this action cannot be undone.

Configuration:

  1. Select your integration, database, and table
  2. Row ID: Specify which row to delete using:
    • Trigger data (for row deleted triggers to log deletions)
    • A previous action’s row ID
    • A specific row ID number
  3. Test the action (use test data, not production data)

Common use cases include automatically removing expired records, cleaning up temporary data after processing, deleting spam or invalid submissions, and archiving data by copying it elsewhere before deletion.

Deleted rows are permanently removed. Consider copying important data to an archive table first.

Get single row

This action retrieves the details of a specific record so that its data can be used in subsequent workflow steps. It fetches all information for one row, allowing you to reference it in later actions.

Configuration:

  1. Select your integration, database, and table
  2. View: (Optional) Apply a view’s filters and sorting
  3. Row ID: (Optional) Specify a specific row
    • Leave empty to get the first matching row after refinements
  4. Refinements: Apply additional filters:
    • Filter by field values
    • Search for specific text
    • Sort results

How row selection works:

  • If you specify a Row ID → Returns that exact row (if it exists)
  • If Row ID is empty → Returns the first row matching your refinements
  • If no refinements → Returns the first row in the table/view

Common use cases include looking up customer details before sending personalized emails, checking current inventory levels before creating orders, retrieving configuration settings for the workflow, and finding related records that need to be updated.

Example scenario: When an order is created, get the customer’s row to access their shipping preferences and loyalty status.

List multiple rows

This action retrieves multiple records from your table, allowing you to process, analyze, or display them in batch operations. It fetches data for several rows based on specified criteria and returns them as a collection that can be iterated through in your workflow.

Configuration:

  1. Select your integration, database, and table
  2. View: (Optional) Apply a view’s filters and sorting
  3. Refinements: Configure criteria:
    • Add filters to narrow results
    • Apply sorting to control order
    • Use search to find specific text
  4. Default result count: How many rows to fetch
    • Set to a specific number (e.g., 10, 50, 100)
    • Set to 0 for on-demand loading (better performance)

Setting default result count to 0 and using pagination in Application Builder can significantly improve page load times.

Common use cases include finding all overdue tasks to send reminder emails, getting recent orders for daily summary reports, listing active customers for batch updates, and retrieving filtered data for synchronization with external systems.

Example scenario: Every morning, list all orders with status “Pending” from the last 24 hours to send to your fulfillment team.

Summarize field

This action calculates aggregate statistics across multiple rows without retrieving each individual record. It performs mathematical operations on a specified field and returns a single calculated value.

Configuration:

  1. Select your integration, database, and table
  2. Field: Choose which field to summarize
  3. Aggregation type: Select the calculation:
    • SUM: Total of all values
    • AVERAGE: Mean of all values
    • COUNT: Number of rows
    • MIN: Smallest value
    • MAX: Largest value
  4. Refinements: Apply filters to calculate only on specific rows

Common use cases include calculating total revenue for the current month, counting how many tasks are still open, finding the average rating across all reviews, and identifying the highest priority value currently in the queue.

Example scenario: At the end of each day, summarize the “Amount” field with SUM aggregation and filters for “Today’s date” to calculate daily revenue.

Workflow control actions

Router (conditional branching)

The Router action enables conditional branching within your workflow, allowing you to execute different actions based on data values. It functions like “if-this-then-that” logic, splitting your workflow into multiple paths so that each set of actions runs only when its conditions are met.

How Router works:

  1. Create branches: Add multiple conditional paths (e.g., “High Priority,” “Medium Priority,” “Low Priority”)
  2. Set conditions: Each branch requires a boolean condition that evaluates to true or false
  3. Execution order: Branches are checked left to right
  4. First match wins: The workflow follows the first branch where the condition is true
  5. Default fallback: If no conditions are met, the “Default branch” executes

Configuration:

  • Branch conditions: Must use formulas or comparisons that return true/false
  • Branch labels: Give each path a descriptive name
  • Default branch: Optionally label this fallback path

You cannot delete a Router node until all actions in its branches have been removed first.

Common use cases include routing high-value orders to a manager for approval, sending different email templates based on customer type, applying different validation rules depending on the data source, and escalating tasks according to their age or priority.

Baserow router node image

External integration actions

Send an HTTP request

This action allows your workflow to connect to any external API or web service, enabling broad integration possibilities. It sends data via HTTP requests, letting you trigger actions in other platforms or retrieve information from external systems.

Configuration:

Setting Description Example
HTTP method Request type required by the API POST (create data), GET (retrieve data), PUT (update data), DELETE (remove data)
Endpoint URL The API’s destination address https://api.example.com/v1/customers
Query parameters Data passed in the URL ?customer_id=123&action=notify
Headers Metadata sent with the request Authorization: Token YOUR_TOKEN
Body type Format of the data payload JSON (most common), Form data, Raw text
Body content The actual data being sent Customer details, order information, etc.
Timeout Max wait time for response 30 seconds (default)

Common use cases include sending new customer data to your CRM, notifying Slack channels when important events occur, automatically creating Trello cards or Jira issues, syncing order data with fulfillment services, updating external inventory management systems, and triggering workflows in platforms like Zapier or Make.

Example: Sending data to Slack

Method: POST
URL: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
Body Type: JSON
Body:
{
  "text": "New customer registered: {{previous node > customer_name}}",
  "channel": "#sales"
}

Learn more about Baserow database tokens.

Send an email

This action allows your workflow to automatically notify users, teams, or customers when specific events occur. It sends emails using your configured SMTP settings, enabling immediate communication from your automation.

Configuration:

Recipients:

  • From email: The sender address (must be configured in your SMTP settings)
  • From name: Display name for the sender (e.g., “Baserow Notifications”)
  • To emails: Primary recipients (comma-separated for multiple)
  • CC emails: (Optional) Carbon copy recipients
  • BCC emails: (Optional) Blind carbon copy recipients

Content:

  • Subject: Email subject line (can include dynamic data)
  • Body: Email content (can include trigger/action data)
  • Body type: Plain text or HTML for styled emails

Using dynamic data:

You can insert trigger and action data anywhere in your email:

  • Subject: New order #{{previous node > order_id}} received
  • Body: Hello {{previous node > customer_name}}, thank you for your order...

Common use cases include welcoming new users after registration, sending order confirmation emails, notifying team members when tasks are assigned, alerting managers about high-priority items, sending daily or weekly summary reports, and reminding users about upcoming deadlines.

HTML email example:

<h2>Welcome to Baserow, {{previous node > customer_name}}!</h2>
<p>Your account has been created successfully.</p>
<ul>
  <li>Email: {{previous node > email}}</li>
  <li>Account ID: {{previous node > row_id}}</li>
</ul>
<p><a href="https://baserow.io/dashboard">Get Started</a></p>

SMTP configuration required: Email actions require SMTP settings to be configured in your Baserow instance. Check with your administrator if emails aren’t sending.

Testing and debugging actions

To test an action,

  1. Ensure all previous nodes (trigger and any prior actions) have been tested
  2. Click the action node to open its configuration
  3. Configure all required settings and field mappings
  4. Click Test this event in the sidebar
  5. Review the results to verify correct execution
  6. Check the generated sample data for use in subsequent actions

Why previous nodes must be tested first: Actions often reference data from earlier steps. Without test data from previous nodes, you can’t properly configure field mappings.

After testing an action, review several key indicators to ensure it worked correctly. Look for success indicators, examine any sample data generated by the action, and verify that all field values were mapped correctly.

Also, check for error messages which indicate configuration issues that need to be addressed.

Frequently asked questions

How many actions can I add to a workflow?

You can add multiple actions to a single workflow. They execute sequentially in the order they appear. There’s no strict limit, but consider workflow performance for very long sequences.

Can I reuse data from multiple previous actions?

Yes. Any tested node’s data is available to all subsequent actions. For example, you can use row data from both a “Get single row” action and a “Create a row” action in a later “Send email” action.

What happens if an action fails?

The workflow stops at the failed action and doesn’t execute subsequent steps. The failure is logged in the History tab with error details. Fix the configuration and test again.

Can I update multiple rows at once?

The “Update a row” action updates one row at a time. To update multiple rows, use a “List multiple rows” action with a Router to iterate through results, or create separate workflows for batch operations.

How do I delete a Router node?

First, delete all actions in every branch coming out of the Router. Once all downstream actions are removed, you can delete or replace the Router node itself.

Can I use formulas in action configurations?

Yes. Most text fields support formulas and dynamic data references. Use double curly braces to reference node data: {{previous node > field_name}} or {{previous node > field_name}}.

What’s the difference between “Get single row” and “List multiple rows”?

“Get single row” returns one record as an object with its field values. “List multiple rows” returns multiple records as an array/collection that you might need to iterate through.

Do HTTP requests timeout?

Yes. Configure the timeout setting to control how long the workflow waits for a response. If the external service doesn’t respond within the timeout period, the action fails.

Can I send emails to multiple recipients?

Yes. Enter multiple email addresses separated by commas in the “To emails,” “CC emails,” or “BCC emails” fields. You can also use dynamic values from your trigger or previous actions.

How do I know which HTTP method to use?

Check the external API’s documentation. Generally:

  • GET: Retrieve data
  • POST: Create new records
  • PUT/PATCH: Update existing records
  • DELETE: Remove records

Troubleshooting common issues

“Previous node must be tested first” error

Cause: You’re trying to configure an action that depends on data from an untested previous node.

Solution: Work through your workflow sequentially from trigger to end, testing each node before configuring the next one.

Update or delete action can’t find the row

Cause: The Row ID you’re referencing doesn’t exist or is incorrect.

Solution: Verify the Row ID source. Print the ID value to check it’s valid. Ensure you’re using the correct field from your trigger or previous action.

HTTP request returns authentication errors

Cause: Missing or incorrect API credentials.

Solution: Check the external API’s authentication requirements. Add necessary headers (like Authorization or X-API-Key) with valid credentials.

Email action doesn’t send

Cause: SMTP settings aren’t configured or are incorrect.

Solution: Verify SMTP configuration in your Baserow instance. Check “From email” matches your SMTP settings. Contact your administrator if needed.

Router condition always takes default branch

Cause: The condition formula isn’t returning a boolean value or has syntax errors.

Solution: Test your condition formula separately. Ensure it returns exactly true or false. Check for typos in field names.

Related content

Still need help? If you’re looking for something else, please feel free to make recommendations or ask us questions; we’re ready to assist you.