younifyd
Menu

Connectors

Data Table Connector

Create your own typed data tables and perform insert/get/find/update/upsert/delete/bulk-upsert operations on them from a workflow — platform-managed storage scoped to your store.

On this page

What this connector is for

Reads and writes your own data tables — platform-managed persistent storage scoped to your store, like a lightweight per-workflow database. No connection is needed: like the Variable and Cache connectors, this is platform-internal state, keyed off your store automatically.

A table (created outside this connector, in the designer's Data Tables UI) has a fixed schema: an ordered list of typed fields, and one or more of those fields designated as the (possibly composite) primary key. Field types are string, integer, float, boolean, array, json (object), enum (with a fixed enumValues list), object (a single nested object with its own field list), or objectArray (an array of such objects) — only string/integer/float/boolean/enum are eligible as primary-key components. Types are enforced strictly: writing a number to a string field (or vice versa) fails validation rather than silently coercing. A field marked isSearchable gets a live secondary index and can be filtered on by Find Records (capped at 5 searchable fields per table); any other field can't be filtered at all.

Every action's output is a plain result nested under the standard envelope — access via {{<stepReference>.response.data.<field>}} — none of these actions ever halt the workflow with an HTTP-style error response the way Schema Validator/Mapper do; a lookup miss or a bad primary key surfaces as a thrown error (visible in execution logs) instead. Every action's Table field selects the target table by its id from a live dropdown of your store's tables. Primary-key fields are ordinary fields on the record too — they're never stripped out of a returned data object, so there's no separate pk field in any action's output.

Insert Record

Creates a new record. Fails (with a conflict error) if a record already exists at the primary key derived from your data.

Configuring it

  • Table — required.
  • Record Data — required. A JSON object with the record's fields, including every required field and the primary key field(s) (Insert validates in "complete" mode — a required field with no default and no value fails).

Reading the response

  • {{<stepReference>.response.data.data}} — the inserted record's fields (including its primary key fields).
  • {{<stepReference>.response.data.createdAt}} / {{<stepReference>.response.data.updatedAt}}.

Example

Table: customers
Record Data: {"email": "ada@example.com", "name": "Ada Lovelace"}

Get Record

Fetches a single record by its exact primary key — a raw point lookup, fast regardless of table size.

Configuring it

  • Table — required.
  • Primary Key — required. A JSON object with the primary key field(s), e.g. {"email": "ada@example.com"} for a table keyed on email.

Reading the response

  • {{<stepReference>.response.data.data}} — the record's fields, or null if no record exists at that key (there's no separate "found" flag — a null data is the "not found" signal).
  • {{<stepReference>.response.data.createdAt}} / {{<stepReference>.response.data.updatedAt}} — absent when data is null.

Example

Table: customers
Primary Key: {"email": "ada@example.com"}

Find Records

Lists/paginates a table's records, optionally filtered on searchable fields. Uses keyset (cursor) pagination — never offset/skip — so paging stays fast deep into a large table.

Configuring it

  • Table — required.
  • Filter — optional. A JSON object of { "<field>": { "operator": "...", "value": "..." } } entries, filtering only fields marked searchable on the table. operator is equals (any searchable type — coerced to the field's real type before comparing) or contains/startsWith/endsWith/like (string/enum fields only — case-insensitive; like additionally supports SQL-style wildcards, %/* for "any run of characters" and _/? for "exactly one"). Filtering on a non-searchable field, or using a string-only operator on a non-string/enum field, fails the step.
  • Cursor — optional. Pass the previous response's nextCursor to fetch the next page; omit for the first page.
  • Page Size — optional, default 20, max 100.

Reading the response

  • {{<stepReference>.response.data.items}} — array of {data, createdAt, updatedAt}, one per matching record.
  • {{<stepReference>.response.data.nextCursor}} — pass this back in as Cursor to get the next page; absent/empty once there are no more pages.

Example

Table: customers
Filter: {"status": {"operator": "equals", "value": "active"}}
Page Size: 20

Update Record

Partially updates fields on a record that must already exist, looked up by primary key. 404s (a thrown error) if no record exists there — use Upsert if it might not exist yet.

Configuring it

  • Table — required.
  • Primary Key — required. JSON object identifying the record.
  • Fields to Update — required. A JSON object with only the field(s) to change (a partial patch — fields you omit are left untouched; this action validates in "partial" mode, so no other required field is re-checked).

Reading the response

  • {{<stepReference>.response.data.data}} — the record's full fields, post-update.
  • {{<stepReference>.response.data.createdAt}} / {{<stepReference>.response.data.updatedAt}}.

Example

Table: orders
Primary Key: {"id": "order_123"}
Fields to Update: {"status": "shipped"}

Upsert Record

Creates the record if its primary key doesn't exist yet, or fully replaces its data if it does — atomic, single database operation, so no locking is needed even under concurrent calls. The primary key is derived from whichever primary-key fields are present in Record Data.

Configuring it

  • Table — required.
  • Record Data — required. A JSON object with the record's fields, including the primary key field(s) — those determine which record is targeted. Unlike Update, this replaces the record's data wholesale (validated in "complete" mode), not a partial patch.

Reading the response

  • {{<stepReference>.response.data.created}}true if this call created the record, false if it updated an existing one.
  • {{<stepReference>.response.data.data}} — the record's full fields.
  • {{<stepReference>.response.data.createdAt}} / {{<stepReference>.response.data.updatedAt}}.

Example

Table: orders
Record Data: {"id": "order_123", "status": "active"}

Delete Record

Removes a single record by primary key.

Configuring it

  • Table — required.
  • Primary Key — required.

Reading the response

  • {{<stepReference>.response.data.success}}true on success (a delete of a non-existent key throws a 404-style error rather than returning false).

Example

Table: customers
Primary Key: {"email": "ada@example.com"}

Bulk Upsert Records

Upserts many records in one call — a single chunked, unordered bulk write, so one bad row (e.g. failing type/required-field validation) is reported without blocking the rest of the batch. Prefer this over calling Upsert in a loop for an import/sync of more than a handful of records.

Configuring it

  • Table — required.
  • Records — required. A JSON array of record objects, each including its own primary key field(s) — each is upserted independently, matched on its own key.

Reading the response

  • {{<stepReference>.response.data.upserted}} — count of records actually created or updated.
  • {{<stepReference>.response.data.errors}} — array of {index, message} for records in the input array that failed validation and were skipped (index is the position in the Records array).

Example

Table: customers
Records: [{"email": "ada@example.com", "name": "Ada"}, {"email": "grace@example.com", "name": "Grace"}]

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

  • Must be at least 2 characters, and 50 characters or fewer.
  • Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
  • Can't be empty.

Tips

  • Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
  • Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

  • If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
  • Object values are automatically JSON-stringified when interpolated into a string field.

Execution Settings

Fire-and-forget

When enabled, the workflow doesn't wait for this step to complete before moving to the next one. Use it for steps whose result nothing downstream depends on — logging, analytics, notifications — so they don't add latency to the steps that matter.

Continue on error

When enabled, a failure in this step doesn't stop the workflow — execution continues to the next step. The failure is still recorded in the execution history; this just controls whether it's fatal.

Combine the two for steps that are genuinely optional to the outcome: fire-and-forget so they don't add latency, continue-on-error so a failure in them (e.g. an analytics endpoint being briefly down) doesn't take down an otherwise-successful workflow run.

Caching

What it does

When enabled, a step's result is cached for a configurable TTL (time-to-live, in seconds). If the step runs again with the same effective cache key before the TTL expires, the cached result is returned instead of re-running the step.

Configuring it

  • Enabled — turn caching on or off for this step.
  • TTL — how long (in seconds) a cached result stays valid.
  • Cache key template — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same call". By default this is based on the step's resolved input; a custom template lets you cache more narrowly or broadly than that.

When to use it

Good candidates are steps that call something slow or rate-limited but return the same answer for the same input within a short window — a lookup against a rarely-changing external system, for example. Skip it for steps whose result must always be fresh (anything involving live inventory, pricing, or payment state).

Locking

What it does

When enabled, only one execution of this step (for a given lock key) can run at a time. If a second execution tries to run the same step while a lock is held, it waits until the lock is released or the hold period elapses.

Configuring it

  • Enabled — turn locking on or off for this step.
  • Lock key — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same resource". By default the lock is scoped to the step itself; a custom key lets you lock per-customer, per-order, or any other identifier that needs serialized access.
  • Period — how long (in seconds) the lock is held before it's automatically released, in case an execution doesn't complete normally.

When to use it

Use it whenever concurrent executions could race on the same resource — e.g. two workflow runs both trying to update the same order's status at once. A lock key scoped to the order id ensures only one of them proceeds at a time.