A change-detection engine, a field mapper, a conflict resolver, and an audit log, working together so every sync connection stays trustworthy without babysitting.
Most connections use a change stream (a database's transaction log, or a source's webhook events) instead of repeatedly asking "what changed?" A change stream tells Syncful the instant something does, so there's no polling delay and far less load on the systems you're syncing.
Some tools only expose a REST API with no webhook or log to read from. For those, Syncful falls back to short-interval polling, typically every few seconds, which is slower than a true change stream but still far faster than an overnight export.
A "Company" field in one tool might be "Account Name" in another, stored differently, or missing entirely. Mapping lets you connect fields explicitly and transform values as they cross.
Point a source field at a differently-named target field. Syncful remembers the pairing for every future sync.
Reformat a date, split a full name into first and last, or convert a currency, without a separate transformation step.
Not every field belongs on the other side. Leave a field unmapped and Syncful will never touch it.
Mark a field as excluded and it never leaves the source system, useful for anything you don't want mirrored at all.
Bidirectional sync means two systems can edit the same record within moments of each other. Syncful gives you three ways to decide what wins, set per sync connection.
The most recent change, by timestamp, is kept. Simple, and a reasonable default when both systems are equally trusted.
One system is always authoritative for a given field. The other side's value is overwritten, never the reverse.
Conflicting changes are held and surfaced in a review queue instead of auto-resolving, for the fields where a wrong guess is costly.
Most connectors authenticate with OAuth in a couple of clicks. A few older systems need an API key instead, Syncful will tell you which one a given connector expects.
Most of the systems Syncful connects to offer a sandbox or developer account. Point a new sync connection at that before flipping it on for production data, so you can watch how your conflict rules behave without any real risk.
Every sync connection runs over TLS, and any credentials Syncful stores to authenticate are encrypted at rest.
Connectors request only the permissions a sync actually needs, never broader account access than necessary.
Every synced change is logged with its before and after value, kept for as long as your workspace is active.
A technique for reading a database's transaction log to see every insert, update, and delete as it happens, instead of repeatedly querying the whole table. It's how Syncful gets near-instant updates with minimal load.
A callback a source system sends the instant something changes, rather than Syncful having to ask. Where a tool supports webhooks, Syncful uses them instead of polling.
Applying the same sync event twice has the same effect as applying it once. It matters because retries after a network hiccup shouldn't create duplicate records.
An update-or-insert: if the record already exists on the target, it's updated, if it doesn't, it's created. Most syncs use upserts so records never duplicate.
The system designated as authoritative for a given field. When there's a conflict, the source of truth's value wins and the other system is overwritten.
The one-time sync of existing records when a connection first goes live, run before Syncful switches to watching for new changes only.
Syncful queues affected events and retries with backoff, staying inside the source system's API limits automatically. Nothing gets dropped.
The time between a change happening in one system and it landing in the other. For most connectors that's under a second, measured and shown per connection in your dashboard.