Open app

Choose the backing table

Pick the table whose rows become profiles, the column that identifies a row, and the column changes are detected by.

A connected database has hundreds of tables. The backing table tells Uptend which one holds the thing your workspace tracks — the signups, the accounts, the customers — and how each row becomes a profile.

It lives with the rest of the profile definition: open Settings → Profiles and find the Backing table section, between the profile's name and its properties.

Only workspace admins can change the backing table. The mapping decides what a sync reads; the first full sync starts within fifteen minutes of saving it, or right away with Sync now on the source's page. See Sync.

The schema

Uptend read your database's schema when you connected it: every table your role can SELECT from, with its columns, primary key, indexes, foreign keys and update triggers. Every table and column you can pick below comes from that list — nothing is typed free-form.

The section says when the schema was read and how many tables it holds. After your database changes, click Refresh schema here or on the source's page; to read through the whole thing, open View schema on the source's page under Settings → Data → Data sources.

If a refresh finds that a column your mapping or a computed property relied on has gone, the change is recorded in the workspace's event log with the missing names, so a broken mapping is visible before a stage page silently empties.

If the section says Read the database schema first, the read that runs on connect did not succeed — a timeout, usually. Click Read schema to try again.

More than one source

A workspace with an additional source shows a Source picker at the top of the section. The primary source is selected by default: its rows are what become profiles. An additional source can be mapped the same way, but its rows only enrich profiles that already exist, matched by email.

Choose the table

Pick the table whose rows should become profiles. One row becomes one profile.

Uptend prefills what it can guess:

FieldWhat it fillsGuessed from
Key columnThe profile's source key — what a re-sync matches on. Defaults to the primary key.the primary key
Cursor columnThe updated_at-style column changes are detected by. See below.updated_at, modified_at, …
Deleted-atOptional. Rows with a value here are marked as deleted in the source.deleted_at, archived_at, …

Every guess is just a prefill. Check each one against your schema before saving.

The built-in fields — display name, email, domain, signed up — are not chosen here. They are computed from the backing row in the Properties section below, with the same dialog every property uses, so the email of an account can be the email of its first user rather than a column the table happens to have.

Filter rows out

The Row filter keeps rows out of Uptend entirely: test accounts, internal staff, anything that should never be a profile. Add one or more conditions on the table's own columns and choose whether all or any must hold.

Use this filter for rows that should not exist in Uptend at all. Rows that exist but should be left out of one particular rule — a second account opened by an existing customer, say — are filtered in that rule's own conditions, not here. Both read the same way in the UI, and they do very different things.

Preview before saving

Preview runs the mapping against your database without storing anything. It shows the five most recent rows as they would appear — the key, plus the name and signed-up date when those built-in fields read a plain column off this table — and two verdicts.

The cursor verdict

Uptend picks up changes by asking your database for rows whose cursor column moved since the last check. How well that works depends on the column, so the mapping grades it:

VerdictWhat it meansCadence
TrustworthyA timestamp with time zone, indexed, and kept current by a database trigger.Changes every 15 minutes; a nightly full pass as backstop
UsableIndexed, but maintained by your application. A write that skips your ORM leaves a row invisible.Every 15 minutes; drift against the nightly pass is reported
UnindexedThe right column, but no index leads with it.Hourly, until the index exists
UntrustworthyThe wrong type (a date, say), or a column that never differs from the created-at column.Snapshot mode
Snapshot modeNo cursor column at all.New rows every 15 minutes; everything re-read nightly

When the column is unindexed, the preview includes a ready-to-run CREATE INDEX CONCURRENTLY recipe. It targets your primary and you run it yourself — Uptend never writes to your database. The index is encouraged, never required: without it, sync is slower, not blocked.

Changing the table, the key column or the cursor column resets the sync's position, so the next scheduled run is a full read of the new mapping rather than a continuation of the old one. Values computed from related tables — joins, first rows, lists — are refreshed on their own cadence, set on the source's page; see Sync.

The cost verdict

The preview also asks your database's planner to estimate the statement Uptend will run at sync time — without executing it — and grades the answer Light, Moderate or Heavy. A heavy verdict usually means a sequential scan over a large table; the warning names the table so you can add the index that turns it into a lookup.

Both verdicts are advice. A mapping with a heavy cost or an untrustworthy cursor still saves; the verdicts decide how often it runs, not whether it runs.

Save

Click Save mapping. The verdicts you saw in the preview are stored with the mapping, and the section header shows the mapped table and its cursor verdict from then on. Saving again replaces the mapping in place; if you point it at a different table, any built-in field whose expression no longer resolves there is cleared rather than left pointing at a column that is not there.

Once the backing table is set, the built-in rows in the Properties section below can be computed from it, and so can every property you declare.

On this page