Table

Use the Table block to read and write structured data in Sim. Data persists across runs and is scoped to the workspace. Operations insert, update, upsert, query, or delete rows, with filters, sorting, and batch writes.

Create tables

Tables are created from the Tables section in the sidebar. Each table requires:

• Name: An ASCII letter or underscore followed by letters, digits, or underscores (e.g., customer_leads)
• Description: Optional description of the table's purpose
• Schema: Define columns with name, type, and optional constraints

Column types

See Table column types for the supported types and their storage behavior.

Column constraints

• Required: Column must have a value (cannot be null)
• Unique: Values must be unique across all rows (enables upsert matching)

Use the block

Create and manage custom data tables. Store, query, and update structured data within workflows. Query Rows accepts a plain predicate — {"field":"wins","op":"gte","value":10} — for one condition. Use all (AND) or any (OR) groups for multiple or nested conditions. Operators: eq, ne, gt, gte, lt, lte, in, nin, like, ilike, nlike, nilike, contains, ncontains, startsWith, endsWith, isNull, isNotNull, isEmpty, isNotEmpty. Order is a sort spec [{"field":"wins","direction":"desc"}]. Query Rows returns every matching row when Limit is omitted (fails if the result exceeds the fixed 5 MiB row-data budget — add a filter or a Limit). With a Limit, responses page: a non-null nextCursor means more rows exist — pass it back as the cursor. Columns to Return narrows each row to the selected columns (by stable id or name; one that no longer exists is skipped); leave it empty for every column.

Actions

Insert Row

Insert a new row into a table. IMPORTANT: You must use the "data" parameter (not "values", "row", "fields", or other variations) to specify the row contents.

Batch Insert Rows

Insert multiple rows into a table at once (up to 1000 rows)

Upsert Row

Insert or update a row based on unique column constraints. If a row with matching unique field exists, update it; otherwise insert a new row. IMPORTANT: You must use the "data" parameter (not "values", "row", "fields", or other variations) to specify the row contents.

Update Row

Update an existing row in a table. Supports partial updates - only include the fields you want to change. IMPORTANT: You must use the "data" parameter (not "values", "row", "fields", or other variations) to specify the fields to update.

Update Rows by Filter

Update multiple rows that match filter criteria. Data is merged with existing row data.

Delete Row

Delete a row from a table

Delete Rows by Filter

Delete multiple rows that match filter criteria. Use with caution - supports optional limit for safety.

Query Rows

Query rows with a typed predicate filter and cursor pagination. A single filter can be a plain condition: \{"field":"wins","op":"gte","value":10\}. Use all (AND) or any (OR) groups for multiple or nested conditions. Operators: eq, ne, gt, gte, lt, lte, in, nin, like, ilike, nlike, nilike, contains, ncontains, startsWith, endsWith, isNull, isNotNull, isEmpty, isNotEmpty. Order is a sort spec, e.g. [\{"field":"wins","direction":"desc"\}]. Omit limit to return the entire result — the query fails if it exceeds the fixed 5 MiB row-data budget (narrow with a filter or set a limit). With a limit, a page can end early at the byte budget: a non-null nextCursor means more rows exist — pass it back as cursor to continue; never infer completion from page size.

Get Row

Get a single row by ID

Get Schema

Get the schema configuration of a table

Filter operators

A filter is a predicate. One condition is an object naming a column, an operator, and a value:

{"field": "status", "op": "eq", "value": "active"}

Most columns are scalar (string, number, boolean, date) or opaque JSON; use ilike with *value* for substring matching on text.

Select columns accept only a subset of these operators, and a query using any other operator on one is rejected rather than returning no rows:

A multi-select cell holds a list of options, so match it with contains (by option name) rather than ilike.

Combine filters

Wrap conditions in all for AND:

{
  "all": [
    {"field": "status", "op": "eq", "value": "active"},
    {"field": "age", "op": "gte", "value": 18}
  ]
}

Use any for OR:

{
  "any": [
    {"field": "status", "op": "eq", "value": "active"},
    {"field": "status", "op": "eq", "value": "pending"}
  ]
}

Groups nest, so mixed logic is a group inside a group:

{
  "all": [
    {"field": "status", "op": "eq", "value": "active"},
    {"any": [
      {"field": "plan", "op": "eq", "value": "pro"},
      {"field": "score", "op": "gte", "value": 90}
    ]}
  ]
}

Omit the filter entirely to match every row.

Sort specification

Order is a list of column/direction pairs, applied in order:

[{"field": "createdAt", "direction": "desc"}]

Multi-column sorting:

[
  {"field": "priority", "direction": "desc"},
  {"field": "name", "direction": "asc"}
]

Pagination

Omit Limit to return every matching row in one response; queries exceeding the fixed 5 MiB row-data budget fail. Narrow with a filter, select fewer columns, or set a limit.

With a Limit, results page. A page can end at the limit or early at the row-data budget (5 MiB by default; self-hosted operators can configure TABLE_MAX_PAGE_BYTES), so a short page does not mean the end. Pass the returned nextCursor back as Cursor to fetch the next page and stop only when nextCursor is null — never infer completion from the row count.

Built-in columns

Every row automatically includes:

These can be used in filters and sorting.

Limits

Workspace access

• Tables are scoped to workspaces and accessible from any workflow within that workspace
• Data persists across workflow executions
• Use unique constraints to enable upsert functionality
• Use the visual filter and sort builders to construct queries without writing JSON