Update Table Row Step

The Update table row step writes data to a knowledge-base table. It is available in both automation types. Tables installed by applications are read-only and cannot be used by this step.

Select A Table, Sheet, And Structure

Open the step on the workflow. Select an active project table in Table, then select its sheet.

In Table structure, keep First row is the header or select Configure and highlight the header rows. Optionally limit the data area. It must be on the same sheet, below the header, and within its columns.

The editor remembers column headers in both conditions and written values. If a column is moved while its unique header remains unchanged, the setting follows it. If the header is renamed or the same title appears more than once, an error asks you to select the column again. Also review every selected field after changing the table, sheet, or ranges.

Select An Action

The What to do field offers three modes:

• Update found rows — find rows by conditions and update them; the step fails when none match;
• Append a new row — skip search and add a separate row after the current data on every run, even for the same lead;
• Update or append — use exact conditions to update matching rows and add a new one when none match.

Use Update or append when one current record should be kept for a defined key, such as a lead's current status. Use Append a new row for request history or repeat submissions. Update or append accepts Equals conditions only; when it creates a row, condition values are also written to their columns.

Define The Record Key

An automation does not assume that every lead must always have one row. First decide what the table represents:

• for one current lead record, lead_id can be the key;
• for separate requests from the same lead, use request_id or a combination of lead_id and a request identifier;
• for an event log, do not look for an old row; append a new one for every event.

A name, phone number, or physical row number is not a reliable key when it can change or repeat. A row number is the record's current position, not its identity.

Configure Search And Multiple Matches

For update modes, add from 1 to 20 conditions in the Where to search block. In each condition, select a column, Equals or Contains, and a value source: an entered value, current date or time, lead data, or a Run, Lead, Dialog, or Project variable. Every condition must match.

When several rows may match, select one behavior in If multiple rows are found:

• update all matching rows, which is the default;
• update only the first row from top to bottom;
• require exactly one row and fail when several rows match.

For a unique key, select Require exactly one. In Update or append mode, zero matches creates a row, while multiple matches causes an error without writing. This exposes duplicate data instead of hiding it by choosing the “first” row.

One execution can update no more than 1,000 rows.

Enter Values To Write

In What to write, add up to 100 columns. For each one, select a column and a value from the same sources available to search conditions. A column cannot be listed more than once in one step; the editor shows an error until the duplicate is removed.

The current date and time are calculated during execution. System lead data is available only in For dialogs automations. A selected variable must have a value when the step runs.

Test With Safe Data

A test run changes the actual table. Use a row that can be restored or deleted. For an integration test through the API or MCP, you can create a separate empty table and fill it with the typed JSON append-rows method; no CSV/XLSX upload is required.

First confirm in the run history that the step completed, then verify the key and written values. Background refresh of the readable table snapshot can take several tens of seconds. If the data is not visible immediately, repeat the check with a bounded wait until the table version changes. Search and table-structure rules are also covered in Find table row.