Where the Data Source Lives
Where the remote system runs decides how it should be used. The same connection that is comfortable for live reads in one deployment is unusable in another.
Where to find it
Architect Panel → Integration & Connections:
- Data Sources — the connection, its timeout and row limit
- Data Source Sync History — run durations, which reveal latency problems
Same region
The remote system runs in the same cloud region as the platform. Round trips are a few milliseconds, there are no egress charges between them, and network rules are simple.
This is the only pattern that comfortably supports live reads on an interactive screen.
Another region
The connection works, but every query pays the round trip — typically tens to a couple of hundred milliseconds. That is tolerable for a scheduled sync and painful for a screen that issues several lookups while somebody waits.
Where the source is in another region, prefer syncing on a schedule and reading the local copy.
On-premises
Common for established line-of-business systems. The platform reaches the customer's network over a site-to-site VPN.
Plan for the link being down sometimes — a VPN that drops for ten minutes overnight is unremarkable, and a design that assumes constant availability will produce alerts nobody can act on. Scheduled syncing tolerates this naturally; live reads do not.
Software as a service
Salesforce, Google Sheets, and services behind REST or GraphQL. These are reached over the internet, and their own rate limits and concurrency rules apply.
Respect those limits when setting sync intervals. A five-minute sync against an API with a modest daily quota will exhaust it, and the failure arrives as a throttling error hours after the change that caused it.
Choosing live or synced
The decision follows from the above more than from preference:
- Live — same region, low latency, data that must be current to the second.
- Synced — anything remote, anything intermittent, anything rate-limited, and anything you want to report on.
When in doubt, sync. A local copy is faster, survives the remote system being unavailable, and can be indexed and joined; the cost is that it is as current as the last run.
Network security
- Allowlist the platform's egress addresses at the remote firewall rather than opening the service broadly.
- Require TLS, with certificate verification, unless the traffic is inside a controlled private network.
- Give the connection its own credentials and rotate them on a schedule you actually keep.
- Separate read and write accounts where writeback is enabled.
Watch the sync durations
Sync history records how long each run took. A run time that is creeping upwards is the earliest warning of a source outgrowing the arrangement, and it is much easier to act on before the run stops fitting in its interval.
Worked example
A customer's on-premises SQL Server is reached over an IPsec VPN, with a read-only account opened by their DBA. Because the link occasionally drops overnight, the objects are configured to sync hourly rather than read live, and the sync history is checked weekly — where a run time rising from 40 to 90 seconds over two months prompted an index on the remote table.
Recommendations
- Live reads only for same-region sources.
- Sync anything remote, intermittent or rate-limited.
- Allowlist egress addresses rather than opening the service.
- Review sync durations as an early warning.