Update in Database · Watchflows Docs

At a glance

Takes: Any payload — its variables become the new values and the conditions
Emits: rowsAffected
Good for: Marking rows done, correcting a value, filling in a blank

Set it up

Set the columns to overwrite, then say which rows with the where-builder. This node never creates a row, and it never touches one your conditions don't match. Run a Find in Database with the same conditions first if you want to see what a change will hit.

The inspector for Update in Database: fields to set, then conditions.

Configure

Field	Default	What it does
Database	—	Which database to write to. The picker fills in the id.
Table	—	The table to change. It must already exist.
Fields	—	Each row is a column and the value to set it to.
Where	—	Conditions, each a column, an operator, and usually a value.
Match	All of the conditions	All (AND) or Any (OR).
No conditions — reach EVERY row	Off	The deliberate opt-in for a whole-table update.
Match capitalisation exactly	Off	Off means `equals`, `contains` and friends ignore case.

The where-builder offers the same eighteen operators as Find in Database, and values follow the same rule as Save to Database: a lone {{text}} keeps the upstream type, everything else is a literal.

Output

Every key is available downstream as {{key}}.

Key	Type	Value
`rowsAffected`	Number	How many rows the update changed. `0` is a normal answer — it means the conditions matched nothing

Example: mark a clipping done

Input supplies the row id. Update in Database sets done to 1 where id equals {{text}}. Log shows how many rows moved.

Three nodes: name a row, change it, see the count.

Paste this into the Flow Builder to get the same flow:

Take a row id from an Input trigger, set done to 1 on that row of the clips table in Clipboard History, and log how many rows changed.

Good to know

No conditions means the node refuses to run. A blank condition list would reach every row, so it stops rather than guessing. Turn on No conditions — reach EVERY row if that really is what you want.

This node is always badged destructive. Matching rows are overwritten in place and a database has no Trash — the old values are gone.

A field that doesn't resolve is skipped; a condition that doesn't resolve stops the run. A value that isn't there must not become a NULL written over data that is; a condition that isn't there would change which rows the update reaches. If nothing resolves the node fails rather than running a no-op.

id and created_at can't be overwritten. They are the managed pair every table carries, and an Update is refused on either.