Mankomail

Table — insert or update ​

Writes the row: created when its key is free, updated otherwise. This is the node for memory between runs.

Writes a row to a Table: it is created when its key is free, and updated otherwise. This is the node for memory between runs — "last reminder sent on", "case status" — because it works the same on the first run and on every later one. Use Table — insert a row when a duplicate must fail, and Table — update a row when a missing row must fail.

At a glance ​

  • Type: table.upsert · version 1
  • Category: Actions
  • Kind: Step — one stage of a run
  • Effect: Writes outside (external_write) — writes outside Mankomail; described instead of performed during a test run
  • Needs a carrier email: No
  • Connection: None
  • Inputs: main
  • Outputs: main

Parameters ​

table ​

Table — Picked from the list, or by its short identifier (its “slug”), which may come from a template.

  • Type: Remote resource (resourceLocator)
  • Required: Yes
  • Ways to choose: pick from a list, type an ID (table)

values ​

Row values, key included — One list, key included: the key is made of columns like any other, and two lists to keep in sync is one too many.

  • Type: List of items (collection)
  • Required: No
  • Default: []
  • At most 60 items
  • Each item has:
    • column — Column
      • Type: Text (string)
      • Required: Yes
      • Default: "" (empty)
      • 60 characters at most
      • Expressions: {{ }} not accepted
    • value — Value. Converted into the column type: “1,234.50” becomes a number, “yes” a boolean, “2026-04-03” a date. Anything it cannot read is refused, never blanked.
      • Type: Text (string)
      • Required: No
      • Default: "" (empty)
      • 10000 characters at most

Outputs ​

  • main

Data produced ​

What this node adds to the run data, and how to read it in an expression. <step> stands for the step key: the node name turned into an identifier (see Data and expressions).

  • {{ data.<step>.rowId }} — string. The identifier of the row written. In a test run, when the row would be created: simulated:<table identifier>.
  • {{ data.<step>.row.<column> }} — object. The whole row after the write, by column machine key. Empty cells are absent.
  • {{ data.<step>.created }} — boolean. true when the row was created, false when an existing row was updated.
  • {{ data.<step>.reused }} — boolean. true when the step was replayed after an incident and the row written by the first attempt was returned, without writing again.
  • {{ data.<step>.simulated }} — boolean. true in a test run: nothing was written.
  • {{ data.<step>.summary }} — string. A one-line summary: Row added., Row updated., Would have added a row., Would have updated the row. or Already written on an earlier attempt: nothing was rewritten.

Example ​

A workflow remembers, for each client, the date of their latest email. The table clients has the key column client_email. An earlier Compute a date step named "Today" gives the date. The node is named "Remember client".

text
table   clients
values  client_email   = {{ email.from.email }}
        last_email_on  = {{ data.today.date }}

On the client's first email the row is created (created: true); on the next ones it is updated (created: false), and {{ data.remember_client.row.last_email_on }} holds the latest date.

Tips ​

  • One list, key included. Row values, key included must contain a value for every column ticked Part of the matching key: the node finds the row from those values. A missing key part fails the step with table.invalid_value; a table with no key column fails with table.no_key.
  • Update keeps the other columns. When the row exists, only the columns listed change; the others keep their value.
  • Matching ignores case, accents and punctuation, and relies on the table option Refuse two rows with the same key. Keep it ticked on a table you write by key.
  • Values are converted to the column type; a value that cannot be converted, or a column that does not exist in the table, fails the step with table.invalid_value. Columns are named by their machine key, not their heading.
  • Replays are safe. The write is recorded with the step's idempotency key: a replay after an incident returns the row already written (reused: true) without writing again.
  • Test runs. Nothing is written, but the row is really looked up, so the result tells you whether the run would create or update it. The step returns the row as it would be, with simulated: true. See Test runs.