Mapping Objects onto Datastores
A connection gives access. Mapping is what turns a remote table, Salesforce object, sheet or endpoint into something the platform can use like any other datastore.
Where to find it
Architect Panel → Integration & Connections:
- Data Sources — the console — map objects and their fields
- Data Source Sync History — each run, its row count and any error
- Data Source Writeback Queue — outbound changes awaiting delivery
What a mapped object holds
- Remote object and its namespace — the table, object or path.
- Local datastore — where it appears.
- Mode — read live, or sync into a local copy.
- Primary key — how a remote row is identified.
- Cursor field and type — what makes a sync incremental.
- Sync interval.
- Write enabled and delete mode.
- Field mappings — remote name and type to local name and type.
Include only the fields you need
Each field is included or excluded individually. Excluding what you will not use makes syncs faster, the local datastore comprehensible, and — where the remote system holds personal data you have no need for — reduces what you are responsible for holding.
That last point is worth taking seriously. Syncing a customer table in full because it was easier than choosing columns means you now hold, and must protect and dispose of, data you never needed.
The primary key must be right
It is how the platform decides whether an incoming row is new or an update to one it already has. Get it wrong and a sync either duplicates everything on each run or overwrites unrelated records.
Use the remote system's own stable identifier. A composite of "name plus postcode" will look correct until somebody corrects a spelling.
Incremental syncs need a cursor
A cursor field — typically a last-modified timestamp or an ascending ID — lets each run collect only what changed since the last one. The last position reached is remembered between runs.
Without a cursor, every run is a full reload. That is fine for a few hundred rows and unworkable for a few million, and it is the difference between a sync that finishes in seconds and one that does not finish inside its interval.
Check the remote field is genuinely updated on every change. A last-modified column that some updates bypass produces a sync that silently misses records — the hardest failure here to detect, because everything appears to work.
Writeback
Write is off unless you enable it, and there is a separate delete mode. Changes queue and are delivered by the writeback task.
Enable it only where the platform genuinely owns the data, and think hard about deletes. A delete propagated to a system of record is the least recoverable thing in this feature, and "we can restore it" is a conversation with somebody else's DBA.
Set the interval to the need
Match it to how quickly the data must be current, not to how quickly it could run. A five-minute sync of a table that changes twice a day is load with no benefit — and against a rate-limited API it is a quota problem waiting to happen.
Watch the sync history
Each run records its start, end, status, row count and any error. A run count that suddenly drops to zero usually means the cursor has advanced past a gap or a remote permission changed — worth a look before somebody reports missing data.
Worked example
A Salesforce account object is mapped to a local datastore with eleven of its forty fields, keyed on the Salesforce ID, cursored on last-modified date, syncing every 30 minutes and read-only. Reporting joins it to local case data without touching Salesforce. When the sales team later needs a status written back, writeback is enabled for that one field with deletes disabled.
Recommendations
- Map only the fields you need.
- Use the remote system's own identifier as the key.
- Always configure a cursor for anything beyond a few hundred rows.
- Leave writeback and deletes off until there is a specific reason.