Skip to content
Docsturbobase.io

Custom fields

Shipped

Source systems let you define custom fields: a custom column on an Oracle NetSuite record, a HubSpot property, a Salesforce __c field. Turbobase discovers these and promotes them into real, typed columns on your canonical data model, so a source-specific field becomes something you can query, filter, and join on directly, instead of digging it out of the raw payload.

How promotion works

Section titled “How promotion works”

A discovered custom field is promoted into a column named cf_<code>_<field>, where <code> is a short, fixed two-character code for the source — cf_ns_ for NetSuite, cf_sf_ for Salesforce, cf_st_ for Stripe, cf_hs_ for HubSpot, and so on. The prefix keeps two sources’ fields from colliding even when they share the same underlying field name, and tells you at a glance which source a column came from. Standard canonical columns never carry the cf_ prefix.

The mapping from a source field to its column is deterministic and stable: the same field always promotes to the same column name across migrations, even when a very long field id has to be truncated to fit Postgres’s identifier limit. If you hold two connections of the same source, each connection’s custom fields land in their own distinct columns so they never overwrite each other.

Read-only and computed fields

Section titled “Read-only and computed fields”

Some source fields are computed by the source and cannot be written back. A Salesforce formula field and a Salesforce auto-number field are the two you are most likely to promote: both become ordinary columns you can query, filter and join on, and neither accepts an edit — the source rejects the whole record when one is sent, so Turbobase leaves them out of every write. The field-selection drawer does not yet say which of the fields it offers are computed, so check the field in Salesforce Setup if you need a column you can write to.

A formula field has a second limit worth knowing about, because it is invisible until something looks wrong. Salesforce recalculates a formula without changing the record’s last-modified timestamp, and every sync after the first reads only the records whose timestamp has moved — so a formula column holds whatever the value was when the row was last read for some other reason. There is no schedule that refreshes it on its own. To bring one up to date, start a full re-scan of that source from /data/sync/history. A promoted formula column that lags behind what you see in Salesforce is expected, not a fault.

Managing customizations

Section titled “Managing customizations”

Administrators pick which discovered custom records, lists, and fields to surface from the Records page at /data/sync/records. Expand a row and each per-source line inside it opens a field-selection drawer listing the discovered fields for that source; the row’s own “+ Add fields” goes straight there when the row has one place to put a field, and asks which line you mean when it has several. Once promoted, a custom field reads and (where the record type is bidirectional) writes just like any other column.

Backfilling history

Section titled “Backfilling history”

A promoted column is not just populated going forward — Turbobase backfills the history for you, in two passes:

  1. Every row whose stored payload already carries the field is filled straight from that snapshot. No calls to your source, so it costs nothing against your API budget.
  2. Rows that predate the field existing in your source are re-fetched, paged, in the background and through the same per-source call gate that protects the rest of your sync. There is no cap on how many rows this covers.

The backfill starts on its own when you approve the customization and runs asynchronously — approving does not block on it. Progress shows inline on the record’s row under /data/sync/records.

Section titled “Related”