Setting Up a Sync
A sync names the far instance, the table at each end, and how often to run.
Where to find it
Architect Panel → Integration & Connections:
- Table Sync — the syncs themselves
Architect Panel → Data:
- Datastores — the tables at both ends
Architect Panel → Security:
- Permissions — making the destination read-only
What it holds
- The address of the other instance and a key to reach it.
- The source table and the destination table.
- A frequency.
The two tables must match
Same fields, same names, same types. A sync copies values into fields — it is not a mapping layer, and a field missing at the destination is a value with nowhere to go.
The reliable way to achieve this is to build the destination from the source's definition rather than by hand. Two people creating "the same" datastore independently will differ in something.
Keep them in step afterwards
This is the ongoing discipline. Adding a field at the source and not at the destination breaks the sync, and the break happens at the next change to that table rather than at the moment you made the schema change — so the cause and the symptom are separated by hours.
Make "change both ends" part of how you edit a synced datastore.
Frequency
Match it to how quickly the copy must be current, not to how often it could run. Reference data changing a few times a week does not need a five-minute sync — that is load with no benefit.
Hourly suits most reference data. Reach for minutes only when somebody is genuinely waiting on the far side.
The first run
Understand what happens with existing data before you enable a sync onto a table that already has rows. Two populated tables with independent histories are the awkward case; an empty destination is much simpler.
Where you can, start from an empty destination and let the sync populate it.
The key is a credential
It grants a remote instance the ability to write into your datastore. Give it the same care as any other credential — not shared with other integrations, and rotated on a schedule you keep.
Make the destination read-only immediately
Before anybody sees it. A destination copy that people can edit will be edited, and their changes will vanish at the next source change — which reads as data loss and is very hard to explain after the fact.
Test with a real change
Change one record at the source and watch it arrive. Then delete one and confirm the deletion carries across, because that is the case most likely to be misconfigured and the one people notice last.
Worked example
A subsidiary's catalogue datastore is created from the parent's definition, left empty, and synced hourly. The first run populates 1,400 products. A test price change arrives within the hour and a test deletion removes the row. The destination is then granted read-only to every group.
Recommendations
- Build the destination from the source definition.
- Change both ends together, always.
- Start from an empty destination where you can.
- Test a deletion, not just an edit.