Skip to main content

Tables

Tables are workspace-owned data sets that store structured records. A table can act as reference data, an operational register, or a workflow-controlled record store.

Use tables when the data needs to outlive one execution, be reused by more than one process, or be controlled with table-specific permissions.

Mental model​

A table has four main parts:

  • Table: The named data set, such as Approved Vendors, Sites, Equipment, or Change Requests.
  • Column: A typed field that defines what every row can store.
  • Row: One record in the table. Each row has a serial number, created/updated timestamps, revision history, and values for the active columns.
  • Grant: Access that allows users, teams, or processes to see or change the table.

Treat a table as a business object, not a spreadsheet tab. A strong table has one clear purpose, stable column meanings, and an owner who is responsible for keeping the data useful.

When to use a table​

Use a table for:

  • reference data that many processes need, such as locations, vendors, products, equipment, departments, or policy options
  • records that need to be updated after the process that created them finishes
  • data that should be selected from a controlled list instead of typed repeatedly
  • workflow output that should become structured business data
  • records that need auditability through row revision history
  • data where permissions need to be narrower than general process access

A form is enough when the data only matters inside one execution. For example, a one-time explanation, a single uploaded file, or an approval comment usually belongs on the execution record, not in a table.

Common table patterns​

Approved vendor table:

  • Columns: Vendor Name, Status, Category, Contact Email, Last Review Date
  • Used by: Purchase request forms and vendor review workflows
  • Good design choice: Make Vendor Name unique so people cannot create duplicate vendor records.

Equipment inventory table:

  • Columns: Asset Tag, Equipment Type, Site, Assigned User, In Service, Next Inspection Date
  • Used by: Inspection workflows, maintenance requests, and asset transfers
  • Good design choice: Store Asset Tag as text, not number, because asset tags often contain leading zeroes or letters.

Change request register:

  • Columns: Request Title, Risk Level, Owner, Due Date, Status, Approved
  • Used by: A process that adds a row when a request is submitted, then updates the row as review steps finish
  • Good design choice: Use a Table Record node to keep the register current without asking people to update it manually.

Table details​

Every table has:

  • Name: The user-facing table name.
  • Description: Context for what the table stores and who should use it.
  • Status: active or archived. Active tables can be used by new process versions. Archived tables cannot be selected for new process references.
  • Row count and column count: Current usage against workspace or plan limits.
  • Schema revision: Internal version of the table structure, updated when columns change.
  • Process grants: The processes allowed to select, create, update, or delete rows.
  • Permissions: The users and teams allowed to view or manage the table.

Archive a table when it should no longer be used in new process versions. Delete is only available for archived tables and permanently removes the table and its row data.

Schema design​

The schema is the set of active columns on a table. Column design controls validation, display, lookup behavior, process mappings, and row history readability.

For each column, configure:

  • Label: The field name people see.
  • Type: The kind of value the column stores.
  • Required: Whether rows must provide a value.
  • Indexed / queryable: Intended for fields that need direct table browsing filters or sorting. A column only appears in those direct row-list filter and sort surfaces when its index state is ready.
  • Unique values only: Prevents duplicate non-empty values in that column.
  • Type-specific settings: Text kind, max length, number range, or select options.

Columns also have a stable generated name based on the label. CSV imports use the column name, not the label, as the header. Use the CSV template when importing so the headers match exactly.

You can reorder active columns, archive columns, and restore archived columns. Archiving removes the column from the active schema without destroying its historical meaning. Restoring a column counts against the active column limit.

Column types​

Text​

Text stores string values. Use it for names, identifiers, emails, phone numbers, URLs, codes, and notes that should not be treated as numbers.

Options:

  • Text Type: Text, E-Mail, Rich Text, Telephone, or URL.
  • Max Length: Optional character limit for non-rich text values.
  • Required: Requires a non-empty value.
  • Unique values only: Supported for bounded non-rich text. Text columns must define a max length at or below the workspace indexed-text limit before they can be unique.

Use text for values that may contain leading zeroes, punctuation, letters, or formatting, even when they look numeric. Examples: asset tags, account numbers, postal codes, lot numbers, and invoice numbers.

Rich Text uses the editor for row entry. It cannot be indexed, unique, or max-length constrained.

Number​

Number stores numeric values for comparison and math-like filtering.

Options:

  • Min Value: Lowest allowed number.
  • Max Value: Highest allowed number.
  • Required: Requires a value.
  • Unique values only: Supported.

Use number for quantities, scores, measurements, thresholds, and amounts when numeric comparison matters. Do not use number for IDs that need leading zeroes or symbols.

Checkbox​

Checkbox stores true, false, or blank when the column is not required.

Options:

  • Required: Removes the blank state.
  • Unique values only: Technically supported, but rarely useful because there are only two non-empty values.

Use checkbox for simple flags like Active, Approved, Reviewed, In Service, or Requires Follow-up.

Select​

Select stores one value from a fixed option list.

Options:

  • Options: One option per line.
  • Custom option values: Use Label|value when the stored value should differ from the label.
  • Required: Requires one selected option.
  • Unique values only: Supported, but only useful when each option should appear on at most one row.

Use Select when the value list is controlled and may be longer than a radio group should display.

Radio Select​

Radio Select stores one value from a fixed option list, like Select, but is intended for shorter choice sets.

Options:

  • Options: One option per line.
  • Custom option values: Use Label|value.
  • Required: Requires one selected option.
  • Unique values only: Supported, but rarely useful.

Use Radio Select for short categorical values such as Low / Medium / High, Open / Closed, or Pass / Fail.

User​

User stores a workspace user reference.

Options:

  • Required: Requires a user.
  • Unique values only: Supported.

Use User for owners, reviewers, assignees, requestors, and accountable people. In row display and history, user values can show readable user details instead of only an ID.

Team​

Team stores a workspace team reference.

Options:

  • Required: Requires a team.
  • Unique values only: Supported.

Use Team for responsible groups, support queues, departments, or escalation ownership.

Date​

Date stores a calendar date without a time of day.

Options:

  • Required: Requires a date.
  • Unique values only: Supported.

Use Date for effective dates, expiration dates, review dates, inspection dates, and due dates where the time does not matter.

Date & Time​

Date & Time stores a timestamp.

Options:

  • Required: Requires a timestamp.
  • Unique values only: Supported.

Use Date & Time for scheduled events, exact handoffs, incident timestamps, and records where the time matters.

Rows​

Rows are the records inside a table. Users with editor or owner access can add, edit, and delete rows manually. Processes with the right grant can also create, update, or delete rows through Table Record nodes.

Every row has:

  • Serial ID: A table-scoped row number used for display and deterministic lookup.
  • Created and Updated timestamps.
  • Revision number.
  • Values for active columns.

Required columns, number limits, select options, relation values, and unique columns are enforced when rows are saved. Blank values are stored as empty values rather than fake placeholders.

CSV imports​

CSV import creates rows in bulk.

Import rules:

  • Download the template first so headers match active column names exactly.
  • The first row must be the header row.
  • Unknown headers are rejected.
  • Duplicate headers are rejected.
  • Required columns must be present in the file.
  • Blank data rows are ignored.
  • Quoted values are supported, including commas and line breaks inside quoted cells.
  • Imports are client-side and limited to 5,000 rows per file.
  • The import cannot exceed the table's row limit.

CSV values are coerced before upload:

  • Number values may include commas, such as 1,250, and are converted to numbers.
  • Checkbox values accept true, false, 1, 0, yes, no, y, and n.
  • Date values must parse as valid dates.
  • Date & Time values must parse as valid datetimes.
  • Other values are imported as trimmed text.

For large or sensitive imports, test with a few rows first. Imports create real row history and can be blocked by uniqueness or validation rules.

Row history​

Row history shows how a row changed over time. Owners can view history when a row has more than one revision.

History entries show:

  • operation: create, update, or delete
  • revision number
  • timestamp
  • actor: user, workflow execution, or system
  • changed values for updates
  • row snapshots where available

Use history when the table is part of a controlled process and you need to answer who changed what, when, and through which workflow.

Permissions​

Table permissions control human access through users and teams.

Roles:

  • Owner: Full control over schema, rows, sharing, process grants, archive, delete, and history.
  • Editor: Can view rows and create, edit, and delete row data.
  • Viewer: Can view table rows only.

Editors and viewers can be scoped to selected columns. Column scope controls which columns are visible and editable for that user or team. Owners always see and manage the full table.

Workspace policies still matter. Users need the relevant workspace policies, such as view, create, update, or delete tables, before table features are available in the app.

Process grants​

Process grants control which processes can use a table. A process grant is separate from human permissions.

Grant capabilities:

  • Allow select rows: Lets table-backed Select fields load table rows as form options.
  • Allow create rows: Lets Table Record Add create rows.
  • Allow update rows: Lets Table Record Update change rows.
  • Allow delete rows: Lets Table Record Delete remove rows.
  • Restrict process columns: Limits the process to selected columns.

New process versions validate table grants before they can use tables. If a process references a table without a sufficient grant, publication fails with a table access error.

Using tables in forms​

The Select form element can use a table as its data source when table selection is available for that form builder.

Table-backed Select settings:

  • Source Table: Active table granted to the process.
  • Display Fields: Columns used to build the option label.
  • Search Fields: Columns searched when a person types. Search uses OR logic.
  • Caption Fields: Optional secondary text shown below the label.
  • Allow multiple selections: Stores all selected table options when enabled.

Supported display/search/caption column types are text, select, radio select, user, and team. Number, checkbox, date, and datetime columns can still exist on the table, but they are not used to render table-backed select option labels.

The field loads the first 10 rows by default and can load more through search. Table-backed Select fields store the selected row id and a snapshot of configured table values for workflow variables.

For update and delete workflows, use a single-select table-backed Select field. The Table Record node uses that selected row as the row reference. Multi-select table fields cannot be used as a single row reference.

Using tables in workflows​

The Table Record node reads or changes table rows.

Actions:

  • Get: Looks up rows in a granted table. Filters use AND logic. When multiple rows match, the node returns the first row after sorting. It can fail the node when no row matches, or continue without a match.
  • Add: Creates one row in a granted table from static values or workflow variables.
  • Update: Updates one row selected by an upstream single-select table-backed Select field.
  • Delete: Deletes one row selected by an upstream single-select table-backed Select field.

Column mapping for Add and Update:

  • Skip leaves a column untouched for updates or blank for creates.
  • Static writes a fixed value.
  • Variable writes a value from workflow context.
  • Plain text / text columns can combine literal text and workflow variables in a template.
  • User and team mappings store the referenced user or team id, even when the variable contains richer display data.

Get filters support static values or variables. Text fields support equality, inequality, contains, starts with, ends with, empty, and not empty. Number, date, and datetime fields support equality, inequality, greater than, greater than or equal, less than, less than or equal, empty, and not empty. Select, radio select, user, and team fields support equality, inequality, empty, and not empty. Checkbox fields support equals and does not equal.

Limits and operational notes​

Table limits are workspace or plan settings. The app shows row and column counts against the current limits, and warns when a table is near or at a limit.

Important limits and states:

  • Active row count is limited by the workspace's table settings.
  • Active column count is limited by the workspace's table settings.
  • CSV import is limited to 5,000 rows per file.
  • Manual Select options in forms are limited to 100 options. Use a table-backed Select when the list is shared, long-lived, or too large for manual options.
  • Archived tables cannot be referenced by new process versions.
  • Archived columns are not part of the active schema, but may still appear in historical snapshots.
  • Queryable column behavior depends on index eligibility and index state. Rich text cannot be indexed, and text columns need a bounded max length for unique constraints.

Pro practices​

  • Model one entity per table. Do not mix vendors, sites, and change requests in one table.
  • Use required columns only when every valid row truly needs the value.
  • Make natural identifiers unique, such as Vendor ID, Asset Tag, or Site Code.
  • Use text for business identifiers, even when they look numeric.
  • Use select or radio select for controlled statuses. Avoid free-text status fields.
  • Keep display fields short for table-backed Select fields. Long option labels make forms harder to scan.
  • Add caption fields only when they help distinguish similar rows.
  • Scope process grants to the minimum capabilities and columns the process needs.
  • Prefer Table Record Add/Update over asking users to maintain process-generated records manually.
  • Archive old columns instead of changing their meaning. Reusing a column for a different concept makes history misleading.
  • Test Table Record Get filters with realistic data before publishing a workflow that depends on one exact match.